1. 从30%到90%：一个RAG技术实践者的深度复盘
去年团队接到一个硬任务：要在三个月内搭建一个企业知识库智能问答系统。当时市面上最火的就是RAG（检索增强生成）技术路线，号称"简单易用效果好"。我们兴冲冲地上了第一版，结果用户反馈直接打脸——准确率只有惨淡的30%。经过半年多的持续优化，现在系统准确率稳定在90%左右。今天就把这段踩坑填坑的经历完整分享给大家，特别是那些刚接触大模型的小伙伴们。
2. RAG技术栈的实战演进
2.1 初代版本的技术选型
我们的V1版本采用了当时社区推荐的主流方案：
- 文档处理：按三级标题切分，每段500-1000个token
- 向量模型：智源的bge-large-zh-v1.5
- 检索方案：ElasticSearch关键词检索+向量检索的混合方案
- 生成模型：ChatGLM3-6B
这套配置在测试集上表现不错，但真实场景立刻暴露问题：用户的问题千奇百怪，测试集没覆盖的长尾问题准确率直线下降。最典型的就是当用户问"这个功能怎么用"时，系统经常返回功能列表而不是具体操作步骤。
关键教训：测试集要包含20%以上的边缘case，最好直接采集真实用户历史问题
2.2 核心突破点：召回率优化
真正的转机出现在2024年初，三个技术突破让我们有了新武器：
- 阿里云Qwen2系列发布，支持32k上下文
- 智源推出bge-m3向量模型和专用reranker
- 社区开始讨论long context与RAG的优劣平衡
我们做了组对比实验很有意思：当把召回文档数从5篇增加到15篇时：
- 纯向量搜索准确率：58% → 72%
- 增加reranker后：68% → 85%
- 成本增加：响应时间从1.2s→2.8s，显存占用从8G→14G
最终采用的召回流水线：
python复制# 伪代码示例
def retrieve(query):
# 第一轮：向量粗排
vector_results = vector_search(query, top_k=100)
# 第二轮：reranker精排
reranked = reranker_model.rerank(query, vector_results)
# 截断策略
final_results = apply_length_aware_cutoff(reranked, max_tokens=8000)
return final_results[:15]
2.3 生成模型的选型博弈
在7B和72B模型间我们做了组对比测试：
| 模型类型 | 准确率 | 响应时间 | 显存占用 | 每千token成本 |
|---|---|---|---|---|
| Qwen2-7B | 89% | 2.1s | 12GB | $0.0021 |
| Qwen2-72B | 92% | 4.8s | 48GB | $0.0087 |
| ChatGLM3-6B | 76% | 1.8s | 10GB | $0.0018 |
最终选择Qwen2-7B的三个理由：
- 性价比曲线在7B处出现拐点
- 支持32k上下文但实际10k就够用
- 对行业术语的理解明显优于ChatGLM3
3. 那些文档不会告诉你的实战技巧
3.1 文档处理的隐藏知识点
-
分块策略：不要简单按字数切分。我们发现带层级结构的切分效果最好：
markdown复制[理想分块示例] ## 功能A ### 使用前提 需要先完成X配置... ### 操作步骤 1. 点击... 2. 输入... -
元数据注入：给每个chunk添加这些字段：
- parent_section：所属章节路径
- doc_type：操作指南/API参考/FAQ等
- freshness_score：文档新鲜度评分
3.2 检索环节的调参秘籍
-
混合检索权重：
- 常规问题：向量权重0.7，关键词0.3
- 专有名词问题：向量0.4，关键词0.6
- 需要动态调整阈值：
python复制if contains_technical_term(query): weights = [0.4, 0.6] elif is_procedural_query(query): weights = [0.8, 0.2] -
Query改写技巧：
- 简单问题扩展："登录失败" → "系统登录失败的常见原因及解决方法"
- 添加领域前缀："报错500" → "[电商系统]报错500的排查方法"
3.3 生成环节的prompt工程
我们最终采用的prompt模板：
code复制你是一个专业的{domain}助手，请根据以下上下文回答问题。
相关文档：
{document_chunks}
用户问题：{query}
回答要求：
1. 如果文档中有明确答案，直接引用原文
2. 如果需要推理，保持严谨专业
3. 不确定时明确告知"根据现有资料..."
4. 用中文回答，控制在200字内
关键技巧是在few-shot示例中展示：
- 如何说"不知道"
- 如何合并多个来源的答案
- 如何处理矛盾信息
4. 产品化过程中的血泪教训
4.1 文档质量决定上限
我们建立了文档健康度评估体系：
- 覆盖度检测：定期用高频问题反向检查文档
- LLM友好度评分：
- 段落连贯性
- 术语一致性
- 示例完整性
- 动态补充机制：当某个问题被连续拒绝3次，触发文档更新流程
4.2 交互设计的魔法数字
通过AB测试发现的几个关键阈值：
- 答案长度：180-220字接受度最高
- 相关文档展示：3篇最优（更多反而降低信任度）
- 追问建议：提供2-3个最相关后续问题
4.3 持续迭代的飞轮效应
我们建立的优化闭环：
- 用户反馈标记低分答案
- 人工分析归类（知识缺失/检索错误/生成错误）
- 针对性优化后加入测试集
- 每周回归测试确保不倒退
5. 给初学者的实操建议
如果你正在搭建第一个RAG系统，我的建议路线图：
-
基础版（1周）：
- 文档处理：LangChain的RecursiveCharacterTextSplitter
- 向量库：ChromaDB
- 模型：Qwen1.5-7B + bge-small
-
优化版（2-3周）：
- 升级bge-m3向量模型
- 添加bge-reranker-large
- 实现混合检索策略
-
进阶版（1个月+）：
- 构建领域测试集
- 设计query理解模块
- 实现动态分块策略
最关键的是尽早让真实用户使用系统，我们70%的优化灵感都来自用户的实际反馈。记住：RAG不是一次性的项目，而是需要持续调优的生态系统。