文章摘要
作者分享了在处理超过500万份文档构建生产级RAG系统时的经验教训。初期使用Langchain和Llamaindex快速搭建原型效果良好，但在实际生产数据上表现不佳。经过数月优化，发现查询生成、数据分块策略和嵌入模型选择对系统性能提升最为关键。这些实践为大规模RAG系统开发提供了宝贵参考。
文章总结
标题：生产级RAG实战：从处理500万+文档中获得的经验
作者在过去8个月深入RAG（检索增强生成）实践，分享了为Usul AI（900万页面）和某法律AI企业（400万页面）构建RAG系统的实战经验。以下是核心发现：
关键改进措施（按投资回报率排序）： 1. 查询生成：通过LLM分析对话线程生成多组语义+关键词查询，并行处理并交由重排序器，显著提升检索覆盖面 2. 重排序技术：50个输入块→15个输出的重排序设置效果最佳，能有效弥补初始设置缺陷 3. 分块策略：需构建定制流程，确保分块完整性（避免中断词句）和逻辑独立性 4. 元数据利用：向LLM注入标题、作者等元数据可大幅提升回答质量 5. 查询路由：通过轻量级路由器识别非RAG问题（如摘要生成），改用API+LLM处理
技术栈演进： - 向量数据库：Azure→Pinecone→Turbopuffer（性价比高，原生支持关键词搜索） - 重排序器：无→Cohere 3.5→Zerank（小众但高效） - LLM使用：GPT 4.1→GPT 5→回归GPT 4.1（受Azure额度影响）
开源成果： 已将全部经验整合至MIT协议开源项目agentset-ai/agentset，欢迎开发者交流。
（注：原文中关于初期使用Langchain/Llamaindex的试错过程、具体时间线等非核心细节已简化，保留关键技术决策和量化数据）
评论总结
以下是评论内容的总结，平衡呈现不同观点并保留关键引用：
分块策略的重要性
- 多位评论者强调分块(chunking)是RAG系统的关键环节
- manishsharan："I found acceptable results by shoving large texts to gemini flash and have it summarize"（使用Gemini Flash总结大文本效果优于普通分块器）
- esafak："theirs looks rudimentary...nothing here that one could not easily write without a library"（批评现有分块实现过于基础）
重排序模型(reranker)的争议
- 支持方：daemonologist："big LLM-based rerankers are what you always wanted...highly recommend"（基于LLM的重排序效果显著）
- 反对方：jascha_eng："we simply ask GPT-5...is there an advantage to actual reranker models?"（质疑专用重排序模型相比通用LLM的优势）
查询生成的价值
- mediaman："we had it create three variants...combined into a set of broadly strong performers"（生成多查询变体提升搜索效果）
- alexchantavy提问："What does query generation mean in this context"（询问查询生成的具体含义）
嵌入模型的比较
- 383toast："there are better ones than openai's (and cheaper)"（指出存在比OpenAI更优且更便宜的嵌入模型）
- leetharris："Embedding based RAG will always just be OK at best"（认为基于嵌入的RAG效果有限）
实践经验分享
- js98分享类似项目："Similar writeup I did about 1.5 years ago"（分享处理百万页技术文档的经验）
- n_u询问："Why not just show the code if it's only 5 lines?"（要求展示所谓"5行代码"的具体实现）
技术选型差异
- manishsharan："I do not use Langchain or python.. I use Clojure+ LLMs' REST APIs"（使用非主流技术栈）
- nextworddev提醒："Your pipeline is a function of the use case"（强调应根据具体用例设计流程）