企业里做AI助手，最容易翻车的地方不是模型不够聪明，而是把“聊天机器人”当成了“知识库问答”来验收。我参与过好几个企业级项目，最后发现核心需求翻来覆去就是三件事：能从多个数据库表里查数，能从一堆文档里找答案，能连续追问不出错。这正好对应标题里那三个关键词——多表、多文档、多轮问答。把它们捏在一起，再加上可落地的检索增强生成（RAG）管线，才叫真正的企业级AI Agent。
这篇文章不是讲概念，是我把一套实际跑过的RAG问答系统的完整过程做了复盘。从架构选型、工具取舍、数据接入，到多表查询的SQL生成、多文档的解析分块、多轮对话的记忆管理，再到上线前的性能和安全排查，都会展开说明。适合正在做企业知识库、数据问答助手、办公智能体的开发者和技术负责人参考。你不需要懂大模型原理，跟着链路看就能明白每一层在解决什么问题。
1. 需求梳理与整体架构设计
1.1 企业场景里的三类真实诉求
先泼一盆冷水：大部分人设想的“企业AI助手”，和业务方实际提出来的需求，往往不是一回事。业务方不会说“我要一个RAG系统”，他们说的通常是三句话。
第一句是“帮我查一下上个月华东区的回款金额”。这句话背后是数据库里的多张销售表、回款表、区域维度表，涉及联表查询和聚合计算。这不是靠向量检索能解决的，需要模型理解表结构并生成SQL，或者至少生成可执行的查询条件。这类需求统称“多表问答”。
第二句是“报销制度里关于差旅费超标的部分是怎么规定的”。这句话背后是几十份Word、PDF、Excel制度文件，有的还有扫描版PDF。模型得先定位到正确的政策章节，再抽取判断依据，还得能回答“如果超标了应该走什么流程”这种需要综合多段内容的追问。这类需求统称“多文档问答”。
第三句是前两句的组合。比如用户先查了制度，又查了自己的报销记录，然后追问“我这次超标了怎么办”。这里既有跨数据源的跳转，又有对上一轮引用信息的依赖，同时还需要在同一个会话里持续保持状态。这就是“多轮问答”真正难的地方。
所以我的第一个建议是：需求阶段先别急着画技术架构图，先把业务方的问题按“查数据、查文档、连续查”三类分好，再估算每一类的问题占比。很多项目一开始只做文档问答，结果上线两周后业务方开始天天问“为什么不能查数据”，这就是当时没把需求聊透，后面被迫补多表能力，返工成本非常高。
1.2 为什么RAG是当前最稳的落地路线
既然要让AI理解企业内部数据和文档，为什么不直接把所有东西塞进大模型的上下文窗口，非要引入RAG？
最直接的原因是成本和企业安全。企业知识量通常是GB甚至TB级别的，单次请求把所有资料塞给模型既不现实，也容易让模型被无关信息干扰。RAG的核心思路是先检索、后生成：先把资料切成小块并向量化存入向量库，用户提问时先召回最相关的若干片段，再把这些片段连同问题一起交给模型生成答案。这套机制能把“大海捞针”变成“按图索骥”，既控制token成本，又避免无关内容被模型编进答案。
但RAG不是银弹。它解决的是“如何让模型基于企业内部资料回答问题”的问题，至于资料本身是否完整、是否准确、权限是否隔离，RAG一概不管。我见过不少团队把RAG当成“只要接入文档就能得到准确答案”的万能药，结果做出来的系统问什么都答，但答案都是模型从各种相似的片段里“脑补”拼出来的，根本经不起业务核对。
真正的企业级落地，应该把RAG理解为一套数据链路工程：从源头数据收集，到格式解析清洗，到分块向量化入库，再到检索排序和模型生成，最后还要回答“我这个答案凭什么可信”。整个链路里任何一环偷懒，最终效果都会在问答质量上暴露出来。
1.3 整体链路与核心设计原则
我这套系统的整体链路可以概括为六个环节：
请求进入Agent后，先做意图识别和实体抽取，判断用户是想查结构化数据库、查文档，还是需要跨源联动。然后进入路由层，把问题分发给对应的工具模块。如果是数据库类问题，走“元数据检索 + SQL生成 + 安全执行 + 结果转写”的链路；如果是文档类问题，走“混合检索 + 重排 + 上下文拼装 + 生成回答”的链路。执行完成后，所有生成内容会经过一层“可校验性检查”，确保引用来源清晰可见。最后，整个过程的会话记录和中间日志统一入库，用于后续调优和审计。
这套设计背后有三条核心原则：
第一，先规划数据合规，再谈模型能力。企业数据能不能给模型看、哪些字段需要脱敏、哪些部门能查哪些表，这些问题必须在第一步就定义清楚，否则后面上线必然出事。
第二，先保证检索质量，再优化生成效果。RAG系统的效果上限由检索决定，生成只是把检索到的内容组织成自然语言。如果检索到的片段就是错的，模型再强也会一本正经地胡说八道。所以我做任何项目都会先反复测试召回质量，等召回的Top-5结果稳定了，才去调模型提示词。
第三，所有能力都留兜底。SQL生成失败要有降级方案，检索不到答案要明确说“不知道”，模型输出格式不对要能自动重试。一个成熟的Agent不是每次都能答对，而是每次答错都错得明明白白、可有迹可循地修正。
2. 工具链选型与关键取舍
2.1 向量数据库：四个维度的选型清单
向量数据库是整个RAG系统的基础设施。市面上的开源向量数据库产品已经不少，但我建议选型时别只盯着技术评测榜单，而是从下面四个维度去对照自己的场景。
第一是数据规模。百万级向量以内，轻量级方案足够；千万级甚至上亿级，就得考虑分布式架构和分片策略。我见过有团队一开始用轻量方案做PoC，数据量上来后查询延迟从几十毫秒飙到几百毫秒，最后只能整库迁移。
第二是检索性能与索引类型。重点看两个指标：召回率和写入吞吐。常见索引类型有倒排索引、HNSW、IVF系列，不同索引在内存占用、召回精度、写入速度上差异很大。HNSW效果好但内存占用高，IVF内存友好但召回参数需要调。建议用真实业务数据做压测，不要拿公开数据集的效果直接推论。
第三是部署方式。企业往往有内网隔离要求，必须选支持私有化部署的方案。还要关注有没有配套的权限控制、多租户隔离能力——很多企业级场景要求不同部门只能检索授权范围内的文档，这不是向量库的加分项，而是必选项。
第四是生态和运维成本。比如有没有现成的数据导入工具、监控面板、备份恢复机制。有些向量库功能很花哨，但生产环境要用时发现连基本的容量评估文档都不全，运维成本全堆在开发团队身上，得不偿失。
我给一个务实的建议：中小规模项目先选支持“嵌入式部署、可本地存储”的方案，让团队把精力集中在数据处理和问答质量上，等规模增长明确后再迁移也不迟。换向量库不是换内核，主要是换数据导入和检索接口，提前把数据层封装好能省很多事。
2.2 嵌入模型与生成模型怎么搭
嵌入模型负责把文本变成向量，它的效果直接决定检索质量。选嵌入模型我主要看三点。
一是语言效果。中文场景必须用中文语料表现好的模型，通用英文模型在中文语义上经常出现同义词匹配不上、专有名词检索不准的问题。二是向量维度和最大输入长度。维度越高单个向量越大，千万级数据下存储和检索成本都会猛涨；输入长度则限制了单次编码的文本量，对分块策略有直接影响。三是是否支持领域微调。如果项目有大量专业术语，我更倾向于选择允许在私有数据上继续训练的模型，实测下来比换更强的通用模型提升更明显。
生成模型的选择则和Agent的思维链路强相关。除了基础的问答能力之外，要注意三点：上下文窗口要够长，因为多轮问答的对话历史和检索片段都会占据token；指令遵循能力要强，因为Agent要按固定格式输出结构化内容，否则下游解析就崩；函数调用能力要稳定，因为在Route层要让模型决定调用哪个工具、传什么参数。
嵌入模型和生成模型的搭配没有固定公式，我更推荐在项目早期把API封装成可替换的接口，然后用同一批测试集分别跑几组“嵌入模型 + 生成模型”的组合，记录检索命中率和答案准确率。这个测试看起来费时间，但能帮你在一开始就找到适合本领域数据特征的最佳组合，后面所有调优都是在这个基础上做的。
2.3 编排框架用还是不用
现在有很多开源的Agent编排框架，能帮你快速搭建“加载文档、切分、向量化、建Agent、调用模型”的完整流程。我的态度是：PoC阶段可以大胆用，生产阶段要慎用。
为什么这么说？框架带来的最大价值是抽象和封装，你不需要关心底层细节就能跑通demo。但生产系统需要的是可控性：你要能精确控制每个环节的提示词、日志、并发策略和失败重试机制，而框架往往在这些地方做了“合理默认”，这些默认不一定符合你的业务约束。比如有些框架默认在检索不到结果时让模型“尽量回答”，这种设定在企业知识库场景里就是灾难。
如果你决定用框架，我建议至少做到两层隔离：第一层，把数据接入封装成独立模块，不依赖框架的数据加载器，这样即使将来换框架，数据管道不用重写；第二层，把检索和生成都包在自己定义的Service接口里，框架只负责流程编排，算法细节自己实现。我踩过最深的坑就是因为直接用了框架内置的检索组件，上线后发现它自动做了一些没有文档记录的后处理，导致排查问题的时候完全无从下手。
3. 多表问答的落地方法
3.1 Text-to-SQL的常见坑
多表问答的核心技术是让模型理解自然语言问题并生成SQL。直接让模型裸写SQL，看起来很简单，实际跑起来满屏都是坑。
第一个坑是幻觉表名和字段名。模型没见过的表结构，它敢编一个非常像真的字段名，查询一执行直接报错。第二个坑是业务语义混淆。比如“销售额”和“回款额”可能含义完全不同，但模型可能混用；“本月”在不同业务线里的口径可能是“自然月”或“财务月”，需要结合企业定义理解。第三个坑是复杂联表和多条件过滤容易出错。三张以上表关联时，模型可能漏关联条件或写错JOIN类型，导致结果错误甚至全表扫描。
所以我的基本判断是：Text-to-SQL必须做，但绝不是让模型自己随便写，而是要给它足够多的“领域约束信息”，并加上一条可靠校验链路。多表问答的难度不在生成SQL本身，而在如何让模型生成“符合这张表结构的、业务口径正确的、执行安全的SQL”。
3.2 元数据注入与检索增强
我给系统加的第一层保护，是为每张表建立“数据字典”，并把这些字典内容作为检索对象。数据字典里不只有表名和字段名，还包括：字段类型、字段注释、允许的枚举值、常用筛选条件、业务口径说明、表之间的关联关系，以及这条表/字段最近被查询得最多的SQL示例。
举个例子，一张订单表里有个字段叫“status”，注释写的是“状态”，这信息量太弱了。我在数据字典里会补充一句：status取值0表示待支付、1表示已支付、2表示已取消；同时补充一条示例SQL，把“查未支付订单”映射成“WHERE status = 0”。这样模型看到问题时能基于“描述”而不是“猜测”生成SQL，命中率会明显提升。
数据字典的维护本身也是动态的，我建议用元数据表统一管理，定期同步建表语句、字段注释和业务团队提供的口径说明。同时，在Agent接收SQL相关问题时，先用向量检索找到最相关的几张表和字段说明，再把这些元数据片段和问题拼在一起交给模型。这一步很像文档问答里的“先检索再回答”，只不过检索的对象从文档片段变成了表结构说明，我把这个方案称为“元数据增强的Text-to-SQL”。
3.3 安全执行链路与兜底策略
SQL生成之后，不能直接丢给数据库执行。我在这套系统里设计了一条多层校验的链路。
第一层是语法和模式校验。检查SQL里是否包含多语句拼接、非查询语句（INSERT、UPDATE、DELETE、DROP等）、注释符号绕过。这一步至少要拦截掉大部分恶意或误写的SQL。第二层是只读事务封装。所有查询都在只读事务中执行，从数据库权限层面禁止写操作。第三层是资源保护。强制加上查询条数上限（比如LIMIT 200），超时时间设置到秒级，防止模型生成全表扫描或笛卡尔积把数据库拖垮。第四层是结果校验。如果查询结果为空，系统要能区分“表里确实没数据”和“SQL条件写错了”，必要时用更宽的口径重跑一遍。
还有一个容易被忽略的点：执行结果返回给模型转成自然语言时，要在期间保留对应的SQL和查询结果来源。这样用户追问“这个数字是怎么算出来的”时，系统可以直接翻出当时的SQL和查询条件。企业里最怕的不是答错，而是答错了还没法复盘。我这套系统上线后，业务方至少有一半的反馈是“要能让我看到口径”——所以从一开始就把查询痕迹留全，能省掉无数扯皮。
4. 多文档问答的落地方法
4.1 文档解析：从杂文件到干净文本
多文档问答的第一步不是向量化，而是把文档变成“干净的、结构完整的文本”。这一步的复杂程度被很多人低估了。
现实里的企业文档长什么样？有的是扫描版PDF，文字层完全不存在，必须先做OCR；有的是Word排版极其混乱，标题靠加粗和字号区分，目录还是手工录入的；有的是Excel里的制度说明，一个单元格塞了三四页文字，还得处理合并单元格。如果把这些问题文件直接切块向量化，检索出来的一定是乱码或结构错乱的内容。
我的处理流程是：先用文档解析组件识别文件类型，分类走不同通道。PDF类优先提取文字层，如果没有就调用OCR引擎；Word类解析时保留标题层级和段落关系；Excel类按单元格区域拆块，把合并单元格展开。解析完成后再做一轮清洗：去掉页眉页脚、移除重复空行、修正OCR常见的错别字和乱码符号、把表格内容转成Markdown或JSON结构。这些清洗规则看起来琐碎，但决定了后续检索质量的上限。
如果你所在的行业有大量专业术语和特殊符号，清洗规则还要再做定制。比如化学式、产品型号、金额单位，OCR很容易识别成奇怪的组合，这些都要在清洗阶段处理。解析这块没有捷径，只能靠拿真实文档反复跑、反复修规则，逐步积累一份属于你自己业务的“文档清洗规则库”。
4.2 分块策略与向量化参数
文档清洗干净之后，进入分块环节。分块这件事的影响比大多数人想象的要大得多：块太大，检索结果不够精准，模型上下文塞得太满；块太小，语义不完整，模型没法理解上下文。
我常用的分块原则是按文档结构来切，尽量别用死板的固定字符数切割。先用标题层级识别分出章节，再在章节内部按段落和主题句切分，同时保留每个块的血缘信息——它属于哪个文档、哪个章节、父标题是什么。这样检索到某个块的时候，可以顺便带上它的上级标题和邻近段落，让模型有完整的上下文。
具体参数一般从chunk_size 512到1024（按字符或token算都行）、overlap 50到200起步，用你业务里的典型问题做检索验证，看哪种参数组合能让答案分布更集中在正确的块上。我见过一个比较麻烦的场景：文档里大量使用表格表达数据，分块时如果表格被切开，检索命中率会明显下降。这时候我会把表格整体作为一个独立的块优先保留，必要时单独为表格建立结构化的键值索引。
分块之后是向量化入库。每个块除了文本内容和向量，我还会存储文档ID、章节路径、更新时间、权限标签等元数据。这些元数据在后续过滤和溯源时非常重要，很多团队忽略这一步，后面做权限控制和来源展示时才发现没有数据可用，只能重新跑一遍入库流程。
4.3 混合检索与重排
纯向量检索在处理企业文档时有明显的盲区：专有名词、缩写、编号经常匹配不到，比如用户搜“差旅标准”，文档里写的是“出差费用管理办法”，向量相似度未必排得上Top-10。所以我强烈建议用混合检索：向量检索负责语义相似，关键词检索（BM25这类传统方法）负责精确匹配，两者结果合并后统一排序。
合并之后还要做一波重排。为什么要重排？因为向量检索和关键词检索各自返回的候选集，相关度并不完全等于问题所需，直接取并集前K个很可能混入一堆低相关度内容。重排模型的思路是：把问题和候选片段两两输入一个专门的排序模型，由排序模型输出相关性分数，再按分数重新排序。这一步会显著提升Top-5的命中质量。
我实测过的经验是：加了重排之后，答案正确率提升在10到20个百分点之间，尤其是问题表述和文档原文差异比较大的情况，改善非常明显。代价是每次查询多一次模型调用，延迟会增加几百毫秒到一两秒。企业场景如果对实时性要求高，可以把重排做成异步或对Top-20结果做粗排再精排，由性能和效果之间取平衡。
多文档还有一个特殊问题：多份文档对同一问题可能有冲突说法。比如一份制度说“补贴上限500元”，另一份手册说“补贴上限800元”，这时模型要能识别出冲突，而不是随便挑一个。我的做法是在生成阶段把多份相关文档的摘要并列展示，并让模型标注“根据某文档某章节规定……”以及“不同文档之间存在差异，建议人工核实”。企业知识库问答的价值很大程度体现在这种“不装懂、直接标冲突”的诚实性上。
5. 多轮问答与记忆管理
5.1 会话记忆的结构设计
多轮问答的实现基础是会话记忆。最朴素的做法是把整个历史对话一股脑塞进模型上下文，但企业场景里对话会越来越长，token成本成倍上涨，而且模型对过长的历史往往抓不住重点。
我建议把记忆拆成两层：短期记忆和长期记忆。短期记忆对应当前会话，保存最近几轮的用户问题、系统回复、检索到的关键片段和查询结果；长期记忆对应同一用户跨会话的偏好和常用实体，比如用户经常查询的区域、部门、关心的指标口径。短期记忆用会话ID关联，长期记忆用用户ID关联，各自存到独立的存储表里，提供查询和清理接口。
关键是记忆不只要存内容，还要存结构化元数据。每一轮对话记录里，除了问题和对答，至少要包含当时的意图类型（数据库查询、文档检索、跨源联动）、引用了哪些文档块或表结构、执行过什么SQL。这样当用户说“把刚才那个数再算一遍，但换成西南区”时，系统能精确知道“刚才那个数”是哪个指标，而不是从几轮前的长文本里模糊猜测。
5.2 问题改写与上下文压缩
多轮问答里最常见的坑是指代词问题。用户问“它的库存还有多少”，这个“它”指的是上一轮提到的那款产品；“那条规定再说一下”，指的是三轮前的某条政策。如果把原问题直接丢给检索和SQL生成，系统根本不知道在问什么。
所以我在每次查询前都会先做一步“问题改写”：把当前问题连同最近几轮的核心摘要喂给模型，让它输出一个“可独立查询的完整问题”。比如“它还有库存吗”会改写成“某产品在当前仓库的库存数量是多少”。改写之后，下游检索和SQL生成就不用再关心上下文关系，整个流程大幅简化。
上下文压缩则是控制token成本的手段。对话越长，历史越不能全部保留。我采用的方案是实时摘要：每两到三轮对话结束后，就把前面的核心信息压缩成一段摘要，存到短期记忆里作为后续改写的上下文。这个摘要不需要包含所有细节，只保留当前用户关心的实体、指标和约束条件。压缩策略调好之后，即使会话长达几十轮，改写模块看到的上下文也不会超过一定长度，且关键信息不会丢。
5.3 跨数据源的多轮联动
多轮问答真正的高级形态，是在同一个会话内完成“文档查政策、数据库查数据、结合两者给结论”的跨源推理。
举个例子：用户先问“报销差旅费的额度是多少”，系统在文档库中检索到制度条款；接着追问“我上个月的报销总额是多少”，系统识别到用户想查个人客观数据，自动走到数据库链路查询报销明细表；再追问“那我超标了吗”，这时系统需要结合第一轮的文档额度和第二轮的报销总额做比较，给出结论。第三步的难度不在查数，而在“自动判断要同时使用文档结果和数据库结果”。
我实现跨源联动的方法是：在Agent里维护一个“当前会话知识状态”，记录每轮引用过的文档块和查询结果。当新问题进来时，除了做意图识别，还会做一次“依赖检测”——判断这个问题是否引用了之前轮次的输出。如果依赖检测通过，系统会自动把相关历史片段和当前查询结果放进生成上下文，让模型基于完整资料回答。这个方案初期误判不少，后来我把依赖检测改成“显式引用识别 + 实体重叠判断”双通道，准确率才到可用水平。
跨源联动对提示词的要求也更高。我会在系统提示词里明确告诉模型：如果没有找到明确的比较依据，必须回答“暂无法判断”，而不是自行假设。企业场景下，一个模棱两可的错误结论比“不知道”的危害大得多。
6. 全流程实操：一步步搭起可运行Demo
6.1 初始化工程与依赖
上面讲了这么多设计思路，下面把一套完整可运行的Demo流程走一遍。先说技术栈选择：语言用Python，数据处理和模型调用生态最全；向量库选一个支持本地嵌入式的开源方案，方便快速起步；Agent编排组件可以选主流框架，但按前面说的，检索和生成逻辑要自己包一层Service。
工程初始化部分，我建议先建立三个目录：data目录放原始文档和表结构元数据；core目录放检索、向量化、SQL生成、记忆管理等核心模块；api目录放对外接口和会话管理。目录划分清晰的好处是，后续加新数据源、换模型、加权限控制时不用拆散原有代码。
依赖安装主要是三个层面：文档解析相关、向量库客户端、模型SDK。文档解析要特别留意系统级的OCR依赖，有些环境需要额外安装系统库才能调用，这一块很容易在部署时踩坑。安装完成后，先跑一个“空数据查询”的冒烟程序，确认向量库能连通、嵌入模型能返回正确维度的向量，再开始灌数据。
6.2 数据侧：文档入库与表结构注册
文档入库的代码逻辑可以抽象为这样一个流程：读取文件 → 解析清洗 → 分块 → 生成向量 → 写入向量库。为了便于复现，我把核心逻辑抽成下面这段示意代码：
from pathlib import Path def ingest_documents(doc_dir: str): for file_path in Path(doc_dir).glob("*.pdf"): # 1. 解析：按文件类型走对应解析器 doc = parse_document(file_path) # 返回干净的markdown文本 # 2. 分块：按章节和段落切分，同时保留元数据 chunks = split_by_structure(doc, chunk_size=768, overlap=128) # 3. 向量化并写入 for chunk in chunks: vec = embedding_model.encode(chunk.text) vector_store.insert( text=chunk.text, vector=vec, metadata={ "doc_id": doc.doc_id, "chapter": chunk.chapter, "permission": doc.permission_label, } )表结构注册要走另一条链路：读取数据库系统表里的字段注释和类型，再加上业务方维护的业务口径文档，组合成“数据字典条目”，作为SQL生成时的检索素材。我建议把每条数据字典单独作为一个文档单元写入向量库，它的metadata要带明确标识（比如source_type=dictionary），这样在检索时可以区分是“文档内容”还是“元数据字典”。
6.3 Agent侧：路由、检索与生成主流程
Agent主流程的核心是一个“意图路由函数”。它的输入是改写后的独立问题，输出是一个结构化的执行计划：该走文档链路、数据库链路，还是跨源联动。代码示意大致是这样：
def agent_route(query: str, history: list): plan = llm.classify( query=query, history=history, tools=["document_search", "database_query", "cross_source"], schema="""{"intent": "...", "target_tool": "...", "dependency": ["..."]}""" ) if plan.target_tool == "document_search": return document_answer(query) elif plan.target_tool == "database_query": return database_answer(query, history) else: return cross_source_answer(query, history)文档链路内部是混合检索加生成的组合。数据库链路内部是“检索数据字典 → 生成SQL → 多层校验 → 执行 → 结果转自然语言”。两套链路都返回统一的回答结构：主文本、引用来源列表、置信度标记。
对外接口部分，我直接用异步接口暴露问答能力，同时维护会话表。会话表的核心字段包括：会话ID、用户ID、当前意图、最近一次检索片段、最近一次SQL及查询结果、核心摘要。每次问答结束会更新会话状态，这样下一轮依赖检测才有依据。
6.4 实测效果与调参记录
Demo跑通之后，我通常会用一组标注好的业务问题做回归测试。测试集规模不需要很大，但一定要覆盖三类问题：单轮文档题、单轮数据题、跨源多轮题。每道题记录三个指标：检索命中位置、生成答案是否正确、延迟。
我在一次典型调参里发现，文档分块大小从512调到768后，问答正确率反而下降了5个百分点。原因是这个场景里的文档段落普遍较短，切大块把不同主题的内容塞进了同一个块，导致检索时相关度被稀释。后来我把chunk_size改回512，同时增加overlap到96，效果才恢复。这说明参数调优必须以真实文档结构为准，不能照搬任何经验值。
另一个实测印象深刻的点是重排的收益。在某批测试题上，不加重排时正确率只有68%，加重排后到84%。但重排也把单次查询的延迟从800毫秒拉到了1.6秒。后来我用“Top20重排取Top5”代替“所有候选重排”，延迟降到1.1秒，正确率依然有82%。这个平衡点值得大家在各自数据上多测几组。
7. 高频问题排查与避坑实录
7.1 检索召回不准怎么定位
系统上线后最常见的抱怨就是“回答不对，查的文档不对”。遇到这类问题不要先调模型提示词，先检查检索链路。
我习惯按这样的顺序排查：第一步看召回片段与原问题是否相关。如果不相关，多半是嵌入模型对这块业务语言理解不够，或者分块粒度不合适。第二步看混合检索比例。把关键词检索和向量检索的结果分开打印，对比是哪种检索拖了后腿，再调整权重。第三步看是否被权限过滤误伤。企业文档往往有权限标签，如果检索时把不可见内容全过滤掉，可能导致Top结果全是低相关的可见内容，这时候要检查过滤逻辑是不是太严格。
排查这类问题一定要做好可观测性。我在这套系统里给每次检索都打印了完整的trace：查询改写后的文本、混合检索的前20条候选及分数、重排后的前5条结果。没有这些日志，你只能对着错误答案靠猜，效率极低。可观测性不是上线后补的，是开发阶段就应该内建的。
7.2 生成结果不可信怎么校验
RAG系统最怕“一本正经地胡说八道”。模型可能把检索到的片段和它自身知识混在一起，生成一段看起来很有道理、但业务上完全错误的回答。
我的应对措施是强制溯源和内容对齐。在提示词里要求模型每个结论都要标注引用来源，引用的必须是检索片段里的原话，而不是自己发挥。系统层面再加一道“引用匹配校验”：生成答案后，把答案里的关键实体和数字与检索片段做一致性比对，如果某句结论找不到对应证据，就标记为“低置信度”或触发重生成。
还有一个容易忽视的点：模型如果检索到的片段本身冲突，或者数据表里存在脏数据，答案质量无论如何提升不上去。这种情况需要把问题反馈给数据侧，而不是在算法侧硬扛。定期做数据质量审计，把常见的脏数据形态（重复记录、空值过多、口径不一致）整理成清洗规则，比调任何参数都有效。
7.3 性能、成本与安全合规
性能方面，我建议优先做缓存优化。问题改写结果和检索结果都可以按“问题哈希 + 数据版本号”做缓存，相同或相似问题直接命中，延迟能降一半以上。向量检索本身也要关注索引类型，数据量上来后选HNSW这类索引并调好efSearch参数，能显著控制延迟。
成本方面，最大开销通常是模型token消耗。除了缓存，还可以做“分层模型策略”：简单问题用轻量模型回答，复杂问题才调用更强的模型。另外，对话历史的摘要压缩也是省token的重要手段，前面讲过的上下文压缩策略，在控制成本的同时还能避免长上下文导致的效果衰减。
安全合规这块，我必须提醒三件事：一是所有查询操作要留审计日志，包括用户、时间、问题、生成的SQL、检索到的文档和最终答案；二是敏感数据脱敏必须在数据入库前完成，不能依赖模型在生成阶段“自觉不提”；三是权限控制要贯穿整个链路，从检索数据源到生成结果展示，每一层都要校验用户的可访问范围。很多团队只在接口层做登录校验，结果用户通过对话间接套出了无权限的数据，这种事故一旦发生就是合规层面的严重问题。
最后分享一点个人体会
这套系统从第一个能回答单文档问题的版本，到稳定支撑多表、多文档、多轮跨源问答，中间改动最大的一版并不是模型选择，而是把整个链路从“一把梭生成答案”改成了“检索、生成、溯源分离”的管线式架构。改动之后，模型的每句话都有了出处，业务方也终于愿意在正式环境试用。其实企业级AI Agent的成败，往往不取决于模型能多聪明，而取决于你有多愿意在数据清洗、元数据维护、权限控制和日志审计这些“不性感”的环节上花功夫。
最后再分享一个小的落地技巧：给Agent设计一套“我不知道”的标准回复模板，明确告知用户“当前知识库中暂未检索到相关依据，建议补充资料或咨询人工”。这套模板看似不起眼，但在企业环境中极大减少了模型硬编答案造成的信任损失。没有哪个系统一出场就是完美的，能在不知道的时候坦然说不知道，才是企业级AI Agent真正走向可用的第一步。
