企业实施RAG过程中:常见误解与澄清,内含项目升级预告

人工智能
这篇给大家介绍下我目前几个项目实践踩坑过程中总结出的些经验。不过抛开以下细枝末节,个人最大的体感是,做 RAG 的垂直场景落地的关键要素其实一直都不是大模型,怎么把数据检索出来才是问题的根本。

春节之后的一个月的时间内,微信和小红书上数了下大概有 150 多个过来咨询 RAG 在企业落地的网友,一路聊下来按照对方的诉求大概分为三类,第一种是最多的就是年后返工公司领导让落地 RAG,但是一时没有头绪的过来咨询的;第二种是看过我公众号上的相关案例后,想外包给我来做具体实施的;第三种有点出乎意料的是,相关的媒体来交流行业观察的。

第一种类型也是最开始比较多的,最初我也是问啥答啥,但是大概聊了五六个之后发现情况有点不对,大部分其实是比较基础的问题,或者我认为问大模型能比问我更快扫盲的,再加上后来确实肉眼可见的人在变多,我索性和每个人说如果是咨询的话 200 块每小时(现在涨到了 500),这样就大部分人就索性不问了,虽说前后也是有十几个人很干脆的问完问题后直接发了红包,不过不得不说收费确实是个很好的互相筛选。

以上是碎碎念,言归正传,这篇给大家介绍下我目前几个项目实践踩坑过程中总结出的些经验。不过抛开以下细枝末节,个人最大的体感是,做 RAG 的垂直场景落地的关键要素其实一直都不是大模型,怎么把数据检索出来才是问题的根本。简单的向量搜索也只是召回,如何做二次精排,以及插入多样性之后再做一次 Re-Ranking 等等方法也是需要从实践中来到实践中去。当然,这些细节也是后续重点和大家一起探讨的。

1、技术选择与应用场景误解

1.1 长文本处理、微调和 RAG 的比较和适用场景

误解:RAG 总是优于直接使用大模型或微调模型

澄清:

直接使用大模型适合:简单查询、通用知识问答、即时响应场景,如客服常见问题解答

微调适合:需要模型深度理解特定领域语言和概念(如医疗术语、法律条文)、语料相对固定且有限、追求统一输出格式和风格的场景

RAG 适合:需要实时获取最新信息、处理大量不断更新的文档(如产品手册、法规更新)、需要提供信息源引用以增强可信度的场景

混合方案的优势:基于领域微调模型结合 RAG 架构往往效果往往比单一方法效果最佳

1.2 RAG 的实际能力与局限性

误解:RAG 可以回答任何关于文档的问题

澄清:

RAG 本质上是"检索增强"而非"完全理解",它基于检索片段进行回答

不擅长回答如"这份报告的整体结构是什么"或"文档中的论点如何递进发展"等需要全局理解的问题

检索效果受分块粒度影响显著:过大的分块会包含无关信息干扰答案,而过小的分块会丢失上下文关联

最后,在需要多角度综合或推理的问题上表现受限,如"基于这些财务数据,公司未来三年的发展战略应该是什么"

1.3 对 RAG 成本和复杂度的误解

误解:RAG 总是比微调更简单或成本更低

澄清:

RAG 系统包括文档处理、向量化、存储、检索、排序等多个环节,每个环节都有大量的优化空间

随着文档数量增长,存储和检索成本呈近似线性增长,大规模应用需考虑成本控制策略

维护成本往往被低估:文档更新、向量重新计算、检索策略调整等也需要持续投入,除非你的知识库是一成不变的

对比分析:处理 10 万页专业文档,一次性微调模型可能比长期维护 RAG 系统更经济,当然前提还是文档的更新是相对缓慢的

2、技术实现层面的误解

2.1 分词策略误解

误解:使用默认的分词策略适用于所有语言和领域

澄清:

语言特性差异:中文需要字词级分词而非空格分词,专业中文术语需要作为整体处理

领域特性适配:法律文本中的"第 X 条"、医疗文本中的"xx 指标"等也需要作为整体保留

技术实现对比:

基础分词:简单按句号、逗号等标点切分

语义分词:考虑段落、小节语义完整性的智能切分

混合分词:结合文档结构(标题、章节)和语义边界的复合切分

2.2 向量化过程的常见误区

误解:所有内容都需要向量化,且使用相同的向量模型

澄清:

内容类型差异化处理:

文本内容:适合使用文本 embedding 模型

表格数据:可考虑结构化向量化或表格专用 embedding

代码片段:代码专用 embedding 通常效果更好

向量模型选择依据:

通用应用:OpenAI text-embedding-3-large、Cohere embed v3 等通用模型足够

专业领域:BGE、GTE 等开源模型可针对垂直领域微调提升效果

混合索引策略:关键词索引+向量索引的双重索引往往比单一索引效果更好

维度与性能权衡:更高维度并非总是更好,1536 维 vs512 维在许多应用中差异不显著但成本相差 3 倍

2.3 检索策略选择的盲区

误解:简单的余弦相似度检索足以满足所有需求

澄清:

多样化检索策略比较:

BM25:适合精确关键词匹配,在技术文档、产品手册中表现良好

向量检索:适合语义理解,在客户问询、意图分析中表现良好

混合检索:结合两者优势,实践中对召回率的提升也有些明显的效果

参数调优经验:

top_k 值选择:一般推荐 3-5 个片段,太多会引入噪音,太少可能缺失关键信息

相似度阈值:0.7-0.8 是常见起点,但需要大家根据自己的业务场景容错性进行自定义调整

检索增强技术:

查询改写:将用户问题转化为更适合检索的形式

结果重排序:根据多维度相关性(不仅是向量相似度)重新排序

2.4 排序策略的优化空间

误解:检索结果的相似度分数直接反映其相关性

澄清:

多维度排序因素:

相关性:向量相似度只是一个维度

时效性:更新时间可作为排序权重,当然这种更适用于新闻、政策等时效性较高的内容

权威性:可给官方文档、核心政策等设置更高权重

排序策略优化路径:

初始阶段:单一向量相似度排序

进阶阶段:加入多因素加权排序

高级阶段:引入专门的重排序模型(如 Cohere rerank)

用户交互数据价值:点击、停留时间、反馈等用户行为数据是优化排序的重要反馈,当然前提是使用的人足够多

2.5 大模型选择的考量

误解:更大、更新的模型总是更好

澄清:

性能与成本平衡:

小模型(7-13B):适合简单总结、标准化回复,成本低、速度快

中型模型(13-70B):大多数企业应用的性价比选择

大型模型(70B+):复杂推理、多轮对话场景的最佳选择

闭源 vs 开源权衡:

闭源 API 优势:质量稳定、维护成本低、快速上手

开源模型优势:数据安全、可定制性强、长期成本可控

注:如果真的不是公司合规限制,初期POC阶段能用商业API的就别动手本地部署,有卡也别部,除非上来能部署个DeepSeek-R1满血版的。

3、项目实施层面的误解

3.1 过早本地化部署的陷阱

误解:企业应该从一开始就追求完全自主可控的本地部署

澄清:

快速 POC 的价值:

验证商业价值是技术路径选择的前提,"有没有用"先于"怎么用"

最快 POC 路径:云服务部署 RAGFlow/LlamaIndex + 商业 API + 简化数据集

典型 POC 周期:精简方案 2-4 周,完整方案 4-8 周

敏感数据处理策略:

实体识别和替换:使用 NER 工具识别并替换敏感实体(人名、机构名、金额等)

令牌化替换:保留数据结构,但用占位符替换实际内容,如"客户 A"、"金额 X"

本地向量化:在本地完成向量化,只把向量而非原始文本发送至云端

混合架构:敏感数据本地处理,非敏感数据云端处理

分阶段部署策略:

阶段一:云服务+商业 API(速度优先)

阶段二:混合部署(关键组件本地化)

阶段三:完全本地化(根据业务需求选择性实施)

3.2 完美主义陷阱

误解:RAG 系统必须达到接近 100%的准确率才能上线

澄清:

渐进式目标设定:

初始可接受准确率:70-80%(取决于业务容错性)

中期目标准确率:80-90%(基于用户反馈优化)

长期理想准确率:90%+(持续迭代提升)

实用性优先原则:

解决 80%常见问题的 80%系统比解决 100%问题但永远不上线的系统更有价值

提供替代路径:当系统无法准确回答时,引导用户转向人工渠道

错误类型区分:

致命错误:提供错误信息导致使用同事判断失误(需严格控制)

非致命错误:信息不完整或部分不准确(可接受一定比例)

3.3 忽视用户反馈的误区

误解:RAG 是一次性建设项目

澄清:

反馈闭环机制:

直接反馈:点赞/点踩、评分、问题报告

间接反馈:使用时长、重复提问率、人工求助转化率

反馈分析:识别常见失败模式和根本原因

持续优化策略:

数据侧优化:补充缺失信息、调整分块策略

检索侧优化:调整检索参数、改进排序算法

生成侧优化:优化提示词模板、调整模型参数

A/B 测试价值:

对比不同切片策略、检索方法或排序算法的实际效果

数据驱动决策而非主观判断

3.4 数据质量 vs 数据量的误解

误解:更多的文档意味着更好的 RAG 效果

澄清:

数据质量评估维度:

相关性:与业务问题的直接关联程度,这部分是重中之重,如果引入了很多噪声,也为调优工作增加了很多负担

时效性:信息的更新状态

权威性:信息来源的可靠程度

结构化程度:信息的组织清晰度

数据预处理关键步骤:

去重:识别并合并重复或高度相似内容

清洗:移除格式标记、无意义内容、噪音数据

结构化:将非结构化内容转化为结构化形式

数据更新策略:

增量更新:只处理新增或变更内容

定期全量更新:针对关键数据源的周期性刷新

基于时效性的差异化更新频率

4、行业最佳实践的思考

4.1 技术栈选择的平衡

最佳实践:

开源框架选择考量:

RAGFlow:适合快速部署,内置多种优化策略

LlamaIndex:灵活性高,适合定制开发

LangChain:生态丰富,社区支持广泛

商业 API 与开源模型混合使用:

核心功能使用高质量商业 API(如 DeepSeek-R1、Qwen 2.5 Max 等)

非核心或高频场景可考虑本地开源模型(如 DeepSeek-R1:32b/70B 等)

向量数据库选择因素:

小规模应用:FAISS、Chroma 等轻量级选项足够

大规模应用:Weaviate、Milvus、Pinecone 等分布式解决方案

特殊需求:Qdrant(过滤功能强)、PGVector(与现有 PostgreSQL 集成)

4.2 灵活配置和二次开发的重要性

最佳实践:

配置化 vs 代码化:

初期:以 UI 配置为主快速验证

中期:转向 Python API 获取更多控制力

长期:核心功能代码化以支持定制和持续优化

组件化架构优势:

分词组件可独立升级而不影响其他部分

向量数据库可平滑迁移或替换

大模型供应商可灵活切换

扩展接口预留:

数据源接口:支持未来接入新数据源

评估接口:便于接入第三方评估工具

人工干预接口:在自动化流程中预留人工介入点

4.3 评估和迭代策略

最佳实践:

多维度评估指标:

准确性:回答中正确信息的比例

完整性:回答覆盖问题所需信息的程度

相关性:回答与问题的直接关联程度

有用性:回答对用户实际问题的解决价值

标准测试集构建:

覆盖核心业务场景的典型问题

包含边界情况和挑战性问题

定期更新以反映业务变化

监控体系建设:

技术监控:响应时间、错误率、系统负载

业务监控:使用频率、解决率、用户满意度

成本监控:API 调用量、存储使用量、计算资源消耗

以上算是个比较完整的 checklist,大家可以针对自己的业务实践辨证参考,其实总结下来也就是两个原则:场景聚焦策+业务价值驱动。初期要从单一明确的场景入手,POC 之后再进行扩展,其次优先解决业务价值提升明显的问题。当然,还有一个重要的原则就是要公司内部跨部门协作,一个好的 RAG 应用一定靠用户反馈不断迭代出来的。

责任编辑:庞桂玉 来源: 韦东东
相关推荐

2010-09-27 13:45:38

2011-04-07 09:07:00

外包项目

2023-02-28 16:26:46

推荐系统模块

2015-07-23 10:39:41

2015-10-13 17:11:46

蓝牙物联网

2020-09-21 19:34:07

DevOps

2019-08-05 07:55:57

2017-07-11 16:13:42

云迁移IP地址企业

2012-06-14 08:46:03

IDC云计算

2018-11-14 10:05:58

5G4G网络

2023-12-12 11:27:58

2009-06-17 14:33:08

java项目开发

2017-10-20 10:34:37

存储双活实施

2013-05-30 14:21:38

2022-07-31 19:59:42

文档管理工具互联网

2009-12-16 10:08:07

2019-05-07 10:28:27

2020-09-18 07:21:36

WLAN系统

2017-11-06 10:00:01

ERP管理数字化

2010-01-12 21:29:16

点赞
收藏

51CTO技术栈公众号