如何搭建企业级的RAG应用

说到最近技术圈里讨论最火的技术，RAG（检索增强生成）绝对占有一席之地。它最初是为了解决大语言模型的一些短板而设计的，但很快大家就发现，这玩意儿在企业实际场景里简直太好用了。说句实在话，很多企业压根不在乎你底层用的是不是大模型，他们只关心能不能更快、更准地搜到想要的东西。RAG恰好就干了这个活儿——既提升了搜索的准确率，又让生成的内容更贴合需求。像ChatPDF这种开源项目，就是RAG落地的绝佳例子，一下子就把它的价值给展现出来了。

什么是 RAG

铺垫了这么多，那RAG到底是个什么东西？简单来说，RAG——Retrieval Augmented Generation，检索增强生成。它的核心任务是生成最终答案，但关键在于，它并不是让大模型天马行空地发挥，而是先做一步检索，从现有文档里找依据。下面用一个浅显的例子来说明：

假设一位工程师需要从厚厚的《业务操作手册》里找知识来完成工作。他有三种方式可选：

• 最原始的方法
  ：自己去翻阅纸质手册，或者搜索电子版，一页页读下来，碰到复杂的内容还得自己整合多个章节，融会贯通。费时费力。

• 借助问答机器人
  ：直接去问一个FAQ式聊天机器人。这确实省了点事，但麻烦也不小——它更像是一问一答的自动回复机，用户还是得自己把零散的回答拼起来；而且背后那个知识库，需要专业人员一条条地整理（包含问题和多种相似问法），工作量巨大，很难大面积推广。

• RAG 方案
  ：直接把《业务操作手册》电子版上传到系统，几分钟内系统就把整本书建好索引了。然后工程师随便问，RAG会自动综合手册中多个相关知识点，并用一种“老专家”的口吻给出答案：“要解决这个问题，你得先搞定两个前提，有三种方法可以走。下面咱们一步步来……”

看到这，你应该明白了。它其实正在悄悄取代传统的FAQ问答模式。

RAG 系统构建挑战

在聊具体架构之前，先得说说构建RAG系统时容易踩的那些坑。最近有研究团队分析了三个跨领域的案例，总结出七个常见故障点：

FP1：缺失的内容（Missing content）

当用户的问题在现有文档里压根儿找不到答案时，理想情况是系统老实说“抱歉，我不知道”。但问题是，有些问题看似相关，实则无解，系统这时候容易被带偏，给出一个不太靠谱的回应。

FP2：错过排名靠前的文档（Missed the top ranked documents）

答案其实藏在文档里，但检索排名不够靠前，导致没被系统推送给用户。理论上所有文档都会被排序，但实际中只会返回前K个，这个K值需要根据性能反复调试。

FP3：未在上下文中——整合策略限制（Not in context - consolidation strategy limitations）

检索到了包含答案的文档，但因为返回结果太多，上下文窗口装不下，导致最相关的信息被排挤掉了。

FP4：未提取（Not extracted）

答案明明就在上下文里，可模型要么被噪音干扰，要么遇到矛盾信息，就是提取不出正确的那部分。

FP5：格式错误（Wrong format）

用户要求输出表格或列表等特定格式，但大模型直接“无视”了指令，给出一堆文字。

FP6：错误特异性（Incorrect specificity）

答案要么太笼统，要么太具体，就是跟用户想要的不在一条线上。比如用户问一个教育问题，系统却偏偏只给答案而不给讲解；或者用户问得太宽泛，系统又不知道该怎么收索。

FP7：不完整（Incomplete）

答案本身没错，但缺少了关键信息——明明这些信息就在上下文里，系统却没提取。比如问“文件A、B、C中涵盖了哪些要点”，它可能只答了一部分。

如何构建企业 RAG 系统

摸清了这些坑，接下来就得看看每个组件该怎么设计，以及有哪些最佳实践。

一、用户认证

这是系统的第一道关。用户开始对话前，必须先确认身份。这不仅仅是为了安全，还能实现个性化。具体来说：

• 访问控制
  ：确保只有授权用户能进入系统。

• 数据安全
  ：防止敏感信息泄露给不该看的人。

• 用户隐私
  ：保证只有目标用户能访问自己的个人信息。

• 问责制
  ：每个操作都能追溯到具体用户，方便审计。

• 个性化和定制
  ：根据用户身份调整体验，比如定制内容、偏好和设置。

二、输入保护

防止用户输入有害或私密信息，这块儿越来越重要——毕竟，最近的研究表明，大模型还挺容易被“越狱”的。具体保护场景包括：

• 匿名化
  ：抹掉姓名、地址、联系方式等个人身份信息。

• 限制子字符串
  ：禁止可能用于SQL注入、XSS攻击的字符。

• 限制主题
  ：过滤掉仇恨、歧视、露骨等违规内容。

• 限制代码
  ：防止可执行代码注入，避免安全漏洞。

• 限制语言
  ：验证输入文本的语言或脚本是否正确。

• 检测提示注入
  ：防止恶意提示操纵系统行为。

• 限制tokens
  ：限制输入长度，防止资源耗尽或DoS攻击。

要防御这些问题，可以借助Meta开源的Llama Guard。

三、数据索引

• 文档解析
  ：处理PDF、Word、Excel、数据库等多种格式，识别超链接、多媒体元素、注释等内嵌内容。尤其要注意表格——从文档表格中提取数据并保留结构，对报告和研究论文尤其重要。Table Transformer这类模型很实用。

• 数据处理
  ：包括格式处理、剔除不可识别内容、压缩和格式化。

• 元数据提取
  ：提取文件名、作者、创建日期、文档类型、关键词、章节标题、图片alt信息等，这些都可以作为特殊字段进行索引。

• 固定大小分块
  ：一般是256或512个tokens，具体取决于嵌入模型。但弊端也很明显——语义可能被切碎。比如“我们今天晚上应该去吃个大餐庆祝一下”，可能被分成“我们今天晚上应该”和“去吃个大餐庆祝一下”。解决办法是增加冗余，比如512tokens的块只存480，让相邻块互相交叉一点。

• 特定格式分块
  ：针对Markdown、LaTeX、Python代码等有结构特征的文本，依据特定字符或结构标记来切分，保持逻辑连贯性。比如Markdown按标题、列表、引用等来分。

• 递归分块
  ：用一组分隔符反复切分，如果第一次没切到理想长度，就递归地用更细的分隔符继续。比如先按句号分，太长就再按逗号或空格切，确保不破坏语义结构。

• 语义分块
  ：先按句子切分（句子本身就是一个语义单位），然后用嵌入模型表征句子，最后把相似的句子组合在一起，同时保持原有顺序。

• 命题分块
  ：一种更高级的语义分块。基于大模型，逐步构建块——先对段落做句法分块，再用LLM生成独立陈述（比如“这段文字讨论了什么主题”），去掉冗余，最后索引并存储命题。查询时直接从命题库检索，而非原始文档库。

• 影响分块策略的因素
  ：索引类型（文章和推文的分块大不相同）、模型类型（ChatGLM、ChatGPT、Claude各有不同的tokens限制）、问答文本的长度和复杂度（最好让分块尺寸与问答文本长度相当）、应用类型（检索、问答、摘要等也会影响策略）。

这是将文本、图像、音频等转化为向量矩阵的过程，也就是变成计算机能理解的格式。嵌入式模型的质量直接影响后续检索的相关度。选择编码器时需要考虑几点：

• 利用MTEB基准评估
  ：大规模文本嵌入基准（MTEB）可以对OpenAI、Cohere、Voyager等商业模型，以及一些开源模型做全面评估，包括向量维度、平均检索性能、模型大小等。

• 自定义评估
  ：编码器在处理敏感信息时不一定表现最佳，需要自定义评估。三种方法：一是通过注释评估——生成专用数据集，人工打标签，再用MRR、NDCG等指标定量评估；二是按模型评估——用LLM或交叉编码器作为评估器，对前三个编码器做手动验证；三是聚类评估——用HDBSCAN等算法分析不同Silhouette分数下的向量相似性。

• 查询费用
  ：OpenAI这类API省去了托管管理，但开源自建要考虑模型大小和延迟。110M参数以内的小模型可用CPU托管，大模型可能需要GPU。

• 索引成本
  ：建议将文档嵌入单独存储，避免服务迁移或重置时重新计算。

• 仓储成本
  ：大规模向量索引的存储成本与维度成线性关系。

• 搜索延迟
  ：语义搜索的延迟随维度线性增长，选择较低维度的嵌入能降低延迟。

• 隐私
  ：金融、医疗等敏感领域对数据隐私有严格要求，通常需要私有化部署。

目前主流的嵌入式模型包括：BGE（国人开发，HuggingFace MTEB排名前二）、M3E（同样来自国内）、通义千问的嵌入模型（1500+维）、OpenAI的Text-embedding-ada-002（1536维，MTEB排名第六，但实际体验很好）。当然，也可以在现有模型基础上微调，一般能提升3%-10%的性能。

四、检索环节

检索环节的技术含量同样很高，通常分为以下几部分工作：

：用户查询可能含糊不清，需要先进行重写以提高清晰度和相关性。具体包括：

• 根据历史重写
  ：利用对话历史理解上下文。比如用户先问“你有多少张信用卡？”，再问“白金卡和金卡有年费吗？”，然后问“比较两者的特点”。系统需要根据历史识别意图，重写为“比较白金信用卡和金卡信用卡的功能”。

• 创建子查询
  ：复杂查询拆分为更具体的子查询。比如对于“比较白金卡和金卡的功能”，拆成“白金信用卡有什么特点？”和“金卡信用卡有什么特点？”。

• 创建类似查询
  ：为了克服语义或词汇匹配的局限性，生成同义词或相关术语的类似查询。比如“我想了解白金信用卡”转化为“告诉我白金信用卡的好处”。

：索引被分成大量块后，检索效率会成为瓶颈。通过元数据预先过滤，能大幅提升效率。比如问“帮我整理一下XX部门今年5月份所有合同中，包含XX设备采购的合同”，通过“XX部门+2023年5月”的元数据过滤，检索量可能缩小到整体的万分之一。

：将实体变成节点，实体间关系变成边，利用知识图谱做更准确的回答。尤其对多跳问题，图数据索引能让检索相关度大幅提升。

：主要包括相似度检索（欧氏距离、曼哈顿距离、余弦等六种算法）、关键词检索（传统但很重要——比如先对块做摘要，再通过关键词检索找到可能相关的块；据说Claude.ai也这么干）以及SQL检索（对本地化企业应用，这是一个必不可少的环节）。

：一次检索的结果相关度可能不够理想。需要利用Plan B或组合相关度、匹配度等因素重新调整排序，得到更符合业务场景的结果。业界常用RankVicuna、RankGPT和RankZephyr。

：MMR在相关性和多样性之间取得平衡，减少冗余。就像在聚会上先介绍最匹配的朋友，然后再找几个稍微不同的人，直到达到理想的引入数量。

：通过检测分数变化来限制返回结果数量。如果分数出现显著跳跃，说明从高度相关转到了不太相关，系统就在这个节点自动截止。

：检索单个句子，同时返回该句子周围的文本窗口，确保信息既准确又与上下文相关。

：可以利用LlamaIndex等框架提供的查询器，采用树查询（从叶子节点逐步向上合并）、向量查询或最原始的顺序查询。

：当有多个索引时（比如技术文档、产品文档、任务、代码仓库等各自建了索引），查询路由将用户问题定向到最相关的索引。比如用户问产品功能，就路由到产品文档索引。

：当检索性能差，尤其是短查询或不匹配查询导致找不到信息时，可以用HyDE技术，生成相似或更标准的提示模板——有点像直接抄作业。

五、生成（Gen）

这块主要依赖Langchain和LlamaIndex这类框架。有多种用于改进RAG输出的提示技术，值得后面单独研究。

六、输出保护

与输入保护类似，但专门针对大模型生成的输出。目的是防止生成不准确、有违道德或不符合品牌价值观的内容。通过积极监控和分析输出，确保内容事实准确、伦理合理且品牌导向一致。

七、缓存

缓存提示及其对应的响应，方便后续直接调用。这能带来三个明显好处：

• 增强生产推理
  ：某些常用查询可以实现接近零延迟的响应。

• 加速开发周期
  ：开发阶段避免重复调用API，省钱又省时间。

• 数据存储
  ：积累的提示-响应数据，可以用于后续模型优化。

八、存储

需要解决向量、文档、聊天记录、用户反馈等数据的存储问题，这个后面再详细展开。

总结

LLM技术浪潮带来了不少新东西，但要让这些技术在企业里真正发光，还得靠深入研究和持续实践。只有这样，才能打磨出真正高质量的解决方案。

https://www.rungalileo.io/blog/mastering-rag-how-to-architect-an-enterprise-rag-system
https://mp.weixin.qq.com/s/37tKVQbxenVVBAeMZ334aQ
https://arxiv.org/pdf/2401.05856