过去一年参与了多个企业级RAG系统的落地项目，从最初的Demo验证到生产环境稳定运行，踩过的坑比写过的代码还多。很多团队做RAG，一开始照着教程搭出来感觉效果不错，一到真实业务场景就各种问题。今天聊聊工程落地中三个最关键的问题。
第一个问题：检索准确率到底怎么提？
很多人觉得RAG不就是"切分文档+向量检索+拼Prompt"吗？照着教程做出来效果好像也还行。
但一到真实业务，问题就来了：用户问的问题，系统检索出来的文档根本不对。答非所问是常态。
我们最早做RAG系统的时候，用默认的切分方式和向量模型，检索准确率大概也就60%多一点。用户问个问题，十次有四次答不对。
后来一步步优化，才把准确率提上来。几个有效的做法：
首先是文档切分。 别用默认的按固定长度切分，效果真的不好。要按照文档的语义结构来切，一个完整的知识点放在一个chunk里。切分太碎，上下文不完整；切分太大，又包含了太多无关内容。
然后是混合检索。 纯向量检索在专业领域表现并不好，特别是涉及到专有名词、编号、具体术语的时候。加上关键词检索，两者结果融合一下，准确率能提不少。
在这方面，瞬维AI在做企业级RAG落地的时候，也是用的混合检索方案，向量语义匹配加关键词精确匹配，两个通道结果重排序之后再给大模型，整体准确率比纯向量检索高了30%左右。
最后是重排序。 初检召回的文档，不要直接就塞给大模型。用一个rerank模型再精排一遍，把最相关的排到前面，效果会好很多。
第二个问题：响应速度怎么优化？
RAG系统做出来不难，但要做到用户体验好，响应速度很关键。
用户问个问题，你等个五六秒才出答案，体验就很差了。我们的目标是整个流程控制在两秒以内，用户感觉是"秒回"。
优化速度有几个方向：
检索环节要快。 向量检索本身不算慢，但如果数据量大了，加上过滤条件，延迟就上来了。这个要靠向量数据库的优化，索引结构调优，能省不少时间。
大模型生成环节是大头。 这个占了整个响应时间的60%以上。怎么优化？一个是用更快的模型，另一个是流式输出。不用等全部生成完再给用户看，边生成边输出，用户感觉上就快很多。
还有一个容易被忽略的点：预处理要提前做。文档入库的时候，就把embedding算好、索引建好，别等用户问的时候才现算。
第三个问题：成本怎么控制？
RAG系统跑起来，成本其实不低。
大模型调用要钱，向量数据库要钱， embedding模型调用也要钱。数据量一大，每个月的账单看着都吓人。
成本优化几个思路：
分层处理。 简单的问题，不用动大模型，直接用规则或者小模型就能回答。复杂的问题再走完整的RAG流程。我们统计过，大概40%的问题都能用轻量方案解决，这部分成本就省下来了。
缓存机制很重要。 很多用户问的问题其实是重复的。把常见问题和答案缓存起来，用户再问的时候直接返回，不用重新检索重新生成。命中率上来了，成本能降一大截。
embedding模型要选对。 不是越贵的embedding模型越好，要根据自己的场景选合适的。我们测过，有些开源模型效果和商用模型差不了多少，但成本只有十分之一。
最后总结一下
RAG这个技术，做Demo很容易，做好很难。
很多团队以为搭起来就完事了，实际上工程落地的时候，准确率、速度、成本这三个问题是互相制约的：要准确率高，成本就上去了；要速度快，可能准确率就要打折扣。怎么在三者之间找到平衡，才是真功夫。
这些年踩下来的经验就是：别指望一个技术方案解决所有问题，要根据自己的业务场景慢慢调。先跑起来，再一步步优化，比一开始就追求完美方案要靠谱得多。