数据库文档问答技术应用与演进趋势

大规模文档带来的业务挑战与RAG解决方案

先交代一下背景。PingCAP 专注关系型数据库领域，核心产品包括 TiDB 和 TiDB Cloud，分别覆盖本地部署与云上服务。数据库类产品天然伴随大量文档——目前英文加中文文档已超过 2000 篇，若算上社区中有价值的内容，总数直奔 15000 篇。

文档数量庞大，普通用户几乎无法全部阅读，导致难以形成整体认知，更谈不上快速定位所需信息。而 PingCAP 作为一家快速成长的中小型企业，人力资源有限。随着用户规模持续扩大，技术支持团队的人手缺口越来越明显，响应间隔也随之拉长。这一问题在海外社区尤为显著，因为当地社区已经相对成熟。

针对上述痛点，团队开发了一款基于文档的智能问答机器人。目前该机器人已上线至 Cloud UI 及海外社区——在 Slack、Discord 上，你可以直接 @ 机器人提问。下面具体聊聊实现过程。

RAG 技术落地实践与演化历程

整个 RAG 实践可分为四个阶段：绿色阶段是最基础的 Basic RAG，黄色阶段是应用优化，最后又分化出两个方向——GraphRAG 和 Agent RAG。

1. Basic RAG

Basic RAG 的逻辑相当直接：借助大语言模型的多轮对话能力，理解用户提问，然后输出精准答案。然而基础模型常常生成与 TiDB 无关的内容。最初尝试 OpenAI，其 Embedding model 对多语言数据库的支持不够理想，检索结果不准确，因此必须对模型进行调优。

2. Only Answer TiDB

团队规模小，自行训练或微调模型成本太高，相比之下 RAG 性价比更优。最终选定 RAG 方案。

核心需求是限制大模型只能回答 TiDB 及业务相关问题。采用业界常见的毒性检测技术即可实现：将与 TiDB 无关的问题定义为“毒性”，让大语言模型自行判断是否相关。上图的 prompt 示例展示了具体做法——基于用户问题，通过向量相似度提取，简单直接地判定是否与 TiDB 有关。

效果相当理想。面对“how to cook a cake”“what about China”等无关或敏感问题，模型都回复了类似“该问题与 TiDB 无关”的应答。关键在于流程中只让 LLM 输出 yes 或 no，由模型自行决定走哪个分支。这样既实现了毒性检测，又避免了 prompt 越狱——因为即便用户尝试越狱，输出不是 yes 时流程也会判为 no。

为什么不在 System Prompt 里直接限制？因为 System Prompt 没有权重，用户输入足够长的越狱 prompt 后，模型仍然可能越狱。所以必须采用 RAG 结合毒性检测的方法才能真正防范。

3. Embedding Model Finetune

TiDB 面向全球用户，拥有英语、日语等多语种语料，而 OpenAI 最先进的 Embedding model（text-embedding-ada-002）不支持非英语语言。用户提问后，模型返回的召回文档 top 结果全是英文，但不可能将所有文档统一为英文，这带来极大不便。官网和 UKP Lab 等社区也证实了这一局限。

解决办法是自行微调 Embedding model，弥补开源模型的不足。团队很小，为了减少人工投入，采用了机器学习中常用的 GenQ 方法：先对所有文档分块，再随机抽取部分进一步切分，然后用 GenQ 生成文档及其对应的 question，得到 chunk-question pairs，拆分为训练集和测试集进行训练。

训练采用 MultipleNegativesRankingLoss 方法，选取大小两个模型，用 4K 数据训练、1K 数据测试。该方法的关键点在于：由于训练数据由 GenQ 生成，只有正例没有反例，因此需要自动生成反例来控制正负样本比例，使训练更高效。

对比结果：OpenAI 的 text-embedding-ada-002 准确率为 0.984，我们微调后的模型为 0.983。考虑到测试数据同样基于 OpenAI 生成的语料，可能存在过拟合，后续又用 TiDB 官方文档做了多轮测试，结果依然理想。在其他领域准确率可能下降，但在数据库领域，正常语料下完全满足要求。

使用微调后的多语言模型，公司超过 15000 篇文档都能被充分利用，避免了像 OpenAI 那样只能处理英文文档的局限。该方案人力投入少、训练效率高、成本低，而且自托管的 Embedding model 可以多次调整。RAG 向量搜索的质量主要取决于向量表达，而向量表达又依赖于 Embedding model，因此可以针对用户提问与文档的关系进行定向匹配，通过多次微调获得更高的召回准确率。

4. ReRank

产品上线后很快应用到公司内部及部分灰度客户。最初几个月，我们让用户对所有结果点赞或点踩，收集反馈。但并非所有问题都能获得反馈——有 57% 的问题没有反馈。用户 like 占比仅 9%，dislike 却高达 34%，说明初版效果非常糟糕。人工统计发现，最大问题是检索结果错误。

真实世界的问题过于复杂多变，召回时表现不理想。从技术角度看，主要是相似度召回的 ranking 太低，导致正确的语料被排除在外，大模型只能靠“幻觉”回答——有文档但召回了错误的文档。

解决办法是引入简单的 ReRank：将用户常用的 QA pairs 记录到向量数据库中，用向量空间（可能是向量数据库、一张表或 name space）存储。召回时，同时在原始文档向量空间和优化后的向量空间进行召回，选取 top 10 送到 LLM 中进一步处理，判断最合适的文本语料。这样一来，所有 ad-hoc 的 basic RAG 问题基本都能得到解决。

由于要承担业务，大量工作留在了 OPT 平台（优化平台），自动追踪用户产生的各类问题、疑问，记录用户的分享甚至 dislike。正向行为数据记录到另一个向量空间中备用；负向行为数据分成两部分处理——一部分再次让 LLM 回答，定向推送给用户确认；另一部分由专家介入排查错误原因，重新调整。当调整后的 QA pairs 足够多时，这些数据可用作 Embedding model 的训练材料。

经过这一流程，产品从灰度上线到持续优化，dislike 比例从最初的 34% 降到了 2%-3%。

5. Basic RAG 的业务挑战

Basic RAG 的挑战也十分明显。前面讨论的均围绕向量相似度展开，但有些场景下，向量相似度未必是最优的搜索方法。真正的需求不是一个 RAG，而是一个全知全能的搜索引擎——只是目前还没有哪个搜索引擎能做到这个程度，包括 Google。因此需要对搜索方法进行调整。如果基础向量搜索效果不理想，就要引入其他方法，比如图数据库方法，或者直接接入真正的搜索引擎（Google、Bing 的 API）。目的是满足业务需求，而不局限于某一种技术栈。

6. Graph RAG

微软今年 4 月发表了一篇 Graph RAG 论文，系统化地阐释了如何利用 Graph RAG 实现引擎搜索功能。我们与微软团队以及 LlamaIndex 三方合作，对引擎搜索进行了探索，分为 index 和 query 两个阶段。

Index 阶段，首先需要构建知识图谱（KG），因此需要丰富的文档和社区问答，然后对文档进行切分。这里存在一个问题：用 entity 做 graph 还是用 chunk 做 graph？参考 Google 的方案，两者都需要——既包含 entity 也包含 chunk，而且这个 chunk 是基于 entity 进行 summarize 得到的。构建知识图谱是异步过程，有充足的时间将每个 entity 相关的摘要信息全部生成，再存到向量数据库中。

我们开发了一个可视化工具，将文档的知识图谱节点和边展现出来。此外还制作了 IndexingHandbook，读者可以扫描二维码（link to Google Colab）了解如何一步步搭建知识图谱并实现 query。

Query 过程：将用户的问题 embedding 得到向量，搜索出 K 度内的关联节点及关系，组装后输入 LLM。

7. Agent RAG 的业务挑战

前面都是基于用户问答进行的，但有一种特殊情况——诊断问答。诊断问答往往无法通过单次交互、单次 RAG 完成，因此另一条线采用 Agent RAG 的方式，供终端客户（如工单、云端运维平台用户等）使用。

Agent RAG 的简单架构：用 agent 方法 trigger 语料库，获取各类 API 信息和异构数据信息，并通过可观测性、优化平台和测试平台保证模型准确度不断提升。我们构建了四个 agent：Planner（将问题规划成一系列子任务）、Engineer & Executor（成对执行子任务）、Critic（评价执行结果，关注执行内容是否与用户问题相关、问题是否得到解决）。

在 Planner 过程中，输出一系列 system status 并 track 各类 RAG，得到背景信息；Engineer 和 Executor 通过多种 RAG 方法实现，比如调用 API、生成 SQL 或其他代码；Critic 判断流程执行情况。这套 Agent 基于微软 AutoGen 框架，为增强稳定性，增加了 FSM 特性，使 agent 之间的流转更可靠。目前 Agent RAG 已应用于内部的一个集群诊断平台。

8. RAG 应用图

总结所有 RAG 应用：绿色部分是最初的 Basic RAG 流程，为了优化增加了黄色部分——判断是否 TiDB 相关、finetune Embedding model、ReRank 内容。每个环节都基于业务目标进行了优化：语料、模型、工程。为了让召回更精准，构建了知识图谱，特别是对于答案分布于多个文档中的情况，借助知识图谱让很多之前难回答的问题都得到了解答。更进一步，采用 Agent 方式，利用多智能体规划评估，结合整个语料和各类 API 联合解决问题。以上就是 PingCAP 在基于 RAG 进行文档智能问答方面的业务实践。

前沿介绍

RAG 生态图

上图展示了当前的 RAG 生态。值得指出的是，对于 RAG 而言，评估系统至关重要。我们的工作聚焦于 Modular RAG，未来会向 Evaluation of RAG 方向发展。同济大学的 RAG server 涵盖了各类 RAG 实施方法，非常全面。其中右下角是最佳工业案例介绍，提供了很多参考。我们所使用的 agent 方法和图中左下角 loop 方法相似，区别在于我们用的是 AutoGen Agent。

以上就是本次分享的内容。

Q&A

Q1：图片语料这一部分如何处理？

A1：本文没有详细介绍语料部分，但“垃圾进垃圾出”，语料的重要性不言而喻。工业实践时，最理想的状态是统一的语料输入（例如 Markdown 输入）。对于图片部分，暂时没有尝试图片识别处理，因为初步尝试发现无法达到工业级的质量要求。目前图片识别的最高标准是 GPT-4o，还不足以满足工业级别的图片分析要求——特别是对图片的理解，以及与上下文和用户提问进行关联，进而准确回答用户问题，这一要求目前还无法做到。

Q2：如何处理标题切分，以及上下文的语意连贯？

A2：有两个建议。首先可以参考 Llama index，充分利用开源的力量，里面包含按标题处理切分这样的逻辑。其次，假如 Llama index 中没有包含该逻辑，可以根据具体情况进行灵活处理。例如，对于 Markdown，可以按照井号实现切分，并在井号上下侧各做一层 overlap，确保上下文的语意连贯。RAG 领域并没有银弹，需要根据具体业务进行调整。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：数据库文档问答技术应用与演进趋势要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题