在修复这 7 个错误之前，我在 RAG 基础设施上花了 500 美元
我为私有文档搜索构建了一个 RAG 流水线。这花费了我 500 美元的计算成本和数周的调试时间。结果却很糟糕：用户得到的答案是错误的，查询速度也很慢。
我对流水线进行了审计，发现了 7 个错误。修复它们之后，一切都改变了。
- 固定的 Token 分块 (Fixed Token Chunking) 我按 512 个 token 来拆分文档。这破坏了上下文。一个 API 的解释可能会在句子中间被切断。LLM 接收到的是碎片，从而给出了垃圾答案。 修复方法：使用语义分块 (semantic chunking)。
- 按段落或标题等自然边界进行拆分。
- 使用父文档检索 (parent-document retrieval)。
- 创建小的子块 (child chunks) 用于搜索。
- 将完整的父文档返回给 LLM。
- 在分块之间添加 10-20% 的重叠。
- 错误的混合搜索权重 (Bad Hybrid Search Weights) 我对向量搜索和关键词搜索采用了 50/50 的比例。这在处理技术文档时失效了。技术用户需要精确的关键词匹配。 修复方法：使用动态权重。
- 事实性查询：35% 向量，65% 关键词。
- 语义查询：75% 向量，25% 关键词。
- 通用查询：60% 向量，40% 关键词。
- 过度调优 HNSW 参数
我将
ef_construction设置到了最大值。这导致我的服务器崩溃了，因为它耗尽了所有可用内存 (RAM)。 修复方法：使用合适的参数。
- 将
M设置在 8 到 32 之间。 - 将
ef_construction设置为 200。 - 将
ef_search设置为 50。 内存占用降低了 70%。
通用嵌入模型 (General Embedding Models) 我使用了一个在维基百科上训练的模型。而我的文档是技术工程运行手册 (runbooks)。该模型无法理解我的领域知识。 修复方法：使用针对技术或代码内容进行微调的模型。
缺乏查询重写 (No Query Rewriting) 用户问的是自然语言问题，而技术文档使用的是正式术语。两者无法匹配。 修复方法：增加一个轻量级的 LLM 步骤来重写查询。
- 用户提问：“why is my build slow”（为什么我的构建很慢）
- 系统重写为：“CI pipeline performance optimization”（CI 流水线性能优化）
- 这将召回率 (recall) 提升了 40%。
结果冗余 检索前 10 个分块时，经常会出现同一个段落重复出现三次的情况。LLM 也会随之重复同样的内容。 修复方法：使用最大边际相关性 (MMR) 来确保结果的多样性。
测试方向错误 我当时是一次性测试整个流水线。我无法确定问题出在检索环节还是 LLM 环节。 修复方法：将检索评估独立出来。
- 追踪命中率 (hit rate)。
- 追踪平均倒数排名 (MRR)。
- 构建一个包含 100 个“查询-文档”对的测试集。
修复后的结果：
- 回答相关性：45% 到 85%
- 延迟：3.2s 到 1.8s
- 月度成本：$180 到 $95
先修复分块，然后是权重，最后是嵌入质量。