中医知识问答大模型

一、项目改动总结

# 前代代码中API key是硬编码的
headers = {
    "Authorization": "Bearer sk-xxxxxxxxxxxxxxxxxxxxx",  # ❌ 硬编码
    "Content-Type": "application/json"
}

# 当前代码使用配置文件和环境变量
if config:
    self.API_KEY = config.SILICON_FLOW_KEY  # ✅ 从配置文件读取
    self.BASE_URL = config.SILICON_FLOW_BASE
else:
    self.API_KEY = os.getenv("SILICON_FLOW_KEY", "")  # ✅ 从环境变量读取
    self.BASE_URL = os.getenv("SILICON_FLOW_BASE", "https://api.siliconflow.cn/v1")

# 上下文记忆功能核心实现
class ContextManager:
    def __init__(self, max_history_length=5):
        self.max_history_length = max_history_length
        self.conversation_history = []
    
    def add_message(self, role, content):
        """添加消息到对话历史"""
        self.conversation_history.append({"role": role, "content": content})
        # 保持历史记录在最大长度内
        if len(self.conversation_history) > self.max_history_length * 2:
            self.conversation_history = self.conversation_history[-self.max_history_length * 2:]
    
    def get_context(self):
        """获取对话上下文"""
        return self.conversation_history
    
    def clear_context(self):
        """清空对话历史"""
        self.conversation_history = []

二、代码质量提升

四、下周工作计划

一、项目概述

本项目成功设计并实现了一个高度智能化的中医知识问答平台。该平台深度融合了大语言模型 (LLM) 的自然语言理解与生成能力，以及知识图谱 (KG) 的结构化知识存储与推理能力。系统采用 Flask 后端框架，结合 Qwen3-Embedding-8B 模型提供强大的语义理解，DeepSeek-VLM 模型进行 OCR 和文档结构解析，Neo4j 数据库存储图谱，ChromaDB 向量数据库管理海量文本数据，并提供 Web 前端交互界面。核心目标是为用户提供专业、准确、可靠且交互友好的中医问答服务，并支持用户上传自定义文档自动扩展知识库。

二、核心技术架构

三、核心功能模块

四、技术亮点与创新

五、项目状态

系统界面展示

图1：中医知识问答系统主界面

知识图谱可视化

图2：中医知识图谱可视化展示

文档处理模块

图3：文档智能处理模块界面

多模态交互

图4：多模态输入与OCR处理结果

六、未来可扩展性

一、研究概述

本周工作聚焦于中医药知识图谱问答引擎的架构实现与流程打通。完成了基于Neo4j图数据库与Chroma向量数据库的分层检索系统搭建，初步实现了从自然语言问题到结构化查询再到答案生成的完整链路，并对核心模块进行了功能性验证。

二、完成的具体工作

4. 功能验证

以"白术的作用是什么"为测试用例，系统在第一层成功生成Cypher查询，从图谱中提取到5条功效关系（健脾利水、强脾、实脾、致冲和之气、安胎），并整合为连贯回答，验证了流程的基本可用性。

系统功能验证截图

图：系统对"白术的作用是什么"问题的处理流程与结果展示

三、当前系统特性

• 双层容错设计：主路径与备选路径自动切换，避免单点阻塞
• 检索深度可控：子图采样限制在1跳邻居与5条记录，平衡信息量与查询效率
• 抗幻觉机制：通过Prompt工程将LLM限制在检索结果范围内

四、存在的问题

• 知识库规模限制：当前实体与关系数据覆盖范围较小，大量专业问题无法召回有效子图，导致查询失败率较高。
• 数据质量不均：图谱中存在关系类型标注不完整、实体命名不统一等问题，影响检索准确性。
• 命中稳定性不足：系统高度依赖实体名称精确匹配，对别名、别称、语境变化等情况的鲁棒性较弱。
• 评估体系缺失：尚未建立量化测试集，无法系统评估各层检索的准确率与召回率。

五、下周计划

技术方案确立

经过对前沿技术的调研，确定采用检索增强生成 (Retrieval-Augmented Generation, RAG)作为本次问答系统的核心架构。该方案能有效结合知识图谱的准确性与大语言模型（LLM）的流畅性，避免模型产生"幻觉"，确保回答的专业性和可靠性。

开发环境搭建

• 完成了核心Python库的安装与配置，包括 langchain (AI应用框架), neo4j (数据库驱动), langchain-openai (LLM接口)等。
• 成功在Python环境中建立了与云端Neo4j AuraDB数据库的连接，并能够通过代码获取图谱的元信息（Schema），为后续的自动化查询生成奠定了基础。

"文本到查询" (Text-to-Cypher) 技术验证

初步尝试使用 LangChain 框架中的 GraphCypherQAChain 模块，旨在将用户的自然语言问题（如"麻黄汤的组成是什么？"）自动转换为精确的Neo4j查询语句（Cypher）。

下一步计划