构建企业级 RAG：从七类失败点到可运营架构

原文来源：Mastering RAG: How To Architect An Enterprise RAG System，作者 Pratik Bhavsar，Galileo Labs，2024 年 1 月 23 日。

做一个能运行的检索增强生成演示并不难：把几份文档切成片段、编码成向量、取回最相近的段落、塞进提示词，再让语言模型回答。企业级 RAG 面临的却是另一类问题。系统必须识别用户，执行租户与文档权限边界，拒绝不安全的输入，改写不完整的提问，选择合适的嵌入模型，接收多种格式的文件，持续更新索引，在真实成本与延迟约束下选择向量数据库，改进检索质量，检查生成结果，从反馈中学习，保留调用链路，缓存昂贵工作，并在上线后保持可观测。

最核心的结论是：检索质量不由向量数据库单独决定，而是由一条决策链共同决定。正确的答案可能因为没有入库而消失，可能因为排名落在前 K 个之外而没有被使用，可能在上下文整理时被丢掉，可能被噪声干扰后无法提取，也可能因为提示词没有规定输出形式或具体程度而失去价值。面向生产环境，必须设计完整链路，并定位失败发生在哪一段。

本文先从三个真实的 RAG 系统出发，归纳七类常见失败点，再逐一拆解企业级架构中的组件。最后重点讨论检索改进、输出控制、持续评估与多租户隔离。这些内容经常被当作上线后的附加项，但它们实际上决定了 RAG 产品能否安全、稳定地长期运行。

三个案例揭示了什么

2024 年的一项研究考察了三个不同领域的 RAG 系统：面向科研工作的认知审阅器、面向教育场景的 AI 导师，以及生物医学问答系统。三者在领域、文档格式和用户群体上完全不同，却出现了相似的失败方式。这说明问题往往来自架构，而不是某一个应用里的偶发缺陷。

系统与领域	源材料	研究中的规模	涉及的 RAG 阶段	代表性问题
认知审阅器 科学研究	大小不一的研究论文 PDF	任意规模的论文集合	切分、排序、查询改写	上传的论文涵盖了哪些关键内容？
AI 导师 教育	视频、HTML 与 PDF	38 份文档	切分、改写、检索、阅读器	第六周讲了哪些主题？
BioASQ 生物医学问答	生物医学科学论文 PDF	4,017 份文档	切分、检索、阅读器	培美曲塞会导致脱发吗？如何处理？

认知审阅器

认知审阅器帮助研究者分析大量论文。研究者先定义目标或研究问题，再上传一批相关论文，系统按照该目标为论文排序，让研究者优先阅读最相关的材料。它同时支持直接针对整个文档集合提问。这个设计最值得注意的地方在于，系统首先输出的不是合成结论，而是一个按相关性组织的阅读界面。检索先用于引导人的注意力，之后才被允许生成研究性判断。

AI 导师

AI 导师根据课程单元的学习材料回答学生问题，并展示来源列表，方便学生核对答案。它被集成进迪肯大学的学习管理系统，索引了 PDF、视频和文本文档。视频内容先由 Whisper 转写成文字，再进入切分流程。查询改写器会把追问改写成更完整的检索问题，聊天界面则利用之前的多轮对话理解当前请求。这个案例说明，多模态数据必须先经过归一化：无论来源是视频还是网页，下游系统最终都需要能够被搜索的文本表示。

生物医学问答

生物医学系统使用 BioASQ 数据集，其中包含问题、支持文档链接和专家编写的答案。答案类型包括是或否、摘要、事实型答案和列表。答案形式如此多样，意味着只针对流畅长文优化的系统很容易失败。用户需要二元判断、排序列表或精确事实时，生成器必须遵守相应输出结构。预期格式不是最后才加上的排版偏好，而是检索和生成规格的一部分。

RAG 的七类失败点

这七类失败点构成了一套实用的诊断顺序。每一个问题都在追问证据究竟在哪一步丢失：语料里是否存在，是否被检索到，是否进入了模型上下文，是否被提取，最终是否以用户需要的格式和具体程度表达出来。与把所有错误都笼统称为幻觉相比，这种拆分更利于定位和修复。

失败点	具体表现	常见原因	生产环境中的应对
FP1：内容缺失	语料中根本没有答案。	采集不完整、来源不可访问，或问题超出系统范围。	识别不可回答的问题并明确说明，同时补齐数据，而不是鼓励模型猜测。
FP2：漏掉高排名文档	答案存在，但对应片段落到前 K 个结果之外。	编码器较弱、查询含糊、切分边界不合理，或 K 值设置不当。	衡量前 K 个结果的召回率，测试查询改写与混合检索，重排候选并依据评测调 K。
FP3：未进入上下文	文档已经检索到，却在整理或拼接上下文时丢失。	候选太多、压缩过猛，或筛选规则误删了真正有用的段落。	追踪实际送入模型的上下文，显式控制上下文预算，保留来源到提示词的链路。
FP4：未能提取	答案就在上下文中，模型却没有找到。	噪声过多、证据冲突、指令较弱，或生成器无法区分证据与干扰内容。	清理并去重上下文，增加基于证据的提取提示，并把生成器评测与检索评测分开。
FP5：格式错误	事实都在，但没有按要求输出表格、列表或结构化字段。	提示词未说明格式、格式要求含糊，或测试集中没有对应案例。	明确结构定义，用程序校验结果，并加入针对输出格式的测试。
FP6：具体程度错误	答案过于笼统或过于狭窄，不符合用户所处情境。	系统无法判断用户身份与目标，或用户的问题过于模糊。	澄清任务，可靠地利用对话上下文，并把证据与面向特定读者的解释分开。
FP7：答案不完整	内容正确，却漏掉上下文中本来存在、用户也要求的信息。	复合问题一次包含多个对象，或模型找到第一项后就停止。	拆分多部分问题，跟踪每个必要子答案，并单独评估完整性。

这些失败点给出了一条重要的评估原则：不能只给最终答案打分。系统还需要记录关键证据是否被索引、是否进入候选集、是否在排序和上下文整理后保留下来，以及生成器是否成功提取。没有这些中间观测，团队可能在解析器已经漏掉表格时反复修改提示词，也可能在真正的问题是权限过滤时错误地更换向量数据库。

企业级 RAG 的整体架构

企业级架构同时包含两条数据流。索引流负责采集文档、解析与补充信息、切分片段、计算嵌入并写入搜索记录。查询流负责认证用户、检查输入、改写问题、编码查询、过滤并检索候选、重排与拼接上下文、生成答案、检查输出，以及记录交互用于反馈。

flowchart LR
    U[用户] --> A[身份认证与租户范围]
    A --> G1[输入护栏]
    G1 --> Q[查询改写]
    Q --> E[编码器]
    E --> R[租户过滤后的检索]
    R --> RR[重排与多样性筛选]
    RR --> C[上下文整理]
    C --> L[语言模型生成]
    L --> G2[输出护栏]
    G2 --> O[带引用的答案]
    O --> F[反馈与调用链]

    D[文档与媒体] --> P[解析与光学字符识别]
    P --> CH[文本切分]
    CH --> V[嵌入与索引]
    V --> R
    P --> S[原始文档存储]
    F --> M[评估与改进]
    M --> P

这张图适合用来划分控制面，但不应被理解成一家供应商会提供所有方框。认证、存储、索引、模型服务、评估和可观测性可能由不同系统承担，也各自有独立的故障模式。只有当身份、访问范围和文档来源关系能够穿过每一个系统边界时，这套架构才是可靠的。

用户认证与访问控制

认证是整个系统的第一道组件，因为匿名检索系统无法安全判断当前请求应该看到哪些文档。在企业部署中，认证要同时满足六个相关目标：

• 访问控制：只有被授权的用户才能使用系统并执行允许的操作。
• 数据安全：机密信息不会暴露给未获授权的个人或进程。
• 用户隐私：个人信息与账户资料只对目标用户可见。
• 合规要求：受监管组织能够证明访问控制符合其法定义务。
• 责任追踪：系统中的动作能追溯到具体用户，用于审计与事故调查。
• 个性化：系统可以调整内容和偏好，同时不把不同用户的数据混在一起。

AWS Cognito 或 Firebase Authentication 之类托管身份服务可以处理注册与身份验证，但认证并不等于授权。检索层仍然需要从可信身份中得出租户范围和权限范围。把用户编号写进聊天提示词不是访问控制机制，因为模型可能复述它、忽略它，或者被检索文本中的恶意指令操纵。

输入护栏

输入护栏在请求进入检索或生成之前保护系统。大语言模型可以被越狱，企业接口还面临数据泄露、注入攻击、资源耗尽与政策滥用等风险。原文建议分别处理以下几类输入：

• 匿名化与脱敏：在存储或发送到外部服务前，移除姓名、地址、联系方式等个人身份信息。
• 限制危险子串：拦截可能用于 SQL 注入、跨站脚本或其他注入攻击的模式。
• 限制主题：拒绝仇恨、歧视、色情或其他不允许讨论的内容。
• 限制代码：防止可执行代码进入可能破坏系统安全的处理路径。
• 检查语言：当下游模型只支持特定语言或文字系统时，先验证输入语言。
• 检测提示注入：识别试图覆盖系统指令、让检索内容接管模型行为的输入。
• 限制令牌数量：设置输入长度上限，避免资源耗尽和拒绝服务攻击。
• 检测有害内容：拦截侮辱、威胁和虐待性语言，同时记录策略判定。

Llama Guard 可以作为策略分类器，自行部署或通过托管服务使用，但不能把它当成完美的毒性检测器。护栏需要校准、明确失败策略，并持续监控误报和漏报。应用还必须把检索到的文档视为不可信输入。即使用户问题本身无害，恶意文档也可能携带指令注入。

查询改写

用户的查询常常很短、含糊，或者依赖上一轮对话。查询改写器要把这种自然语言请求转换为适合检索的文本。原文介绍了三种常见方法。

依据对话历史改写

对话中的问题可能省略主语，因为双方都知道正在讨论什么。例如历史依次是“你有几张信用卡？”、“白金卡和金卡有年费吗？”以及“比较两者的功能”，检索系统必须先解决“两者”指代什么，才能开始搜索。改写后的问题应当是“比较白金信用卡和金卡的功能”。

这一步还要区分长期偏好和临时上下文。如果改写器注入了错误的旧主题，检索就会非常自信地返回无关内容。生产系统应同时保存原始问题、改写后的问题和所使用的历史窗口，以便复现失败。

生成子问题

复合问题很难靠一次向量搜索完成。“比较白金卡和金卡的功能”包含两个对象和一个比较操作。子问题查询引擎可以把它拆成“白金信用卡有哪些功能？”和“金卡信用卡有哪些功能？”，分别检索证据，再由生成阶段进行比较。

子问题也能处理 FP7。如果用户要求总结文档 A、B、C 的关键点，单次检索很容易过度偏向其中一份文档。分别检索并检查每个子答案是否齐全，可以让遗漏变得可观察。

生成相似查询

语义检索和词法检索都可能因为用户措辞不同而错过相关文档。改写器可以生成同义表达或领域内常用说法。例如“我想了解白金信用卡”可以变成“介绍一下白金信用卡的权益”。系统可以融合多组候选结果，也可以分别评估，但必须去重，并保留真正支持答案的来源。

选择编码器

编码器把文档和查询转换成向量。它是整个系统中影响最大的选择之一，因为检索两侧通常必须使用同一个模型表示。高分基准只是决策起点，不能代替实际评估。

以 MTEB 作为筛选工具

Massive Text Embedding Benchmark 对不同嵌入模型的任务表现、向量维度、检索能力和模型规模做了广泛比较。它可以缩小候选范围，也能发现与商业接口水平接近的开源模型。但它无法证明某个模型最适合特定企业语料。基准训练数据可能与企业领域不匹配，模型文档可能不完整，综合分数也可能掩盖某一种关键文档类型上的弱点。

因此，应把 MTEB 当作初筛。最终候选模型必须在具有代表性的文档和真实用户问题上测试。

建立自定义评估

原文给出三种在真实领域内评估编码器的方法：

1. 人工标注：建立专门的检索数据集，由专家给出相关性金标签，再用平均倒数排名、归一化折损累计增益等指标比较模型。
2. 模型辅助评估：使用大语言模型或交叉编码器生成候选排序，先比较多个编码器，再人工检查最强的少数候选。适合标注成本过高的情况。
3. 聚类评估：观察不同 Silhouette 分数下被聚类的数据比例，并尝试 HDBSCAN 等算法。嵌入分布可以反映模型是否能以有用方式组织领域概念。

三种方法回答的问题不同。人工标注衡量相关性，聚类揭示数据结构，模型辅助排序则更快地找到值得人工检查的候选项。任何方法都不能脱离样例检查单独使用。

评估运行成本与约束

选择编码器同时也是系统设计决策：

• 查询成本与可用性：托管接口免去模型部署工作，但形成外部依赖；开源模型则需要与其规模匹配的 CPU 或 GPU 容量。
• 索引成本：每份文档都要编码，重建大型语料非常昂贵。应单独保存嵌入，使向量数据库能够重建，而不必重复计算未变化的向量。
• 存储成本：向量存储量随维度和语料规模增长。选择高维模型前，要估算每份文档的平均索引单元数量。
• 检索延迟：语义搜索延迟通常随嵌入维度增加，向量更大并不意味着检索收益更高。
• 语言支持：跨语言搜索需要使用多语言编码器，或在流程中加入翻译步骤。
• 隐私与合规：金融、医疗等敏感领域可能不允许把文本发送给外部嵌入服务。

因此，编码器选择应被记录成一项架构决策，包括候选模型、评估集、实测召回率与延迟、部署方式、隐私限制，以及在什么条件下重新评估。

文档采集与解析

文档采集把原始材料转化为可检索记录。每份文档需要经过解析、切分、编码，并把片段、原始内容和元数据一起写入索引。如果这条流水线漏了表格、误读扫描页或丢掉章节，后续提示词工程无法恢复缺失的证据。

文档格式

解析器必须处理 PDF、文字处理文件、电子表格、HTML 以及组织使用的其他格式，还要保留链接、多媒体引用、批注、表格和标题等有意义的嵌入内容。只返回一段扁平文本的提取器，可能恰好丢掉理解财务表格或技术规格所需的结构。

表格识别

报告、论文和运营文档经常把关键事实放在表格里。解析器应提取单元格、表头、行列关系和表格级元数据。Table Transformer 之类的模型可以帮助识别表格结构。检索表示也需要保留足够结构，让生成器能够引用正确行，而不是把一组单元格揉成无法核对的长句。

图像与光学字符识别

扫描页、示意图、截图和纯图片 PDF 需要光学字符识别。提取的文本应与页码和区域元数据关联，使引用能够回到原始来源。医疗、制造等领域尤其要测量识别错误，因为一个字符的偏差就可能改变药物名称、零件编号或数值结果。

元数据提取

元数据描述文档本身，包括作者、创建日期、文档类型、关键词、访问组、租户等。自然语言处理或光学字符识别流水线可以推断部分字段，但来源系统提供的权威字段应由采集系统直接写入。元数据支持过滤、排序、去重、时效规则和访问控制。

元数据质量不是展示层的细节。租户标识缺失或可被随意修改会导致数据泄露；有效期错误会让正确片段变得无关；文档类型识别错误则可能让查询路由把请求送到错误的索引。

文本切分

切分决定了哪些内容可以作为一个检索单位。片段太小时，可能缺少回答问题所需的上下文；片段太长时，检索精度下降，生成器也会收到更多噪声。摘要可以减少长度与编码成本，但也可能删掉用户真正需要的精确细节。

最佳边界取决于领域。技术手册可以按章节切分，源代码可以按类和函数切分，法律文件可以按条款切分，对话记录可以按发言轮次切分。固定字符数容易运行，却经常刚好切在最能解释语义的位置上。

实用的流水线可以同时保存多种表示：用于精确检索的小型子片段、用于生成的较大父级章节，以及连接两者的元数据。这也是后文递归检索和句子窗口技术的基础。

索引器

索引器把片段和嵌入映射到可搜索位置，并执行创建、更新和删除。它是一套承担生产责任的数据系统，而不只是一个写入接口。

• 可扩展性：随着语料增长，索引和检索速度仍要保持可接受。
• 实时更新：频繁变化的来源系统需要实时采集，同时不能破坏查询流量。
• 一致性与原子性：并发更新不能留下只索引了一半或互相矛盾的文档。
• 存储效率：大型语料需要管理索引体积、副本和保留周期。
• 安全与访问控制：只有获授权服务才能创建、读取、更新或删除记录。
• 监控与维护：索引失败、索引陈旧和资源瓶颈必须能被发现并修复。

原子性直接影响用户信任。如果一份政策文件在更新与删除时只完成了一半，旧片段仍可被搜索，系统就可能依据过期规则回答。采集任务应具备持久状态、幂等写入、完整删除协议，以及验证可搜索集合与事实来源一致的方法。

为不同职责拆分数据存储

企业级 RAG 会产生多种数据，它们在访问权限、保留周期和性能要求上各不相同。全部塞进一个数据库可以让首次部署更简单，却会让后续恢复和评估更困难。

数据类型	常见存储	为什么需要	运行注意事项
嵌入向量	SQL 或 NoSQL 数据库	无需重新计算全部向量即可重建索引，并保留可恢复表示。	保持编码器版本、向量维度与向量数据库一致。
原始文档	对象存储或 NoSQL 数据库	用于重新处理、引用、检查和恢复原始来源。	保存源文件哈希、访问标签和删除状态。
聊天历史	NoSQL 数据库	解析指代、个性化、审计和评估多轮对话。	对敏感对话执行保留周期和隐私规则。
用户反馈	SQL 或 NoSQL 数据库	定位薄弱查询、比较检索路径，并转化为回归测试。	把反馈关联到准确的检索上下文和模型版本。

单独保存嵌入是一项重要的安全措施。向量数据库可以替换、重建或重新索引，因为文档和向量仍然存在。没有这种拆分，一次迁移可能要求再次付费编码同一批语料，而且如果模型版本发生变化，还会得到不同的索引。

选择向量数据库

向量数据库是检索引擎，但“哪个向量数据库最快”并不是完整的评估问题。最佳选择取决于语料、查询分布、访问模式、部署约束以及负责运维的团队。

召回率与延迟

精确平面搜索提供可靠召回基线，但规模变大后成本很高。HNSW、乘积量化、ANNOY 和 DiskANN 等近似索引会以召回率、内存或存储为代价换取速度。必须在组织自己的向量和查询上测试，因为供应商的综合基准很少完整复现相同的过滤条件和文档分布。

成本与部署方式

托管云数据库通常按存储和查询量计费，并免除基础设施工作。自托管可以提供更强控制和潜在更低的边际成本，但组织必须负责扩容、升级、备份、安全和事故响应。数据敏感性和团队能力有时比查询延迟的微小差异更重要。

写入速度与查询速度

流式系统需要快速写入，面向用户的搜索则通常更重视稳定查询延迟。要在真实峰值负载下同时测量。如果一个数据库写入很快，但一加过滤条件延迟就大幅上升，它就不适合权限复杂的企业界面。

内存与磁盘

内存索引速度快，但向量集合超过内存后会变得昂贵甚至无法运行。磁盘或内存映射系统可以扩展到内存之外，DiskANN 及相关索引专门优化外部存储搜索。比较时必须把内存成本计入总成本。

混合检索

向量检索擅长语义相似，却可能漏掉精确名称、标识符和稀有术语。全文检索能捕捉词法匹配，却可能错过同义改写。混合检索同时维护稠密与稀疏表示，通常包括向量索引、倒排索引以及重排或融合步骤。Pinecone、Weaviate 和 Elasticsearch 等系统提供用于平衡稠密与稀疏信号的权重。

元数据过滤

企业查询经常要求按租户、部门、文档类型、日期或权限组过滤。预过滤如果执行过强，可能排除本应出现的结果；后过滤则在目标子集极小时容易失效，因为近似搜索可能没有返回足够多符合条件的记录。Weaviate 等系统的自定义过滤搜索把预过滤与仍能高效探索子集的搜索结构结合起来。

从安全角度看，租户和权限过滤不是可选的排序提示。任何候选进入结果集之前都必须通过过滤。即使应用层最后再剔除无权记录，只要未授权向量已经进入查询进程，设计仍然存在数据边界缺陷。

改进检索的技术

更长的上下文窗口并不能消除检索问题。原文引用的研究表明，模型会被无关内容干扰，也可能漏掉长上下文中部的信息。目标不是把所有可能文档都发过去，而是发送相关、多样、结构良好的证据。

假设文档嵌入

HyDE 先让模型根据问题生成一份假设答案或文档，再把生成文本编码，并用这个向量检索真实文档。假设文本可能包含编造细节，因此不能作为证据。它的价值在于，答案形态的段落可能比短问题更接近目标语料。当查询很短，或用户词汇与原文差异很大时，这种方法尤其有效。

查询路由

组织拥有多个索引时，路由器把问题送到最相关的索引。产品问题进入产品文档，代码问题进入代码索引，制度问题进入人力或合规索引。路由能提高精度并降低延迟，但每次路由决策都要记录。如果系统自信地送往错误索引，用户看到的结果会像内容缺失，实际上答案存在于另一处。

重排

第一阶段向量检索优先保证召回，随后由重排器更仔细地给较小候选集打分。BGE-large 等交叉编码器，以及 RankVicuna、RankGPT、RankZephyr 等基于解码器的重排模型，可以改善顺序并减少幻觉。代价是额外延迟和计算量，因此候选数量和模型规模都要测量。当第一阶段能够召回答案但排序不够靠前时，重排收益最大。

最大边际相关性

相关结果可能彼此重复。最大边际相关性在查询相关性与已选结果差异度之间取得平衡，使结果覆盖问题的更多方面，而不是返回多个几乎一样的片段。它适合比较型问题、研究综述，以及需要多文档证据才能完整的回答。

自动截断

自动截断通过分析排序分数中的明显跳变来决定返回多少结果。在距离值为 0.1899、0.1901、0.191、0.21、0.215 和 0.23 的例子中，前三个值形成一个紧密分组。不同截断设置可以只返回这一组、扩展到更大一组，或返回全部六个。它的优势是 K 随每次查询的数据分布变化，而不是所有问题共用固定数量。

递归检索

递归检索也叫从小到大检索。系统先用较小片段建立嵌入，以提高精确匹配概率，再返回较大的父级上下文供生成器使用。小片段负责命中相关句子，父级内容恢复解释、表格或条件。它直接缓解检索精度与答案完整性之间的矛盾。

句子窗口检索

句子窗口检索先找到高度相关的句子，再在生成前扩展前后文。它与递归检索思想相同，只是粒度更轻：用精确单位检索，再提供局部上下文。窗口需要遵守文档结构，不能从一个章节跨进另一个无关章节。

选择生成模型

生成器把检索证据转化为答案。主要选择是自托管推理还是私有接口，但完整比较还应包括延迟、吞吐、安全、可观测性和幻觉检测能力。

模型接口能力

生产级大模型服务不应只接收提示词。原文强调四类能力：

• 性能：多 GPU 张量并行、连续批处理、量化和优化后的 Transformer 实现可以改善吞吐和延迟。
• 生成控制：温度、top-p、top-k、重复惩罚、停止序列和对数概率，让应用能够控制输出并支持幻觉分析。
• 安全：使用 safetensors 加载权重可以降低模型参数被篡改的风险，水印则有助于追踪来源。
• 用户体验：通过服务器发送事件流式输出令牌，让界面更快响应用户并持续展示进度。

这些能力并非每家供应商都等价。一个基准质量很高的模型，如果不能流式输出、不能提供对数概率、无法设置稳定超时，或不能运行在要求的隐私边界内，仍然不适合生产。

自托管推理

在 AWS、GCP、Azure 或私有基础设施上自托管，可以控制数据和部署，但也接管了全部模型服务工作。TGI、Ray 和 FastAPI 技术栈在运维复杂度上各有取舍。应测量首令牌时间、令牌间延迟、成功率、吞吐和负载下的正确性。像 LoRAX 这样的多适配器系统可以在产品需要多个微调模型时共享 GPU 资源，而不必为每个模型单独部署。

私有模型接口

OpenAI、Fireworks、Anyscale、Replicate、Mistral、Perplexity、Together 等服务免除基础设施工作，但引入速率限制、价格变化、网络依赖和数据治理问题。比较输入与输出令牌价格时，要同时考虑 GPU 使用率与人员成本。低流量或波动大的场景可能托管服务更便宜，持续高利用率则可能自托管更经济。使用量变化后应重新评估。

用提示词约束有证据的回答

检索负责提供证据，提示词决定模型如何使用证据。原文列出了五种可以改善 RAG 表现的提示方式：

• 思维线索：先把复杂问题拆成较小步骤，再形成答案。
• 笔记链：在长上下文中逐步记录结构化笔记，最后再综合。
• 验证链：先起草答案，再生成验证问题，并根据检查结果修订。
• 情绪提示：在指令中加入情绪强调，可能改变模型服从程度，但可靠性较低，也更难解释。
• 专家提示：加入详细的专家角色和任务框架，以改善特定领域表现。

企业级 RAG 的提示词应要求答案基于证据、允许表达不确定性、规定输出结构，并说明检索上下文不足时如何处理。但提示词不能成为唯一的约束机制。引用、结构校验和访问控制必须在语言模型之外执行。

输出护栏

输出护栏在生成答案到达用户或其他系统之前进行检查，可以识别无证据的断言、不恰当的具体程度、竞品提及、毒性、政策违规、敏感数据泄露和品牌风险。原文用一个气候问题举例：一个回答基于科学事实，另一个回答充满侮辱和轻蔑。后者可能在表面语言上很流畅，却会造成真实的品牌与安全损害。

输出检查应分层进行：对照检索证据检查落地性，检查格式与结构，执行政策分类，检测敏感数据，并应用确定性的业务规则。每一种失败都需要明确动作，例如阻断、重新生成、脱敏、升级人工处理或返回安全兜底内容。为了调试护栏本身，还要同时记录原始回答、修改后回答和干预原因。

用户反馈与持续改进闭环

反馈把生产过程变成评估数据来源。点赞、点踩、星级、修正答案或文字评论只有和原始问题、检索片段、排序分数、提示词、模型版本及最终答案关联起来，才真正有用。

1. 收集反馈：提供低摩擦的正负信号，并允许用户补充具体问题。
2. 诊断失败：判断问题来自数据缺失、检索、上下文整理、信息提取、输出格式、具体程度还是完整性。
3. 改进数据：修正不完整或组织混乱的源内容，修复解析，更新访问标签，或补充缺失文档。
4. 评估并加入回归测试：修改后重新运行薄弱查询，并把它永久纳入测试，防止后续变化悄悄破坏结果。

最有价值的改进往往发生在底层数据，而不是提示词。如果制度已经更新但旧文档仍在索引中，系统需要删除与时效流程；如果表格被压平成文本，解析器需要重做；如果答案已经检索到却被遗漏，上下文整理或完整性评估需要关注。

可观测性

RAG 可观测性既要覆盖传统服务指标，也要覆盖模型特有行为。延迟和成本是必要条件，但并不充分。一个快速、便宜的答案仍然可能没有证据、不完整，或超出允许的数据范围。

• 提示分析：检查真实提示和输出中的指令失败、幻觉与漂移。
• 调用可追踪：采集 LangChain、LlamaIndex 等框架的调用链，让缓慢或错误答案能够沿检索、重排、上下文整理和生成逐段追查。
• 检索诊断：记录召回率、分数分布、过滤行为、索引时效，以及检索参数变化带来的影响。
• 告警：发现错误率上升、延迟回归、成本突增、幻觉信号和异常访问模式。

服务目标应覆盖首令牌时间、端到端延迟、可用性、检索失败率、答案落地性和每次成功交互的成本。调用链应记录文档编号和访问范围决策，但也要避免产生第二份失控的敏感内容副本。

缓存

缓存保存提示词与回答，或可复用的中间结果，避免重复执行昂贵工作。它有三方面价值：

• 改善生产推理：重复或相似问题可以接近零生成延迟。
• 加快开发：工程师迭代下游逻辑时，不必每次测试都重新调用相同模型。
• 复用数据：保存的提示与回答可以用于分析及未来微调，但要符合隐私和保留规则。

GPTCache 是一个可选实现，支持精确匹配和相似匹配，并提供命中率、延迟和召回指标。相似缓存必须执行严格租户隔离。两个用户可能说出完全相同的问题，却拥有不同权限和文档访问范围。缓存键如果没有包含租户、授权范围、文档版本和模型版本，就可能泄露上一名用户的答案，或返回当前用户无权查看的证据。

多租户：隔离属于访问控制属性

多租户 RAG 必须同时满足两个目标：为当前用户检索最佳证据，且绝不让其他租户的数据进入查询路径。最可靠且简单的设计，是把权威的租户、用户和权限元数据附加到每份文档与片段，然后在检索和排序之前执行强制过滤。

flowchart LR
    Q[用户问题] --> I[已验证身份]
    I --> S[租户与权限范围]
    S --> F[预过滤可搜索记录]
    F --> V[向量与词法检索]
    V --> R[只重排获授权候选]
    R --> G[基于获授权上下文生成]
    G --> A[答案]
    A --> L[审计日志]

原文推荐使用元数据实现隔离，因为它简单而有效：添加文档时写入租户信息，把文档与该租户绑定；用户搜索时，系统按相同属性过滤，只对属于该租户的文档进行智能排序。这样可以防止私人信息在不同用户之间混杂。

租户过滤必须由数据访问层强制执行，不能交给语言模型请求执行。“只使用租户 A 的文档”写进提示词并不构成安全边界，检索内容和用户消息都可能尝试覆盖它。

在运行成本允许时，最稳妥的实现是为每个租户使用独立命名空间或集合；共享集合则必须使用带强制过滤的查询。无论采用哪种方式，授权判断都要发生在向量、片段和上下文返回之前。审计记录应展示请求身份、应用的权限范围、符合条件的文档版本，以及最终支持答案的来源。

除了第一层过滤，还有更多隔离问题。一个租户能否污染共享缓存？重排器是否会看见其他租户候选？评估系统是否会把原始调用链跨账户导出？管理索引器能否错误写入另一个命名空间？引用接口是否可以通过猜测编号读取用户范围外的文档？多租户设计必须让租户身份贯穿所有这些路径，而不能只处理最初的向量查询。

结语

企业级 RAG 是一组彼此耦合的信息系统与控制系统的组合。身份认证确定用户身份；输入输出护栏限制不安全请求和回答；查询改写把用户语言转换为可检索表达；编码器定义“相似”的含义；解析与切分决定哪些证据能够存在；索引与存储保证证据可用且正确；向量数据库与检索技术决定哪些证据进入模型；提示词和生成器把证据转化为答案；反馈、可观测性、缓存与多租户机制则保证系统可以持续改进，同时不破坏信任边界。

七类失败点提供了一套长期可用的诊断框架。答案出错时，先定位损失发生在哪里：内容缺失、排名遗漏、上下文丢失、提取失败、格式错误、具体程度不对，还是答案不完整。只有保持这种区分，团队才能把“看起来很聪明”的演示，变成可评估、可审计、可运营的企业级服务。

来源说明：整理本文时原站域名已无法访问。以上中文内容根据 Internet Archive 于 2024 年 10 月 11 日保存的完整页面改编，原始技术插图从归档的 Galileo 内容分发网络资源中恢复。规范来源仍为原文链接。