组里最近接了个工单：把公司五年技术文档喂给大模型，做内部问答助手。产品第一反应："直接微调呗？"我摇了摇头——这是 RAG 的主场，不是微调的。很多人把 RAG 想复杂了。说白了，大模型是闭卷考生，RAG 就是给它配本小抄：用户提问 → 去向量库翻最相关的几页 → 原文+问题一起塞给模型 → 照着答。公式就一句：RAG = 检索 + 生成。那为啥不微调？三个硬理由：- 知识要保鲜：微调一次几万块、按周算；公司文档天天改，RAG 重建索引十分钟。- 幻觉可控：证据拍脸上，纯生成幻觉率比 RAG 高 60%+。- 能追溯：答错知道它翻了哪几页，微调做不到。什么时候才用微调？模型要学新能力/新风格；查新知识，永远选 RAG。两者是搭配，不是二选一。最小可用版四步走：1. 建索引：文档清洗 → 切 chunk（代码 800-1000 token，文档 300-500 token，重叠 10%-15%）→ Embedding → 丢进 Milvus / FAISS。2. 检索：问题转向量，cosine 取 top-3~5。3. 拼 Prompt："根据以下资料回答，没有就答不知道"+检索原文+用户问题。4. 生成：丢给 LLM 吐答案。但 90% 的 RAG 项目死在检索这步，不是生成。我们上线前命中率 72%，调完这四件套飙到 89%：- 混合检索：BM25 关键词 + 向量加权，别纯靠向量（搜"GPT-4o"别退回"大模型"）。- Rerank 必加：粗筛 top-20，bge-reranker 精排 top-3 进 LLM。- 查询改写：用户问"咋整"，先改写成"公司报销流程申请步骤"再检。- Metadata 过滤：时间/部门/文档类型先 filter，噪声少一半。我们那个内部助手，上线三个月日均 2000+ 提问，满意度 4.6。RAG 听着高大上，拆开就是"查资料+照着答"。真正拉开差距的，不是你用哪个向量库，而是 retrieval 那层调得细不细。上面这套四件套齐了，企业级场景基本扛得住。如果这篇帮你少踩一个坑，点个赞再走 👇
发布于 河南
分享
1
2
未登录
友善发言
评论
加载中
