企业官网建设流程全解析

简介：《字节跳动RAG实践手册》是一份系统梳理大模型检索增强生成（RAG）落地经验的技术资料，面向算法工程师、NLP研发人员及架构设计者，重点解决检索、召回、生成全链路中的工程化难题。手册以字节跳动业务线真实应用为背景，从整体架构切入，详解数据层、索引层、检索层与生成层的设计思路，并在数据处理与准备环节覆盖数据收集清洗、文本预处理、数据增强、标注分类及隐私保护；在索引构建环节介绍向量生成策略、向量数据库管理、性能优化与质量评估迭代；在检索策略部分展开查询理解、核心算法、结果过滤与效果调优；生成层则关注模型选型、提示工程、质量控制及成本优化。手册还涉及抖音电商智能客服、飞书知识问答等落地案例，方便对照业务场景。压缩包内为一份PDF文件，大小1.41MB，目录按技术模块划分，便于检索。已有522人学习下载，适合希望借鉴大厂RAG系统化实践、提升检索准确性与生成质量的技术团队参考。

1. RAG 不是给别人做的，是先解决自己的知识割裂

做 RAG 落地的人，多半会在某个深夜对着一条 rag hit rate 卡在 60% 的曲线发呆。字节跳动 RAG 实践手册里最扎眼的一条，不是又换了个多大参数的模型，而是把知识割裂这件事当成工程问题来解：业务文档散在 Wiki、工单、产品手册和数据库里，LLM 再强也答不出没喂进去的内容。这篇笔记按“先立原理、再给步骤、最后讲坑”的顺序，聊聊怎么把 rag知识库从一个 demo 变成能扛住线上检索压力的 rag项目。适合正在搭本地知识库、被召回质量折磨，或者想搞清楚 agentic rag 和普通 RAG 边界的人。

2. 摸清 RAG 的命中率瓶颈：从检索到生成的链路分析与关键参数

2.1 文档切分：chunk 大小和重叠是 hit rate 的第一道坎

RAG 检索的对象不是整篇文档，而是切好的片段。很多人第一次跑通链路后，发现回答内容像“从三本书里各撕了一页”，根因十有八九出在 chunk 切分上。字节跳动在实践手册里反复强调一个观点：切分粒度决定召回粒度，而召回粒度直接决定 rag hit rate 的上限。模型参数量再大，也无法把丢失在切分缝隙里的信息找回来。

切分参数我一般看三个：chunk_size、chunk_overlap、以及是否按语义边界切。chunk_size 设多大，取决于你的文档类型和 embedding 模型的 max sequence length。用常见的 bge-m3 或 text-embedding-3 时，我把默认 chunk_size 压在 500 到 800 token 之间，而不是套用某些框架自带的 1024。原因很简单：超过 800 token 的片段，向量里关键词密度会被稀释，检索时往往只命中中间那段，首尾信息全部被忽略。

chunk_overlap 的作用是补偿切分造成的语义断裂。我常用 chunk_size 的 10% 到 15% 作为重叠，比如 600 token 的 chunk 配 80 token 的 overlap。这样做能显著减少“一句话被切到两个 chunk 里，后半句没了主语”的情况。但 overlap 不是越大越好——重叠太多会导致不同 chunk 内容高度相似，检索结果可能连续返回同一段内容的近邻版本，白白消耗重排和 LLM 的上下文窗口。

比参数更关键的，是切分策略本身。标准固定长度切分（recursive character split）适合结构松散的文本，但对带标题层级、表格、代码块的内容，我更愿意先做结构解析，把 Markdown 标题、HTML 标签、PDF 里的 Heading 当成硬边界，再在边界内部做长度切分。这一步在字节跳动的实践里也被单独拎出来：文档解析不是丢给语言模型去理解，而是用规则把层级关系先剥出来，LLM 只负责做语义压缩。

2.2 向量化与召回：embedding 模型、top-k 和混合检索的取舍

Embedding 模型的选择，决定了 rag检索 的天花板。同一个 chunk 库，用开源的中文 embedding 模型和用商业接口的大模型，在业务术语多、口语化查询占比高的场景下，Top-10 命中率可以差出 15 个百分点。我现在的选型标准是：先拿自己的 100 条真实问答跑一遍 recall@k，再对比模型参数和部署成本，而不是只看榜单分数。

混合检索是解决向量召回漏检的常见做法。向量检索擅长语义匹配，但遇到精确编号、型号、人名、日期这类强标识信息时，BM25 关键词匹配往往更可靠。具体实现上，我会把两类检索结果做加权融合，权重先按 0.6（向量）对 0.4（BM25）起步，再用线上 bad case 反推调整。字节跳动在实践手册里把这种混合检索称为“不要迷信向量”，尤其在 ERP、产品手册这类充满物料编码的场景，纯向量检索几乎必然漏掉“ABC-1234”这种精确串。

top-k 的取值直接影响召回质量与后续重排。常见做法是检索阶段放大 top-k 到 20 到 50，把足够多的候选交给重排器，再由重排器裁到 5 到 8 条。如果一上来就把 top-k 设成 5，重排环节就失去了意义。这里要把“检索召回”和“重排精排”分成两个阶段看待：召回阶段宁可多召回无关内容，也不能漏掉正确答案；精排阶段再通过 deep-cross 或 cross-encoder 模型把真正相关的片段推到最前面。

需要注意，这里的 hit rate 指标并不是单一数值。我通常分开统计三个口径：召回率（正确答案是否出现在召回候选里）、命中率（正确答案是否出现在最终喂给 LLM 的上下文里）、以及端到端回答正确率。字节跳动实践手册里一个值得抄的做法，是把每一次线上检索的 query、候选片段和最终回答都记录下来，每周做一次 bad case 回看，而不是只盯着一个平均数。

2.3 重排与上下文压缩：让 LLM 只读该读的片段

召回阶段出来的 30 条候选，不可能全部塞进 LLM 上下文。常见做法是先在 Embedding 层用距离粗筛，然后用一个轻量级 rerank 模型做精排。我惯用 bge-reranker-base 或者其他 cross-encoder，它的特点是把 query 和每个候选片段拼成一个句子对，让模型逐对计算相关性分数，精度比向量余弦距离高，但速度也慢，所以只能用在“候选已经压缩到几十条”的阶段。

重排之后，还有一个经常被忽略的步骤：上下文压缩。数十条候选里，每条可能都是 800 token，即使重排后取前 5，也有 4000 token，这还没算 prompt 模板和对话历史。如果直接把这些原文丢给 LLM，不仅慢，而且容易让模型被冗余信息带偏。

我的做法是给每个候选做一个“提取式压缩”：保留首句、包含查询关键词的句子、以及结尾句，其余句子按 “是否有助于回答这个问题” 用规则或小模型筛一遍。这样喂给 LLM 的每条上下文能压到 200 token 以内。字节跳动实践手册里也提到类似思路，叫“检索结果的后处理”，核心目标是让最终进入生成器的文本和问题之间的互信息最大化。上下文压缩不是可选项，当你把 RAG 接到线上服务时，token 成本和时间延迟都会逼着你做这一步。

3. 把手册变成可复现的 RAG 落地流程：从知识库构建到检索生成

3.1 知识库清洗与分层：让 rag 项目从一个好数据开始

我见过的 rag项目，十个里有八个死在“数据没洗干净”上。字节跳动实践手册里有一句话我印象很深：知识库的脏数据会在召回阶段放大，而不是被向量化过程吸收。常见的脏数据包括：PDF 扫描件里的乱码、Markdown 里的重复标题、表格被拆成碎片、同一份文档的多个历史版本同时入库。这些问题不做前置处理，后面再调 embedding 和 rerank 都是白费。

清洗的第一步是去重。我会按文档标题加正文 hash 去重，避免同一内容被多个来源灌入知识库。第二步是类型感知解析：PDF 用解析器抽文本层，表格单独提取行和列结构，代码块保留缩进和注释。第三步是分层，把知识库按“通用文档、产品手册、内部流程、数据字典”划分成不同的 collection，因为不同分层的检索策略不一样——数据字典适合关键词检索，流程文档适合语义检索。

我在实际项目里会为每个 collection 单独建索引，而不是全塞进一个大向量库。这样做的另一个好处是便于做权限隔离：不同团队只能查自己的集合。字节跳动在实践手册里也建议按业务边界拆分知识库，避免一个庞大的混合索引把检索噪声放大。清洗后的文档，最好额外生成一份清洗日志，记录每篇文档被修改了什么、为什么改，否则后面出问题很难回溯。

3.2 用代码实现一条最小 RAG 链路

为了复现实践手册里的核心链路，我常用 Python 搭最小实现。下面这段代码不做框架绑定，只用最基础的 openai SDK 和 numpy 模拟“向量化—召回—重排—生成”四段流程，方便看清每一步的输入输出。

# 最小 RAG 链路的骨架代码，不依赖具体向量库 import openai import numpy as np client = openai.OpenAI(api_key="你的_key", base_url="你的_endpoint") def embed_texts(texts): # 将文本列表转成向量，这里假设模型输出 1024 维 resp = client.embeddings.create(model="your-embedding-model", input=texts) return [item.embedding for item in resp.data] def bm25_score(query, doc): # 简化版 BM25，只统计关键词交叠比例 q_words = set(query.lower().split()) d_words = set(doc.lower().split()) overlap = len(q_words & d_words) return overlap / (len(q_words) + len(d_words) + 1e-6) def hybrid_search(query, chunks, top_k=30, alpha=0.6): q_vec = np.array(embed_texts([query])[0]) doc_vecs = np.array(embed_texts(chunks)) # 余弦相似度 cos_sim = (doc_vecs @ q_vec) / (np.linalg.norm(doc_vecs, axis=1) * np.linalg.norm(q_vec) + 1e-9) bm25_scores = np.array([bm25_score(query, c) for c in chunks]) # 融合：alpha 控制向量权重 fused = alpha * cos_sim + (1 - alpha) * bm25_scores top_idx = np.argsort(fused)[::-1][:top_k] return [(chunks[i], fused[i]) for i in top_idx] def rerank(query, candidates): # 假设有一个 /rerank 接口，或者直接用 cross-encoder sorted_candidates = sorted( candidates, key=lambda x: client.chat.completions.create( model="rerank-model", messages=[{"role": "user", "content": f"{query}\n{x[0]}\n打分:"}], max_tokens=1 ).choices[0].message.content, reverse=True ) return sorted_candidates[:5] def generate_answer(query, contexts): prompt = "基于以下资料回答问题，如果资料不充分，直接说不知道。\n\n资料：\n" + \ "\n\n".join(c for c, _ in contexts) + f"\n\n问题：{query}" resp = client.chat.completions.create(model="your-llm", messages=[{"role": "user", "content": prompt}]) return resp.choices[0].message.content

这段代码的逻辑分四层：embed_texts 负责把 query 和 chunks 变成同一向量空间中的向量；hybrid_search 把向量相似度和 BM25 分数做加权融合，保留 top 30 候选；rerank 模拟了一个排序模型把候选精排到 5 条；generate_answer 把精排结果组装成 prompt 交给 LLM。参数说明：alpha 是向量检索权重，业务越偏精确匹配越低到 0.4 左右；top_k 在召回阶段通常不小于 20；rerank 环节在真实系统里应调用专门的 rerank 服务，用 LLM 逐对打分是偷懒的办法，会多出大量 token 开销。

3.3 评估集与 Hit Rate 的计算

没有评估集的 RAG 调优就是盲人摸象。我建议每个 rag项目至少维护一份包含 200 条问题的评估集，覆盖三种类型：能从知识库直接找到答案的“记忆型问题”、需要跨两三个文档拼答案的“综合型问题”、以及知识库里没有答案的“拒答型问题”。字节跳动实践手册里对评估的强调是：hit rate 不是算出来的一次性数字，而是每次改动切分、embedding、重排、prompt 后必须重新跑一遍的回归指标。

下面是我常用的一个 hit rate 计算脚本骨架。

# 评估 RAG 召回命中率 import json def recall_at_k(result_path, k=5, gold_key="answer_in_candidates"): """ 假设评估结果文件里每行包含: query: 原始问题 candidates: 检索并重排后的候选片段列表 gold_chunks: 包含标准答案的片段 id 列表 """ hit = 0 total = 0 for line in open(result_path, encoding="utf-8"): item = json.loads(line) gold_ids = set(item[gold_key]) top_k_ids = [c["id"] for c in item["candidates"][:k]] if any(g in top_k_ids for g in gold_ids): hit += 1 total += 1 return hit / total # 调用方式，通常配合 pytest 或定时任务 print("Hit@5:", recall_at_k("eval_results.jsonl", k=5))

这个脚本的逻辑是：把每次检索的候选片段 id 和标准答案片段 id 做交集判断，计算前 5 个候选里是否包含正确答案。之所以用前 5 而不是前 30，是因为最终喂给 LLM 的就是前 5，这更贴近真实效果。参数说明：gold_key 指向评估 JSON 里标记标准答案片段 id 的字段；k 可以分别跑 1、3、5 得到 hit@1、hit@3、hit@5 三档。我在项目里会把 hit@5 作为调优主指标，hit@1 作为重排质量的参考，两者同时看才能定位问题出在召回还是重排。

4. RAG 实践避坑：五个高频翻车点与排查命令

4.1 现象：检索结果里全是无关片段，回答东拉西扯

原因：chunk 切分粒度太大或太小，导致向量空间里不同文档的语义边界相互污染。另一种常见诱因是 embedding 模型本身与业务领域不匹配，比如用通用英文模型处理中文工单术语，向量空间中“退货”和“退款”的距离比“退货”和“换货”还远。解决：先用 3.3 的脚本打印 hit@5，如果 hit@5 远低于直觉，优先检查切片后的片段内容——把每个 chunk 前 20 个字打出来，看是否完整表达了一个独立意思。然后换一个领域预训练的 embedding 模型对比，同一批评估集，hit@5 通常会有明显变化。

4.2 现象：同一条问题，换个说法就召回失败

原因：知识库里同一件事的表述方式和用户 query 的表达差异太大，而向量模型的泛化能力不足以弥合。比如知识库写“申请退款需在订单完成后 48 小时内”，用户问“多久之后不能退钱”。解决：不要只靠加大 chunk_overlap，先做 query 改写，把口语化问题改写为知识库风格的问题再检索。具体工具可以用 LLM 做一次轻量改写，或者维护一个同义术语表，在检索前把“退钱”映射到“退款”、“坏了”映射到“故障”。字节跳动实践手册里也提到，query 理解是 RAG 链路上比 rerank 更容易忽视的杠杆。

4.3 现象：加了知识库后响应变慢，甚至超时

原因：检索阶段把大量文本做 embedding 计算，或者每次请求都对全部文档向量做余弦相似度，复杂度随知识库容量线性增长。常见做法是把向量索引换成支持 ANN（近似最近邻）的引擎，比如 faiss 或专门的向量数据库。解决：先给检索接口做监控，看耗时分布。如果 80% 时间花在向量检索上，把 FlAT 索引换成 HNSW，调高 ef_search 与 M 参数换取速度。再检查是否每次请求都调用了 embedding 接口，而不是把 query embedding 结果做缓存。若是重排环节太慢，把候选从 50 压到 20，重排模型换小一档。

4.4 现象：长文档被截断，末尾关键信息丢失

原因：PDF 或 Word 解析时遇到分页、页眉页脚、表格跨页，内容被错误截断，导致一个完整段落被硬生生切成两个片段，且第二个片段没有开头上下文。我的经历里，最常见是表格跨页后表头丢失，后续行只有数字没有列名。解决：先检查原始文档解析后的文本，定位截断点。如果是分页符导致，按页面解析后做跨页合并，把属于同一段落或同一逻辑块的行拼回去。如果是表格问题，用专门的表格解析结构，把跨页表格的表头复制到每一页片段里。这个坑属于数据侧，embedding 和 rerank 调多少次都救不回来。

4.5 现象：混淆 agentic rag 和普通 RAG，错误引入多轮改写

原因：看多了 agentic rag 的宣传，以为给 RAG 加上多轮规划、自我反思就能提升效果，于是在普通知识库问答场景里引入了复杂的 agent 路由。但 agentic rag 适合需要多步推理、需要调用外部工具的场景；简单的“查资料—回答问题”用普通 RAG 更稳定，也更易排查。解决：先明确场景是否需要多步检索。如果 query 是“A 产品的退货政策是什么”，不需要 agent 参与。把 agent 层去掉，直接用 3.2 的链路，观察是不是反而更准。字节跳动在实践手册里也把普通 RAG 和 agentic rag 的边界划定清楚：前者解决知识割裂，后者解决任务拆解，不要拿锤子找钉子。

5. 进阶：把 RAG 做成 on-premise 服务前，先学会验证和压测

5.1 用上下文相关性评分替代肉眼判断

肉眼判断回答质量只能发现明显错误，很难量化“看起来差不多但细节错了”的退化。我建议在评估集上额外跑一个上下文相关性评分：把标准答案、RAG 的输出、以及检索到的上下文片段一起交给一个评判模型，按 1 到 5 分打分。分数低于 3 的案例全部拉出来看，通常会发现是“检索到了正确文档，但 prompt 把重要性压低了”或者“上下文太长，模型没注意到关键句”。这个评分脚本可以用 3.3 里的评估集直接扩展。

5.2 一个回归自检的目录结构

项目里我会维护一个rag_eval/目录，包含三份文件：queries.jsonl（评估问题与标准答案片段 id）、cases/bad_cases.jsonl（每周回看存下的失败案例）、regression_report.csv（每次改动后的 hit@1/hit@5/上下文相关性评分）。每次改动 chunk 参数、embedding 模型、重排权重后，就执行一遍回归，把所有数值记录到 CSV 里。版本变化和指标变化直接对比，避免“改完不知道是变好还是变坏”的玄学状态。

5.3 最后的一点经验

我在做 rag检索 落地时，最大的教训是不要先调模型，先调数据。一个干净、分层、去重过的知识库，比换一个大模型带来的提升更稳定。字节跳动实践手册里没有魔法，只有把切分、召回、重排、评估每个环节都当成可度量的工程点。每次线上回答翻车，先把问题归因到检索还是生成，再动手改对应环节。希望这套拆解能帮你的 rag项目少走几步弯路。

本文还有配套的精品资源，点击获取