7.5.md 3.3 KB
7.5 融合 MySQL、Milvus 与 Neo4j
前面几节已经把 FAQ 与知识库问答接入 API。本节只增加一个清楚的能力边界：FAQ 未可靠命中、进入 RAG 后，让 Milvus 的两路证据与 Neo4j 图证据共同参与。
{{figure:integration|图 7-1 原 FAQ 入口继续处理可靠命中；图检索加在 RAG 的证据层。}}
一、先找到真正生效的接入位置
增强版提供独立 graph_qa 问答入口，也把它接入整合项目的运行链路。原项目同时存在不同阶段的 RAG 实现，不能只看到一个名字叫 rag_system.py 就假定 API 使用它；应从 API 的调用对象追到实际检索方法。
{{snippet:integration-hook}}
这一段关注调用边界与返回结构，完整路由配置在增强版代码中。保持原 FAQ 的可靠命中行为，进入图增强 RAG 时才使用新的检索编排。Query 改写仍可在检索前进行，它与“多一个检索通道”是两个可组合的维度。
二、答案之外，接口还应返回什么
{{snippet:api-response}}
回答正文供用户阅读；citations 供来源展示；paths 供解释关系；warnings 告知降级与未知引用。界面如果只显示 answer，会丢掉本章最有教学价值的“路径和原文怎样支撑结论”。
知识域从真实用户权限推导是企业集成的重要工作。教学 API 允许指定配套 scope 以演示隔离，不应把这种参数选择当成已经实现了用户身份认证和授权。
三、用同一道题验证 API 和命令行一致
uvicorn app:app --host 127.0.0.1 --port 18080
启动后在本地接口文档中提交 q03，选择 hybrid（融合检索）与 dessert-shop（接口中代表甜品店的代号）。核对回答、三份关键来源和包含／需要组成的路径，再与命令行结果比较。模型措辞可能变化，事实和引用约束应保持一致。
{{runtime:api}}
四、FAQ、追问与历史展示怎样衔接
增强版先规范化 FAQ 查询：MySQL 返回的记录与 Redis 中缓存的答案统一为同一种业务形状，精确命中优先；近似匹配的门槛是工程筛选条件，不是模型置信概率。这样“可靠 FAQ 直接返回、其余进入 RAG”才真正成立。原第三章阶段代码保留，相关运行修复在增强整合项目中体现。
多轮追问如“那应该找谁”，需要结合历史形成独立检索问题。增强版仅在存在历史且出现指代追问时执行这一步；首轮与基准评估不改写。重写后的问题仍然走固定多路检索，不会借这个步骤把图通道关闭。
回答的引用和路径随会话历史保存，界面可以展开原文与关系。每个请求的检索结果需要隔离，防止并发请求拿到其他人的引用；查看历史时也应恢复当时的证据，而非用当前数据库重新猜出一套引用。
五、不要在接入时悄悄换掉检索实验
接入 API 后继续保留 milvus、graph、hybrid 三种模式供课堂对照。若旧入口仅返回文本，新入口返回结构化结果，应该明确适配这一差异。不要把三种模式写成三个独立且参数不一致的系统，否则第六章建立的对照实验就失去可比性。
下一章部署时，把 Neo4j、Milvus、生成服务、API 以及共享模型目录分别检查；只有真实请求走完这条链，才能说接入完成。