NexaRAG：把 RAG 证据链落到 3C 数码客服项目里

NexaRAG 是我围绕 3C 数码产品客服场景做的一套 RAG 智能问答系统。这个项目的重点不是“接一个向量库再问大模型”，而是把 RAG 里常见的知识点真正落到工程链路里：知识怎么进入系统，证据怎么被召回，候选片段怎么变成可用上下文，模型回答之后又怎么判断它有没有留在证据边界内。

我选择 3C 数码客服作为场景，是因为它足够具体，也足够容易暴露问题。用户会问产品参数、故障排查、购买建议、竞品对比，也会在多轮对话里省略产品名。比如“这款耳机连接不上怎么办”“小米 15 Pro 和 iPhone 16 Pro 哪个更适合拍视频”“它电池多大”。这些问题既需要准确匹配型号和参数，又需要理解自然语言里的指代和场景。

项目要解决的问题

普通 FAQ 能回答标准问题，但面对多轮追问、产品对比和模糊表达时会比较吃力。大模型表达能力强，但如果没有可靠知识支撑，又容易编造参数、混淆型号，或者把几段互相冲突的资料强行合成一个肯定答案。

所以 NexaRAG 的目标很明确：先找到证据，再组织答案；证据不足时不硬答，必要时澄清或拒答。它更关注客服问答里的稳定性、可追溯性和可评测性。

我是怎么做的

项目按一条 RAG 证据链来设计。

第一步是知识入库。系统支持将 3C 产品资料导入知识库，并在入库时完成结构化 chunking、metadata 构建、文档去重、版本管理和索引重建。这里我没有只按固定长度切文本，而是尽量保留标题、段落、产品、品牌、文档类型等信息，让每个 chunk 都带着“身份”。这样后面做过滤、排序和证据组织时，系统知道这段内容属于哪个产品、适合回答什么问题。

第二步是混合检索。3C 场景里有大量型号、数字、品牌名和专有名词，单纯向量检索不够稳。因此系统结合 BM25 关键词检索和 pgvector 向量检索：BM25 负责型号、参数、故障关键词等精确匹配，向量检索负责语义相近但表达不同的问题。两路结果再通过 RRF 融合排序，并接入 rerank，把更相关的候选片段排到前面。

第三步是证据组织。检索结果不能直接一股脑塞进 prompt。系统会按产品、问题类型、相关性和证据来源整理候选片段，把它们变成更干净的上下文。这样模型看到的不是杂乱文本，而是更接近“可引用证据”的材料。

第四步是答案边界。RAG 不是把资料交给模型就结束了。NexaRAG 会检查答案里的关键事实是否被证据支持，关注数字、型号、价格、容量、保修规则等高风险信息；当证据不足、产品歧义或证据冲突时，系统会触发澄清、拒答或冲突提示，避免模型看起来很自信地答错。

第五步是评测。项目建立了 Golden Set 和 Smoke Test，覆盖单品规格、产品对比、购买建议、故障排查等问题类型。评测不只看答案像不像，还会看检索是否命中目标证据、引用是否合理、该拒答时是否拒答，以及答案是否忠实于证据。

LangGraph / Agent 编排

在流程组织上，我参考 LangGraph 和 Agent 节点思想，将一次问答拆成意图识别、查询改写、工具检索、答案生成和结果校验等模块。

这样做的好处是可观察、可替换、可迭代。比如检索失败时，可以单独看 query rewrite 是否把问题补完整；答案不稳时，可以看是证据组织不清楚，还是答案校验策略不够严格。相比把所有逻辑堆在一个长 prompt 里，这种拆分更适合持续优化。

项目亮点

• 用结构化 chunking 和 metadata 让知识片段带上产品、来源和版本信息，而不是只有一段孤立文本。
• 用 BM25 + pgvector + RRF + rerank 组合检索，兼顾型号精确匹配和语义召回。
• 将候选片段整理为证据上下文，减少无关内容进入 prompt。
• 加入答案校验、证据不足拒答和冲突提示，降低产品参数类幻觉风险。
• 用 Golden Set 和 Smoke Test 做持续评测，让 RAG 优化有可比较的指标。

我从这个项目里学到的

做完 NexaRAG 后，我对 RAG 的理解从“技术组合”变成了“证据链工程”。一个可用的 RAG 系统，不只是 embedding、向量库和大模型，还包括知识治理、检索策略、上下文工程、答案约束和评测体系。

对 AI 应用开发来说，真正难的地方往往不是调用模型，而是让模型进入一个可靠的业务流程：什么时候检索，信哪些证据，证据不足怎么办，答案生成后如何校验。NexaRAG 就是围绕这些问题做的一次完整实践。

技术关键词

Python、FastAPI、LangChain、LangGraph、DashScope Qwen、pgvector、BM25、RRF、rerank、RAG Evaluation、Golden Set、Smoke Test、答案校验、拒答策略。