春节之后的一个月的时间内,微信和小红书上数了下大概有 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 应用一定靠用户反馈不断迭代出来的。