企业知识库怎样选架构：文档 RAG、SQL 与图查询各解决什么问题

从业务人员最近做过的任务里取样，记录问题、允许查看的数据、应返回的对象和判对依据。例如“介绍退货政策”需要完整规则，“昨天已结算收入”需要交易状态和金额，“同一供应商影响了哪些订单”需要稳定主键与关系。它们不应共享一条未经区分的检索路径。

微软的 RAG 设计资料把数据管道与问答流程分开，数据平台建议则要求每个新增组件有明确用途。下面的分类表是本站的架构决策方法，不是厂商性能测试。

图数据库适合需要维护和遍历关系的任务，并不因为问题出现“关联”两个字就必需采购。少量固定关系可能由现有数据库连接查询完成。先量出查询复杂度和维护负担，再判断专用图引擎是否值得增加。

AWS 的资料列出关系数据库加向量扩展、搜索引擎、图分析与托管检索等不同路径。它提供的是选项，不是通用排名。已有稳定数据库、资料量适中且权限逻辑集中时，可以先评估现有系统能否承担查询；高更新频率、多来源检索或复杂全文需求可能需要独立索引。

记录连接方式、备份恢复、删除传播、权限过滤和团队维护能力。相同的模型换一个向量库不会自动解决文档抽取错误。将主系统数据复制到索引，也会增加同步和权限副本的责任。原始系统和索引更新时间必须能对应。

这里的查询都只读。即使解释成立，也不能顺手自动续费或改合同。需要执行动作时应建立独立工具合同、授权与幂等设计，不把问答系统的访问权限扩大成写入权限。

题集要包含短问题、精确编码、同名客户、过期政策、关系断裂、无权对象和确实无答案的情况。每题写清允许证据、参考结果和应拒绝的动作。先评估检索是否找对资料，再评估解释，统计问题则直接与受控参考查询比较。

假设有十二道演练题，其中四道需要精确计数。文档方案只答对八道解释题，不能把另外四题从报告删掉后宣称全部通过。也不能用模型给自己打分作为计数题的唯一依据。增加 SQL 路径后，还要测试用户改地区或时间时是否正确更新过滤。

可以再放入三份名称近似的产品手册：A 型号支持某接口，A-Pro 不支持，旧版 A 曾支持但已停用。问题只提 A 时，候选检索应验证型号和版本，不能因为 A-Pro 文本相似就采纳；问题缺型号时应先澄清。然后把一个对应型号的库存问题交给受控数据库查询，确认系统没有从手册里的教学库存数字回答。

结果报告按任务类型分别列出正确、错误、拒答和未知原因，再给总体分母。增加组件后既要检查原来失败的题，也要回放已通过的题，防止解决统计问题时破坏政策解释或权限过滤。

索引使用周一的合同快照，而数据库使用周三状态时，同一客户可能出现不同结论。答案应带数据时间；需要一致快照的任务，应由流程协调数据版本或停止合并，不能用流畅的措辞掩盖时间差。

每条路径保留对象标识、查询版本、资料版本和用户授权上下文。删除原始资料或撤销权限时，历史摘要与缓存也要重新判断能否复用。试点验收不仅检查正确答案，还检查缺资料、查询超时和路径失败能否给出清楚的待处理状态。

记录业务题清单、选择的查询路径、保留和删除规则、各项评测结果，以及谁负责资料、权限和运营。预算应包含索引更新、数据管道和故障处理，不只看首次建库成本。

如果文档方案已经满足主要任务且能解释失败原因，就继续改善资料质量；确有精确查询或多跳关系需求，再添加对应组件。选型结论应能用题集重新验证，而不是永久绑定某个产品名称。