是否做过知识库或 RAG 项目？

核心回答

下面给出两种项目介绍示例：一种是代码实现路线，另一种是基于已有开源底座的业务设计路线，可根据自己的实际参与范围选用。

运维知识助手：LangChain 路线

“项目面向运维人员，输入错误码或故障描述，从内部说明文档检索依据，再生成解释。技术上用 Python 和 LangChain 组织加载、切分、检索与生成，DashScopeEmbeddings 负责向量化，Redis 向量索引保存文档片段，聊天模型依据召回内容回答。

链路分两部分：先把文档加载并切分，连同来源信息生成索引；用户提问后，将问题向量化、召回片段，再把片段和问题交给模型。我的工作重点放在文档处理、检索与生成的连接，以及错误答案的分段定位。交付时会保留入库与问答脚本、问题样例和对应的召回片段，检查文档中的错误码能否找到、答案是否忠实，以及文档不存在的信息是否仍被编造。”

设备售后知识助手：Ragent 业务设计路线

“项目给售后工程师按型号、固件和故障现象查手册。采用的 Ragent 底座由 Java / Spring Boot 提供后端，MySQL 保存业务与知识库记录，Milvus 承担向量检索，并复用多通道召回、融合重排与引用。

这条路线的重点，是设计设备档案与手册适用范围的匹配：先统一型号别名和版本，生成允许手册集合，再让实际召回通道遵守这个范围，最后检查引用与建议。行业适配属于设计方案，验证会覆盖同故障不同型号、同型号不同固件、缺条件、旧手册混入和无适用资料，分别判断适用性、召回和回答，而不是只看回答是否流畅。”

展开说明

入库阶段为什么影响最终答案？

先检查解析是否保留标题、表格中的对应关系和错误码。按文档结构切分，避免把错误码与处理步骤分开；每块保留文档标识、版本和位置，便于过滤与引用。嵌入模型改变后，索引和查询也要保持兼容，不能随意混用新旧向量。

入库不只是存文本。若更新手册只新增索引却保留旧有效记录，在线检索就可能同时取到冲突版本，因此需要管理文档版本、删除状态与更新范围。

为什么不能只做向量检索？

向量检索适合同义表达，但错误码、型号和专有名词可能需要精确词法匹配。可以按问题集比较向量、关键词、融合与重排，确认是否有收益，再决定增加哪一步。重排能改善候选顺序，但无法找回从未召回的正确文档，也不能代替设备版本规则。

设备案例中，底座的通用检索作用域区分主路与补充库，并不天然实现设备手册限制；拟议适配需要覆盖全部实际召回路径，不能只在最终答案里删除不合适的引用。

如何验证个人模块和整条链路？

保留一组有来源和预期的问题，覆盖精确错误码、同义问法、跨片段、缺条件和无答案。先看正确证据有没有进入候选，再看排序与上下文，最后看答案及引用。检索失败、证据被裁掉和模型误读要分开，不一开始就换模型。

产物可以包括可重复运行的处理脚本、索引配置、问题集、召回记录和失败修正前后对照。有运行数据时，再说明数据量、环境、基线和评价方法；没有实测结果，就围绕完成的功能与验证方法展开。

可能的追问

RAG 能完全消除幻觉吗？

不能。文档可能过期、检索可能找错，模型也可能扩写结论。需要可核查来源、证据不足处理和分层评测；“有引用”还要检查引用是否真正支持答案。

为什么不直接微调？

这些任务首先缺的是当前有效的业务资料和来源，检索更便于更新、过滤和回查。若证据充分时模型仍长期无法遵守输出格式或完成特定行为，再评估微调；先排除数据和检索问题。

对应教程

参考资料