项目实训（四）｜中医智能诊疗系统症状提取与知识库表设计与开发

项目开发日志 | 阶段三：症状存储与RAG知识库落地

---

中医智能诊疗系统开发日志：症状提取与知识库表设计实践

前言

本阶段，工作重心从基础数据库搭建，转向诊疗核心数据结构化与大模型能力支撑。在这一阶段，不再只是简单建表，而是围绕“AI自动症状提取、多智能体协同、RAG检索增强、幻觉控制”等真实业务流程，设计可直接支撑后续功能的数据结构。本篇重点记录我的需求理解、设计思路、工程决策、阶段进度与技术思考，完整呈现本阶段的开发过程与成果。

---

一、本阶段工作目标与整体思路

在开始编码前，我先明确了阶段目标与推进思路：

1. 围绕会话级症状提取业务，设计专用存储结构，让AI提取的症状可保存、可查询、可展示。
2. 为RAG知识库与幻觉控制设计存储结构，让大模型诊疗有据可依。
3. 保持表结构、编码风格与项目前两阶段完全统一，保证架构一致性。
4. 只新增表、不改动原有结构，确保系统稳定，降低团队协作成本。
5. 完成从需求→设计→编码→验证的完整流程，形成可交付成果。

我的整体思路是：先理解业务为什么需要这两张表，再确定字段与关系，最后按照项目规范落地为可运行的数据库结构。

---

二、业务需求理解与设计依据

在设计表结构之前，我先梳理了背后的真实业务逻辑：

1. 症状提取模块的需求

在智能诊疗流程中，用户与AI聊天时，系统会自动从对话中抽取症状（如头痛、乏力、失眠），并在右侧面板实时展示。这些症状必须持久化存储，才能用于后续辨证、食疗推荐、诊疗记录生成。
因此症状表必须满足：

• 与会话绑定，一次会话对应一组症状
• 支持批量存储，方便前端展示
• 会话删除时，相关症状同步删除
• 记录提取来源与时间，便于追溯

2. 知识库与RAG的需求

项目采用多智能体+RAG架构，7个诊疗Agent都需要从知识库获取依据，从而控制大模型幻觉、提高输出可靠性、实现诊疗依据可视化。
因此知识库表必须满足：

• 支持知识分类（症状、疾病、体质、方剂、食疗等）
• 存储原文内容，用于检索与展示
• 预留向量字段，支持后续向量化检索
• 记录知识来源，保证专业性与可信度

---

三、表结构设计思路与技术决策

在设计症状表与知识库表时，我充分结合了项目现有风格、业务扩展性、团队协作规范三方面要求，同时围绕“症状提取、RAG 检索、幻觉控制、食疗安全”等核心业务目标，最终确定了表结构。所有设计均不改动原有表，只做平稳扩展，保证系统一致性与可维护性。

1. 症状表（symptoms）设计思路

我采用单条记录存储一组症状的方案，使用数组字段symptom_list保存一次会话提取的所有症状，而不是每条症状单独建一行。
这样设计的优势非常明显：

• 贴合前端展示逻辑，一次查询就能获取当前会话全部症状
• 减少数据行数，提升查询效率
• 与项目现有风格保持一致（sessions 表已使用数组结构）
• 通过 session_id 外键与会话绑定，并设置级联删除，保证数据生命周期统一
• 增加 extracted_from 字段，用于记录是 AI 自动提取还是人工修正

对应的关键字段如下：

• id：UUID 主键，保证唯一标识
• session_id：关联会话，实现数据归属
• symptom_list：数组类型，存储一组症状内容
• extracted_from：提取来源，便于追溯
• created_at、updated_at：统一时间字段规范

2. 知识库表（knowledge）设计思路

知识库表采用分类 + 标题 + 内容 + 向量 + 来源的经典 RAG 结构，是整个项目幻觉控制、检索增强、诊疗依据的核心底座。
我在设计时重点考虑：

• 使用 category 分类字段，让后续知识检索更精准
• 设置 embedding 向量字段，为后续向量化与相似度检索做准备
• 增加 source 来源字段，提高知识库可信度与可追溯性
• 字段长度、类型完全贴合中医长文本存储特点
• 保持与项目统一的 UUID 主键、时间字段风格

对应的关键字段如下：

• id：UUID 主键
• category：知识分类（症状、疾病、体质、食疗等）
• title：知识标题，便于快速检索
• content：存储中医专业知识内容
• embedding：向量存储，用于 RAG
• source：知识来源（教材、古籍、指南等）
• created_at：统一时间字段

通过以上设计，两张表不仅能满足当前功能需求，还能为后续RAG 接入、大模型幻觉控制、食疗安全检查、诊疗依据可视化提供完整的扩展能力。

---

四、开发过程与工程实践

在具体实现阶段，我严格按照项目分层架构推进：

1. 表结构设计
   先完成SQL层面的表设计，确保字段、约束、索引、外键正确，与现有系统风格统一。

2. ORM模型开发
   在backend/db/models/目录下新建模型文件，将数据库表映射为Python类，实现对象化操作，避免直接编写复杂SQL。

3. 模型注册
   在__init__.py中按依赖顺序导入新增模型，保持导入结构清晰，便于上层模块调用。

4. 更新初始化脚本
   将新表写入init_db.sql，方便团队统一使用最新结构，支持一键初始化。

5. 结构验证
   通过数据库连接测试，确认表创建成功、字段正确、约束生效，确保可进入下一阶段开发。

整个过程遵循最小改动、结构统一、可验证、可协作的工程原则。

---

五、本阶段完成成果与进度总结

具体成果如下：

1. 完成症状表（symptoms）设计与实现
   支持会话级症状存储、数组格式、级联删除，满足AI症状提取业务需求。

2. 完成知识库表（knowledge）设计与实现
   支持知识分类、内容存储、向量扩展、来源记录，为RAG与幻觉控制提供数据底座。

3. 完成ORM模型开发
   模型风格、字段规范、继承关系与项目完全统一，可直接被上层接口调用。

4. 完成数据库结构升级
   仅新增表，不改动原有结构，系统平稳扩展，团队可无缝同步。

5. 完成验证测试
   表结构创建成功、外键与索引生效、连接稳定，可支撑下一阶段开发。

目前数据层已具备会话管理、症状提取、知识存储、诊疗记录的完整支撑能力。

---

六、技术理解与收获

通过本阶段开发，我对数据库设计在AI项目中的作用有了更实际的理解：

• 数据库设计本质是业务流程的持久化，必须先理解业务再设计结构。
• 好的表结构能够显著降低上层开发复杂度，提前避免大量逻辑问题。
• 在多智能体与RAG架构中，知识库表是系统可靠性的关键基础。
• 项目迭代中应保持风格统一、最小改动、可扩展，提高团队协作效率。
• 开发不仅是实现功能，更要保证可维护、可验证、可扩展。

---