AI Engineering / AI 工程

RAG 与 Agent 工程化：把大模型接进业务系统

RAG 不是“向量库 + 大模型”，Agent 也不是“让模型自己调工具”。真正决定效果的，是数据管道、检索质量、权限边界和评测闭环。

过去几年，很多 AI 项目停在演示阶段：文档上传、提问、模型给出看起来很专业的回答。但一进入生产，问题就出现了——答案没有出处、权限越界、延迟不稳定、成本不可控、出了问题无法回滚。要把大模型接进业务系统，需要把它当成一个完整的工程系统来设计，而不是一次 API 调用。

一、先判断场景是否真的需要大模型

大模型擅长处理非结构化信息、语义理解和生成；不擅长精确计算、强规则判断和没有数据支撑的推理。适合的场景通常具备三个特征：输入是非结构化文本、输出允许一定弹性、有人可以最终确认。比如知识问答、工单辅助、文档摘要、信息抽取、内部搜索。

反过来，账务计算、库存扣减、权限判定这类强一致性场景，应该继续用确定性代码。大模型可以参与“理解和解释”，但不能替代事务和规则。

二、数据管道决定 RAG 的上限

很多 RAG 效果不好，不是模型不行，而是数据没有处理好。一个可用的数据管道至少包括：

• 解析：PDF、Word、HTML、扫描件分别处理；扫描件需要 OCR，表格要保留结构。
• 清洗：去页眉页脚、去重复、修正断行，保留标题层级。
• 切分：按语义和结构切，而不是固定字数硬切；块之间保留少量重叠。
• 元数据：来源、章节、更新时间、密级、可访问角色，这些字段后面会决定检索和权限。
• 增量与删除：文档更新要能重建索引，文档下线要同步删除，否则会一直召回过期内容。

如果知识库本身有大量重复、过期和互相矛盾的内容，再强的模型也只能给出“看起来很合理”的错误答案。数据治理是 RAG 的前置条件。

三、检索：混合召回与重排

纯向量检索擅长语义相似，但对专有名词、编号、精确短语不敏感；BM25 擅长关键词，但不懂同义表达。生产系统通常采用混合检索：一路关键词召回，一路向量召回，合并后用重排模型排序。

几个关键动作：

• 查询改写：把口语问题改写成更适合检索的查询，但不要改变用户意图。
• 元数据过滤：先按租户、时间、文档类型、权限过滤，再做相似度计算，既快又安全。
• 重排：用小模型对候选块做精排，通常比单纯扩大 top-k 更有效。
• 引用：返回答案时带上文档名、章节和链接，方便用户核对。

四、生成：引用、结构化输出与兜底

生成层要解决三件事：答案有依据、格式可消费、失败可兜底。提示词里明确要求“只根据给定资料回答，资料不足时说明不足”，并在返回结构中带上引用片段。对于需要进入业务系统的结果，使用 JSON Schema 约束输出，避免下游解析失败。

还要考虑上下文长度和噪声。把所有召回块一股脑塞进上下文，既贵又容易让模型抓错重点。控制块数量、去重、按相关性排序，比单纯堆上下文更有效。

五、Agent 的边界：工具、权限与人工确认

Agent 的本质是“模型决定下一步调用什么工具”。一旦接入真实系统，风险就从“答错”变成“做错”。因此需要明确边界：

Agent 适合“检索 + 草稿 + 建议”这类可回退的流程；对于付款、删除、发布等不可逆动作，必须有人工确认和审计。

六、推理部署与成本

推理层要根据延迟、并发和成本选择方案。常见做法是用 vLLM 这类推理框架做连续批处理，配合量化和 KV Cache 优化；小模型处理高频简单任务，大模型处理复杂推理，通过路由控制成本。上线前要压测首 token 延迟、吞吐和显存占用，并准备降级策略：模型超时后回退到检索结果或模板回答。

七、评测、灰度与反馈

没有评测的 AI 系统无法迭代。离线阶段准备一批真实问题，分别评估检索召回率、答案忠实度、格式正确率和平均延迟；在线阶段通过灰度发布观察采纳率、追问率、差评率和人工修正率。每次调整切分、提示词或模型，都要用同一套评测集回归，避免“感觉变好了”但整体退化。

八、安全与权限

权限必须在检索层做，而不是靠提示词约束模型。用户只能召回自己有权访问的文档，答案里的引用也必须经过权限校验。日志中避免记录敏感原文，必要时做脱敏；对外部内容保持警惕，防止提示词注入把系统指令带偏。

九、落地顺序

1. 选一个边界清楚、有人工兜底的知识问答场景。
2. 先解决数据解析、切分和权限，再调模型。
3. 建立最小评测集，把检索和生成分开评估。
4. 上线灰度，收集反馈，逐步扩展到 Agent 和自动化流程。

小结

RAG 和 Agent 的工程化，本质上还是软件工程：数据质量、权限边界、失败处理、可观测性和评测闭环。模型会不断更新，但这些基础设施决定了一个 AI 系统能不能长期稳定地产生价值。