企业官网建设流程全解析

如果你的 RAG 问答系统还停留在“检索 Top5 直接塞给大模型”的阶段，准确率卡在 60% 左右非常正常。这个数字并不是模型不行，而是链路里至少有三个环节没做满：召回不够准、排序不够细、生成不够稳。这篇文章就把 RAG 准确率从 60% 提到 80% 的工程化路径拆开讲，从切分策略、混合检索、Query 改写、Rerank 重排、上下文压缩到评测集建设，每一步都给出可落地的操作和验证方法。

先说结论：RAG 的准确率不是靠换一个大模型就能解决的，而是一个系统工程。embedding 模型、chunk 切分、检索召回、重排序、Prompt 组织、评测标准，任何一环偏弱都会直接压住准确率上限。下面我按“定位问题 -> 升级链路 -> 建立评测 -> 验证迭代”的顺序来写，核心是让你在自己的数据集上能把准确率一步步拉起来。

如果你正在做大模型应用、RAG 知识库、本地部署或智能问答这类方向，这篇文章可以直接收藏备用。文中所有方案都以通用开源技术为主，可以适配到本地部署的向量库和 Rerank 服务。

1. RAG 准确率拆解：先搞清楚卡在哪

很多人优化 RAG 的第一反应是换 Prompt、换模型，但准确率变化很小。原因在于 RAG 系统的准确率由多个环节叠加决定：查询理解、召回质量、重排质量、上下文组织、生成忠实度。其中任何一个环节召回率低，后面的生成环节再强也拿不到正确答案。

一个典型的低准确率现象是：用户问一个业务问题，系统返回的片段看着相关，但关键数字或结论不对。这种问题的根因通常不在生成端，而在检索端——正确答案根本没有进到上下文里。

从工程角度看，RAG 的“准确率”应当分层度量：

如果端到端准确率只有 60%，建议不要直接去调 Prompt，先跑一轮批量评测，把 Hit Rate 和 Groundedness 分别测出来。如果 Hit Rate 低，说明知识没被检出来，重点改切分、embedding 和检索方式；如果 Hit Rate 高但最终回答错，说明是上下文组织或生成阶段的问题。

判断优先级很简单：先保证“正确的知识被找到”，再保证“找到的知识被用好”。这是从 60% 到 80% 最核心的思路转变。

2. 核心能力速览

3. 先建评测集，再谈准确率

没有评测集就谈不上准确率。很多团队反复调 Prompt 但效果不稳定，就是因为没有把问题转成可重复验证的测试集。RAG 优化必须是数据驱动，而不是感觉驱动。

评测集建议包含三个部分：

• 问题文本。
• 标准答案。
• 该问题对应的参考文档片段或文件路径，用于验证检索命中。

第一版评测集不需要很大，50 到 100 条精选问题就够一轮迭代。关键在于覆盖典型场景：常见的业务问题、含数字或代码的精确问题、多轮改写问题、跨文档综合问题、没有答案的对抗问题。只要评测集覆盖度够了，后续每次调整都能看到准确率数字的上下浮动。

这里给出一个通用评测集 CSV 结构：

question,answer,source_doc,expected_chunk "本季度营收是多少？","营收为 1200 万元。","finance_report.md","finance_report.md#L42" "如何重置密码？","进入设置页点击重置。","user_guide.md","user_guide.md#L85"

在批量评测脚本里，检索结果可以这样判断是否命中：

def is_hit(retrieved_chunks, expected_chunk): for chunk in retrieved_chunks: if expected_chunk in chunk["source"] or expected_chunk == chunk["id"]: return True return False

有了评测集和命中判定，后面每一步改动都能对比出准确率。这是整个 60% 到 80% 提升过程的地基。

4. 单路检索改为混合检索：提升召回率的关键一步

很多 RAG 系统只用向量检索。向量检索对语义相似的问题效果好，但对精确关键词、型号、编号、人名这类查询很弱。比如用户问“A100 和 H100 的显存分别是多少”，向量检索可能找出一堆概念相似的“显存介绍”，反而漏掉精确对比表。

混合检索（Hybrid Search）是提升召回最直接的手段：向量检索负责语义召回，BM25 或全文检索负责关键词精确匹配，最后融合两边结果取交集并集。

具体实现时可以选择 Elasticsearch + embedding、Milvus + sparse encoder、Qdrant 自带的 sparse+dense 混合查询，甚至自己用向量库 + whoosh/elasticsearch 做双路召回。

下面是一个伪代码结构，演示混合检索的融合逻辑：

def hybrid_search(query, top_k=20): dense_results = vector_search(query, top_k=top_k) # 向量检索 bm25_results = bm25_search(query, top_k=top_k) # 关键词检索 # 分数归一化后加权融合 fused = {} for rank, item in enumerate(dense_results): score = 1.0 / (rank + 1) fused[item["id"]] = fused.get(item["id"], 0) + score for rank, item in enumerate(bm25_results): score = 1.0 / (rank + 1) fused[item["id"]] = fused.get(item["id"], 0) + score * 0.4 ranked = sorted(fused.items(), key=lambda x: x[1], reverse=True) return [item_id for item_id, _ in ranked[:top_k]]

这里的关键是向量检索和 BM25 的结果要按排名做融合，而不是直接拼接。如果材料库里同一篇文档在两个检索结果中都出现，说明它更可能是正确答案，排名应当上升。

实践中有一个值得注意的点：向量检索的 TopK 可以适当调大，比如从 5 调到 20，因为后面还有 Rerank 会做精细排序。过早截断会让正确的片段在召回阶段就消失。

5. 切分策略：决定检索质量的上限

很多人忽略切分，直接按固定长度把文档切成 512 个字符的 chunk。这种做法的最大问题是一个完整的段落、一张表格或一个业务规则被切成两部分，正确答案的信息被拆散了，检索时无论命中的是哪一半，大模型都得不到完整答案。

切分策略要根据文档类型分场景处理：

• 结构清晰的 Markdown/HTML：按标题层级切，保留标题信息作为 metadata。
• 工整的段落文本：按段落切，保持每个 chunk 语义完整。
• 表格类文档：尽量表格整体作为一个 chunk，否则拆列对齐。
• 代码文档：按函数、类切，避免按字符硬切。
• 父子切分：父亲 chunk 大，保留整体语义；子 chunk 小，负责精确命中。召回子 chunk 时返回父 chunk 给大模型。

要做到从 60% 到 80%，至少要检查两种常见问题：

• 正确答案跨了两个 chunk。
• chunk 之间没有 overlap，边界处信息丢失。

切分参数也不是固定值，需要评测验证。以通用文本为例，可以先从 chunk_size=512、overlap=50 起步，再试 256 和 768，看 Hit Rate 指标变化。更合理的方式是按层级先做结构切分，再对超长段落做补偿切分，这样能减少语义断裂。

租一个重要经验：切分完成后一定要做一轮“盲检”，随机挑 20 个问题，手动定位标准答案，看它落在哪个 chunk。如果答案正好被切散，你会立刻看到 Hit Rate 低的原因。

6. Query 改写：把问题本身变准

RAG 系统上线后，用户的问题常常是模糊的、口语化的，甚至包含指代词。比如用户先问“为什么我的实例连接超时？”再问“如何解决？”这里第二个问题只有结合上下文才能检索，单纯把它拿去向量化，大概率会召回一堆不相关内容。

Query 改写通常包括三类操作：

1. 指代词替换：把“它”“这个”“上述问题”替换成明确的实体名。
2. 口语转书面：把“怎么搞”“咋弄”改写成“如何操作”。
3. 多轮压缩：把历史对话压缩成一个独立提问，再进行检索。

最简单的多轮改写可以用 LLM 做，调用成本不大：

prompt = """ 请将用户的当前问题改写为一个适合检索的独立问题。 要求：保留关键实体和数字，替换指代词，不要添加额外信息。 历史对话： {history} 当前问题： {question} 改写后的独立问题： """

Query 改写对多轮对话场景的准确率提升非常明显，因为向量检索对长对话拼接的内容非常敏感。如果希望在本地跑这一步，可以部署一个 7B 级别的本地模型服务，也可以直接接外部大模型 API。

另一种 Query 改写思路是 HyDE（Hypothetical Document Embedding）：先让大模型根据问题生成一段假设答案，再用假设答案做向量检索。这个方向对描述型问题有效，但在精确数字、列举型问题上效果有限，需要按场景验证。

7. Rerank 重排：从 Top20 到 Top5 的精细挑选

混合检索可以召回 Top20 个候选片段，但直接把这些片段全部塞给大模型，既费 token 又稀释注意力，还容易让模型看到不相关的内容后胡编。Rerank 的作用就是在这 Top20 里精确挑出 Top3 到 Top5，交给生成模型。

Rerank 通常使用交叉编码器（Cross-Encoder），将问题和候选文本一起输入模型，输出相关性分数。因为要做模型推理拉近距离，它对显存和延时都有一定要求，但对准确率提升非常显著。

这里以常用的 bge-reranker 系列为例，演示大致的加载思路：

from FlagEmbedding import FlagReranker reranker = FlagReranker('BAAI/bge-reranker-v2-m3', use_fp16=True) question = "如何重置密码" candidates = [ "打开设置页面，点击安全选项。", "密码是用户登录系统的凭证，应当定期修改。", "用户可以在账号管理中重置密码。", ] scores = reranker.compute_score([[question, c] for c in candidates]) ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True) for cand, score in ranked: print(f"{score:.4f}\t{cand}")

实际项目中，Rerank 分数还需要和前面混合检索的分数做融合，或者直接把 Rerank 结果作为最终排序依据。建议在评测集上分别测试“只用混合检索”和“混合检索 + Rerank”两版 Hit Rate，以数据确认收益。

Cross-Encoder 类 Rerank 的精度普遍比 Bi-Encoder 高，但计算量更大，不适合对每个候选直接做全量排序。通常做法是先用低成本的混合检索召回 Top20 到 Top50，再用 Rerank 精排 Top5，兼顾速度和准确率。

如果你使用的是 Elasticsearch 或向量数据库，也可以把 Rerank 封装成一个独立服务，接到检索链路上。这样后续想替换成更强的 Rerank 模型时，不用改业务代码。

8. 上下文组织与生成端约束：让大模型不跑偏

到这里，检索环节基本调好了，正确内容已经进入瓶颈。接下来要解决的是“把正确上下文用好”的问题。

很多 RAG 系统在给大模型的 Prompt 里直接拼接多段关联内容，没有任何来源区分，也没有“没有依据不要回答”的约束。这样大模型很容易把不相关信息也纳入回答，或者强行编造一个答案。上下文组织建议做好这几件事：

• 只保留相关性高的片段，候选数量不宜超过 5 个。
• 给每个片段附上来源元数据，方便模型引用。
• 在 Prompt 中明确“只能基于以下片段回答”。
• 设置“如果片段没有答案，直接说没有找到”的兜底约束。
• 对长文本做摘要压缩，避免无关内容干扰生成。

一段可行的 Prompt 模板如下：

你是企业知识库助手。请基于提供的文档片段回答问题。 片段1：{chunk_1} 来源：{source_1} 片段2：{chunk_2} 来源：{source_2} 问题：{question} 要求： 1. 只使用上述片段中的信息。 2. 如果片段中没有答案，请回复“根据已有文档无法回答”。 3. 回答中标注引用来源编号。

这里还可以做上下文压缩：如果某个片段有大量无关内容，只提取与问题相关的句子再拼接。这一步对大模型的上下文长度要求低，也能降低生成噪声。

上下文组织完成后，端到端准确率的提升会更显性——因为黄金片段已经进去了，关键是别让模型绕开它。

9. 批量评测与接口接入：数据驱动迭代

RAG 优化不是一次就完事，而是一个迭代过程。建议固定一个评测脚本，每次改完参数，跑一遍评测集，记录准确率变化。这样从 60% 到 80% 的过程有据可查。

下面是一个批量评测的简化流程：

import pandas as pd from tqdm import tqdm df = pd.read_csv("eval_set.csv") for idx, row in tqdm(df.iterrows(), total=len(df)): question = row["question"] chunks = hybrid_search(question, top_k=20) top_chunks = rerank(question, chunks, top_n=5) hit = is_hit(top_chunks, row["expected_chunk"]) if hit and not row.get("answer_hit"): answer = generate_answer(question, top_chunks) row["answer_hit"] = judge_answer(answer, row["answer"]) hit_rate = df["hit"].mean() accuracy = df["answer_hit"].mean() print(f"Hit Rate: {hit_rate:.2%}, End-to-End Accuracy: {accuracy:.2%}")

这里的 judge_answer 可以用人工判断，也可以用 LLM 打分。LLM-as-Judge 适合批量初筛，但请尽量在核心数据上保留人工抽检，避免模型自我偏好干扰。

接口接入方面，你完全可以把检索链路拆成 HTTP 服务。一个简单的检索服务接口可以这样约定：

curl -X POST http://127.0.0.1:8000/search \ -H "Content-Type: application/json" \ -d '{"query": "如何重置密码", "top_k": 5}'

返回结果建议包含：

{ "query": "如何重置密码", "results": [ { "chunk_id": "user_guide.md#L85", "text": "用户可以在账号管理中重置密码。", "score": 0.91 } ] }

有了接口，后续无论是接前端对话框、企业微信机器人，还是做内部知识库工具，都会方便很多。本地部署时要注意绑定地址、端口、访问权限这三个问题，避免把检索接口直接暴露到公网。

10. 资源占用与性能观察

RAG 系统的资源消耗集中在三个部分：embedding 向量化、rerank 模型推理、大模型生成。如果你只做检索优化，CPU 机器也能跑混合检索，但 rerank 和生成环节如果放在本地，就需要重点关注显存占用。

建议在测试环境里用以下命令或工具观察性能：

• 使用nvidia-smi观察 GPU 显存和利用率。
• 使用top或free -m观察内存。
• 使用time、requests或llm的耗时统计函数记录单次调用延迟。
• 批量任务时记录队列长度和失败重试次数。

显存占用不是一个固定值，它会随模型尺寸、输入长度、batch size 变化。以 bge-reranker 系列为例，模型越大精度越好在实践中常见，但也要保证 GPU 能跑得动批量推理。显存不足时优先减小 batch size 或改用 API 版 rerank 服务。

性能观察要区分“首次冷启动”和“稳态调用”。冷启动会加载模型文件，耗时较长；稳态调用才是真实性能。批量任务建议在代码里加 Warm-up，比如启动时先跑一条假请求，让模型提前加载到显存。

另外，检索链路本身也要做缓存。用户问过的问题、相同或相似的问题，可以在 Redis 或内存里缓存检索结果，减少重复计算。缓存命中率上去了，整体延迟会明显下降，也能降低对 GPU 的压力。

11. 常见问题与排查方法

日常排查时建议先保留一条最小可运行链路：一个 query 进来，分别打印检索 Top20、Rerank Top5、生成结果。每一步都输出，问题出在哪一目了然。不要直接看最终答案，中间环节透明化是提高准确率的前提。

12. 最佳实践与合规提醒

从 60% 到 80% 的完整工作流，可以沉淀成下面这套实践方法：

1. 先建一个 50 到 100 条的评测集，定义 Hit Rate 和端到端准确率。
2. 检查切分策略，优先结构切分，避免答案跨 chunk。
3. 从单路向量检索改为混合检索，把 TopK 调大到 20 到 50。
4. 引入 Rerank 交叉编码器，从 Top20 精排到 Top3 到 Top5。
5. 对用户问题做 Query 改写，特别是多轮对话场景。
6. 组织上下文时只保留高相关片段，并约束大模型“没依据就说不知道”。
7. 每轮优化后跑批量评测，保留所有实验记录，方便对比。
8. 批量任务一定要加日志、缓存和失败重试，接口部署要限制访问范围。

还有一条合规提醒需要单独说清楚：如果 RAG 知识库中包含企业内部文档、个人信息、版权材料或人脸声音等敏感数据，使用前必须确认授权和合规边界。本地部署不等于可以无限制使用数据，对外提供服务前要做数据脱敏和权限校验，避免敏感信息泄露。涉及第三方文档、代码或模型权重时，也要遵守对应开源协议和使用条款。

13. 总结与下一步

这篇文章的核心观点是：RAG 准确率从 60% 到 80%，靠的不是玄学换模型，而是把链路中的六个环节逐一做实：评测集、切分、混合检索、Query 改写、Rerank、上下文约束。任何一个环节出现短板，整体准确率就会被压住。

建议你按下面的顺序动手验证：先花半天建评测集，然后跑一遍现有系统的基线准确率。接下来只做混合检索优化，再次跑评测。再把 Rerank 接上，对比 Hit Rate 和端到端准确率的变化。你会看到准确率指标逐步从 60% 往上走。

最容易踩的坑有两个：一是不建评测集就反复调 Prompt，效果好坏全靠感觉；二是只盯生成端，不管检索端，结果正确的知识根本没被找到。先把这两件事做好，80% 的准确率目标基本稳了。

后续可以继续扩展的方向包括：Agentic RAG 的迭代检索与工具调用、领域知识库的 embedding 微调、RAG 与图谱结合、自动化评测平台的建设。这个方向还有很多工程细节可以挖，建议收藏备用，在实际项目中逐步验证。