1. 从搜索到生成：RAG技术演进之路
第一次接触RAG（Retrieval-Augmented Generation）是在处理客户问答系统时遇到的典型困境——纯生成式模型经常编造事实，而传统检索系统又缺乏语言组织能力。当时用BERT构建的检索模块准确率已经达到82%，但拼接生成的回答总感觉生硬不连贯。直到看到Meta发布的RAG论文，才意识到这两项技术可以像齿轮般精密咬合。
现在看RAG架构，核心就是三个齿轮的啮合：检索齿轮负责从海量数据中抓取相关片段，编码齿轮将这些信息转化为向量空间里的坐标，生成齿轮则像绘图师一样根据坐标描摹出自然语言。但要让这套齿轮组运转顺滑，每个部件的公差控制都至关重要。
2. 检索模块的精度革命
2.1 向量化策略的进化史
早期直接使用BERT的[CLS]token向量效果并不理想，在FAQ数据集上测试时，相似问题召回率只有65%。后来改用sentence-transformers的all-MiniLM-L6-v2模型，通过对比学习优化的句向量显示出明显优势。这里有个反直觉的发现：更大的模型并不总是更好，在测试中all-mpnet-base-v2虽然benchmark分数更高，但在我们特定领域的法律文本上反而比小模型低3个点。
关键教训：领域适配性比基准分数更重要，建议先用小模型快速验证
2.2 混合检索的黄金比例
单纯向量检索在处理专业术语时容易漏检，我们开发了混合检索策略：
- 先用Elasticsearch进行关键词初筛（保证召回）
- 再用向量模型做精排（保证精度）
- 最后用规则引擎过滤敏感内容
这个组合使得医疗领域的检索准确率从71%提升到89%。特别要注意的是第二阶段的向量搜索必须限定在第一阶段的结果集内，否则计算量会指数级增长。
3. 生成模块的可控性调教
3.1 提示工程的隐形控制杆
使用FLAN-T5模型时，发现提示模板中引用标记的位置直接影响生成质量。最优模板结构是：
python复制template = f"""基于以下背景知识：
{context}
请回答：{question}
必须严格依据背景信息，不得自行编造。"""
这个模板相比原始版本使幻觉率降低了42%。更关键的是要在few-shot示例中展示"拒绝回答"的情况，让模型学会在检索结果不相关时说不。
3.2 温度参数的蝴蝶效应
在法律咨询场景下测试发现：
- 温度0.3时回答严谨但像法条堆砌
- 温度0.7时语言自然但可能偏离法条
- 最佳平衡点在0.45，此时BLEU分数和人工评分都最高
这个参数需要配合max_new_tokens一起调整，我们建立的经验公式是：
code复制max_new_tokens = 平均答案长度 × (1 + 温度值)
4. 端到端优化中的黑暗森林
4.1 评估指标的陷阱
最初只关注BLEU和ROUGE分数，直到客户投诉才发现问题——模型会把检索到的不相关内容也编织进回答。后来引入三个新指标：
- 事实一致性（FactScore）
- 检索相关性（KNN验证）
- 安全过滤通过率
这促使我们重写了30%的prompt逻辑。现在会先用规则检查生成内容是否包含检索片段的关键实体，没有就自动触发重生成。
4.2 缓存策略的隐藏成本
为提升响应速度引入了Redis缓存，却导致时效性内容更新延迟。最终方案是分层缓存：
- 事实类答案缓存24小时
- 时效性内容缓存5分钟
- 每次检索先检查数据更新时间戳
这个方案使API响应时间从1200ms降到380ms，同时保证新闻类问题的时效性。
5. 实战中积累的生存法则
- 数据预处理阶段一定要保留原始文本偏移量，这对后期调试检索失败案例至关重要
- 生成模型的system prompt要预留版本号字段，便于AB测试
- 定期用对抗样本测试系统，比如故意输入矛盾的前提条件
- 监控面板必须区分检索失败和生成失败，两者的优化策略完全不同
- 在部署前用错别字测试鲁棒性，法律场景的容错率要比客服场景低得多
最近发现的新方向是让检索模块也能从生成反馈中学习——当用户明确纠正某个答案时，不仅更新生成模型，还要反向标注检索结果的相关性。这套机制使系统在金融领域的迭代速度提升了3倍。