企业官网建设流程全解析

做大模型应用开发时，很快会遇到一个核心瓶颈：模型只会回答训练数据里出现过的内容，公司内部文档、最新政策、实时业务数据，它一概不知道。RAG（Retrieval-Augmented Generation，检索增强生成）是当前解决这个瓶颈最常用的技术路线：先让系统从知识库中检索与问题最相关的片段，再把片段交给大模型生成答案。这套逻辑听起来简单，真正落地时却涉及 Embedding 嵌入模型怎么选、向量检索为什么能工作、文档切块怎么切、检索结果如何重排等一系列问题。这篇文章从 RAG 的完整业务流程出发，重点讲解 Embedding 的运行机制、向量检索的工作原理，并给出一个可运行的最小项目和排查链路，适合准备入门大模型 RAG 开发，或者已经在做 RAG 但想系统理清原理的读者。

1. 先理解 RAG 的运行位置：为什么大模型需要外挂知识库

1.1 大模型的“知识截止”与幻觉问题

语言模型在训练阶段学习到的知识，有一个固定的截止时间。模型无法天然知道训练之后发生的事情，也无法读取你本地服务器上的私有文档。如果直接拿一个通用模型回答企业内部问题，它只能基于训练时的记忆生成内容，一旦遇到没见过的问题，会选择“编造一个看起来合理的答案”，这就是所谓的大模型幻觉。

幻觉不是模型“坏掉了”，而是生成机制决定的。模型在预测下一个 token 时，只会根据上下文寻找概率最高的表达，它并不区分这个表达来自真实资料还是自己的记忆。因此，在企业知识问答、客服、文档助手等场景中，直接让模型回答是不可控的。

RAG 的思路是改变信息流向：不让模型凭记忆回答，而是先从外部知识库检索出候选材料，再把材料作为上下文交给模型，让模型基于给定材料生成答案。这样既保留了模型的生成能力，又把答案限定在可追溯的知识范围内。

1.2 RAG 与微调不是二选一

很多刚接触大模型开发的人会把 RAG 和微调放在一起比较，但两者解决的问题是不同的。

实际项目里，RAG 和微调也经常组合使用。先用微调让模型适应业务术语和输出格式，再用 RAG 提供最新的业务数据。两者不是互斥方案。

1.3 RAG 的核心链路一句话总结

可以把 RAG 理解成两条流水线的组合：

一条是离线的索引构建流程：原始文档 -> 清洗 -> 切块 -> Embedding 向量化 -> 写入向量数据库。

另一条是在线的问答流程：用户提问 -> 问题向量化 -> 向量数据库检索 -> 候选片段合并重排 -> 拼接 Prompt -> 大模型生成答案。

后面所有章节都会围绕这两条流水线展开。理解这两条线，RAG 的整体结构就清楚了。

2. Embedding 运行机制：文本如何变成向量

2.1 什么是文本向量

文本向量是把一段文字转换成一串固定长度的浮点数数组。例如“RAG 是什么”经过 Embedding 模型处理后，可能得到一个 1024 维的向量，像这样：

[0.0123, -0.0456, 0.0789, ... , 0.0034]

这串数字不是随机的，它在高维空间里编码了文本的语义。两个语义相近的句子，它们对应向量的空间距离也会更近。例如“如何退款”和“怎么申请退款”的向量会靠在一起，而“如何退款”和“今天天气怎么样”的向量会离得比较远。

这就是 Embedding 模型的核心价值：把人类语言中的相似性，转换成数学空间中的距离。

2.2 Embedding 模型的基本工作流程

Embedding 模型本质上是一个深度神经网络，通常基于 Transformer 结构。输入是一段带 token 的文本，输出是一个向量表示。常见流程是：

1. 文本分 token，例如“RAG 是什么”会拆成若干 token。
2. token 经过多层 Transformer 编码，每一层都会融合上下文信息。
3. 取最后一层某个位置的输出，或者对所有 token 输出做池化，得到一个定长向量。
4. 对向量做归一化，得到可以直接计算相似度的结果。

以 bge-m3 这类常见中文模型为例，它在推理时会同时把词、短语、句子级别的信息编码进向量，因此对中文长文本的语义表达效果较好。使用前要查看模型的 max_seq_length，也就是最大输入长度，超过这个长度的文本需要截断或重新切块。

2.3 相似度计算：余弦相似度为什么常用

向量检索时最常用的相似度指标是余弦相似度。它计算两个向量夹角的余弦值，公式逻辑是：

import numpy as np def cosine_similarity(vec_a, vec_b): dot = np.dot(vec_a, vec_b) norm_a = np.linalg.norm(vec_a) norm_b = np.linalg.norm(vec_b) return dot / (norm_a * norm_b)

余弦相似度的值范围是 -1 到 1。值越接近 1，表示方向越一致，语义越相近。它只关心方向，不关心向量的长度，因此在文本语义相似度场景中比欧式距离更稳定。

很多向量数据库在计算时会先对向量做归一化，这样余弦相似度可以直接转化为内积计算，性能更高。

2.4 Embedding 模型选型对比

Embedding 模型的选择会直接影响检索效果。常用的几类模型如下：

选择模型时要注意三点：第一，Embedding 模型必须与检索链路保持一致，索引时用模型 A，查询时换成模型 B，会造成向量空间不一致，检索结果完全不可用；第二，要关注模型的最大输入长度，长文本切块后单块长度不能超过该限制；第三，中文场景优先选择中文语料训练充分的模型，直接拿英文模型处理中文，语义表达会打折扣。

2.5 常见坑：维度、语义漂移与文本长度

第一个坑是维度不匹配。向量数据库建集合时会固定维度，例如 1024 维。如果写入时换了一个模型，输出的向量变成 1536 维，写入就会报错。解决方案是建集合前固定模型版本，并在集合元数据里记录模型名称。

第二个坑是语义漂移。同一套知识库，今天用 bge-m3，下周换成另一个新模型，新模型没有重新生成全部向量，只对新文档做向量化。结果就是新旧文档处于不同向量空间，检索质量混乱。正确做法是换模型后全量重建索引。

第三个坑是文本超长。有些 Embedding 模型会直接截断超长输入，但截断位置如果落在语义中间，向量表达会偏离原意。所以文档切块时，单块长度要小于模型的最大输入长度，留出安全余量。

3. 向量检索工作原理：从暴力搜索到 ANN

3.1 为什么传统数据库的 LIKE 不够用

传统关系数据库的 LIKE '%退款%' 只能做字符匹配。用户问“钱没到账怎么办”，文档里写的是“退款将在 3 个工作日内原路返回”，两者没有共同的字符，LIKE 无法召回这条内容，但 Embedding 向量可以做到，因为两个句子的语义是相近的。

向量检索解决的是“按语义找内容”的问题。它可以处理同义词、口语表达、语序变化，这是 RAG 知识库的核心能力。

3.2 近似最近邻：HNSW 和 IVF 的原理

如果知识库只有几百条文档，直接计算每条向量与查询向量的距离，也就是暴力搜索，完全可行。但生产环境的知识库动辄几十万、上百万条数据，暴力搜索的耗时无法接受，所以需要近似最近邻算法，简称 ANN。

ANN 的核心思想是用空间索引结构，减少需要计算距离的向量数量，用少量精度损失换取大幅性能提升。

HNSW（Hierarchical Navigable Small World）是目前最常用的算法之一。它把向量构建成多层图结构：上层图连接稀疏，适合快速定位大范围区域；下层图连接密集，适合精确比较。查询时从顶层进入，逐层向下，类似在大地图上先定位城市，再找具体街道。

IVF（Inverted File Index）的思路是先把向量空间划分成多个聚类区域，查询时只搜索与查询向量最近的几个聚类区域，而不是全量搜索。它需要先训练聚类中心，适合数据量更大的场景。

实际选型时可以参考这个表格：

3.3 混合检索：向量召回 + BM25 多路召回

向量检索擅长语义匹配，但也有短板。遇到精确名词、编号、人名、专业术语时，向量模型可能把不同编号的语义混淆，而传统的关键词检索能精确命中。例如用户查“订单号 20260815001”，关键词检索能直接找到包含这个订单号的文档，向量检索反而可能召回语义相近但不正确的文档。

混合检索的思路是同时跑两条召回通道：

一条是向量召回，基于 Embedding 相似度找语义相近内容。

另一条是关键词召回，基于 BM25 算法计算文档与查询词的相关性，找字符级精确匹配的内容。

两条通道的召回结果合并后，再经过重排序模块，把最终结果拼接给大模型。

BM25 的核心公式可以简单理解为：一个词在一篇文档中出现的频率越高，且这个词在整个知识库中越稀有，那么这篇文档的相关性越高。它适合处理精确匹配场景。

3.4 重排序 rerank 的作用

召回阶段的目标是“尽量不全漏”，所以返回的候选数量通常比较大，例如召回 50 条。但大模型的上下文窗口有限，不能把 50 条全部塞进 Prompt，而且召回的列表未必按真实相关性排序。这时需要 rerank 模型。

Rerank 模型与 Embedding 模型不同。Embedding 是预先给每条文本算好向量，查询时只比较向量距离；Rerank 是在查询发生时，把“查询文本 + 候选文档”拼接起来输入模型，让模型直接判断候选文档与查询的相关性，输出相关度分数。

这种方式的精度更高，但性能开销也更大，因为每条候选都要单独过一遍模型。生产环境常见的做法是：召回 50 条 -> rerank 取前 5 条 -> 拼入 Prompt。

3.5 向量数据库选型对比

向量数据库是 RAG 项目中负责存储和检索向量的组件。主流选择如下：

学习阶段可以先从 FAISS 或 pgvector 开始，跑通业务逻辑后再切换到 Milvus 等生产级方案。切换时要注意向量索引类型、检索参数和元数据过滤方式的差异。

4. 一条完整的 RAG 业务流程：从文档到答案

4.1 整体流程：两个阶段一条主线

RAG 业务可以拆成两个阶段。理解这两个阶段，就能理解 RAG 项目所有模块的职责。

离线索引构建阶段的任务是“准备好知识库”。输入是 PDF、Word、Markdown、HTML 等原始文档，输出是向量数据库中的一条条向量记录。

在线问答阶段的任务是“根据问题找答案”。输入是用户问题，输出是模型生成的回答，同时最好附带引用的来源文档。

两个阶段共享同一个 Embedding 模型，这一点非常关键。

4.2 阶段一：离线索引构建

离线索引构建的五个步骤分别是：

1. 文档加载：读取原始文件。PDF 要处理扫描件还是文本版，Word 要处理表格和页眉页脚，Markdown 相对干净。
2. 文档清洗：去掉无意义的换行、水印、页眉页脚、特殊符号。清洗不干净，切出来的块会大量包含噪声文本。
3. 文档切块：把长文档切成固定大小的片段，这是影响检索效果最直接的一步。
4. 向量化：每个片段调用 Embedding 模型生成向量。
5. 写入向量数据库：保存文本片段、向量、元数据，例如来源文件名、页码、章节标题。

4.3 阶段二：在线问答

在线问答的五个步骤分别是：

1. 查询向量化：用同一个 Embedding 模型把用户问题转成向量。
2. 向量检索：从向量数据库召回 TopN 候选文本。
3. 可选的混合检索：同时用 BM25 召回关键词命中结果。
4. 重排序：用 Rerank 模型重新排序，合并多路结果。
5. Prompt 拼接与生成：把用户问题和检索到的候选片段拼进系统提示词，交给大模型生成答案。

这个流程中，任何一个环节质量差，最终答案都会受影响。很多人调了很久 Prompt 但效果仍然不好，问题很可能出在检索环节，而不是生成环节。

4.4 切块策略：什么影响检索效果

切块是 RAG 项目里最值得花时间调优的环节。切块过小，单个片段语义不完整，检索不到核心信息；切块过大，片段里混入太多无关内容，向量表达被稀释，同时占用的 Prompt token 也更多。

常见的切块策略有三种：

推荐的做法是固定长度切块 + 重叠窗口。例如每块 500 个 token，重叠 50 个 token。重叠的作用是避免关键句子刚好落在切块边界上导致语义断裂。切块后每块文本长度要小于 Embedding 模型的最大输入长度。

4.5 一个最小 Python 示例：bge-m3 + FAISS + 大模型 API

下面给出一段最小可运行示例，用来说明离线索引和在线检索的完整闭环。

import os from FlagEmbedding import FlagModel from sentence_transformers import SentenceTransformer # 1. 加载模型，实际项目中要统一模型版本 model = SentenceTransformer("BAAI/bge-m3")

这段代码仅为示例加载说明，不同版本的依赖库接口差异较大。使用前先确认 FlagEmbedding、sentence-transformers 等包的版本，并查阅对应版本的 API 文档。

更稳妥的最小链路可以拆成两个脚本。索引脚本负责把文档切块后写入 FAISS：

import numpy as np import faiss # 假设 docs 是已经切块并清洗好的文本列表 docs = [ "RAG 是把检索结果作为上下文交给大模型生成答案的技术。", "Embedding 把文本转换为向量，用来计算语义相似度。", "向量数据库用来存储和检索大规模向量数据。", ] # 生成向量 vectors = model.encode(docs, normalize_embeddings=True) # 写入 FAISS 索引 dimension = vectors.shape[1] index = faiss.IndexFlatIP(dimension) index.add(vectors) # 保存索引和文档映射，供查询阶段使用 faiss.write_index(index, "knowledge.index") with open("docs.txt", "w", encoding="utf-8") as f: f.write("\n".join(docs))

查询脚本负责把问题向量化、检索并输出结果：

index = faiss.read_index("knowledge.index") with open("docs.txt", "r", encoding="utf-8") as f: docs = [line.strip() for line in f.readlines()] question = "RAG 是什么技术？" question_vector = model.encode([question], normalize_embeddings=True) # 检索 top3 scores, indices = index.search(question_vector, k=3) for score, idx in zip(scores[0], indices[0]): print(f"score: {score:.4f}, text: {docs[idx]}")

之后再把检索到的片段拼入 Prompt，调用大模型 API 生成答案：

from openai import OpenAI client = OpenAI( api_key=os.getenv("LLM_API_KEY"), base_url=os.getenv("LLM_BASE_URL"), ) context = "\n".join([docs[idx] for idx in indices[0]]) prompt = f"""请基于以下资料回答问题。 资料： {context} 问题：{question} 回答时只使用资料中的信息，不要编造。""" response = client.chat.completions.create( model="qwen-plus", messages=[{"role": "user", "content": prompt}], ) print(response.choices[0].message.content)

这个最小示例中，切块、索引、检索、生成四个环节都完整存在，只是全部简化了。实际项目里需要把 FAISS 换成向量数据库，把内存中的 docs 列表换成持久化存储，并加入元数据过滤。

4.6 Java 侧集成提醒

热搜词里出现“java rag 实战”，说明很多 Java 技术栈的团队也在接入 RAG。Java 生态中可以做类似的事情，但侧重点不同。

Java 侧通常负责的是 RAG 后端的工程化部分：接收用户请求、调用检索服务、管理 Prompt 模板、调用大模型 API、保存会话历史。而 Embedding 和向量检索，更多是交给 Python 侧的服务或独立部署的向量数据库完成。

如果坚持在 Java 里生成向量，可以使用 ONNX Runtime 加载量化后的 Embedding 模型，也可以调用远程 Embedding API。要特别注意，Java 侧通过 HTTP 调用 Python 侧服务时，建议在中间层做好超时控制、熔断和日志记录，避免大模型接口抖动影响主流程。

5. 从零跑通 RAG 项目：环境准备与验证

5.1 环境版本建议

学习阶段不需要一上来就搭建完整的 Milvus 集群，建议从轻量方案开始。

先跑通最小闭环，再逐步替换组件，是成本最低的学习路径。

5.2 一个 RAG 项目的目录结构

rag-project/ ├── data/ # 原始文档 ├── index/ # 本地向量索引 ├── src/ │ ├── loader.py # 文档加载与清洗 │ ├── chunker.py # 切块策略 │ ├── embedder.py # Embedding 封装 │ ├── retriever.py # 检索封装 │ ├── generator.py # 大模型生成封装 │ └── pipeline.py # 编排完整流程 ├── tests/ │ └── test_retriever.py # 检索测试 ├── requirements.txt └── README.md

这种目录结构把每个环节拆成独立模块。等需要替换组件时，例如从 FAISS 换成 Milvus，只需要修改 retriever.py，其他模块不需要动。

5.3 运行验证：查询答案并检查引用

项目跑通后，不能只看模型是否输出了文字。建议输出以下信息用来验证：

1. 用户问题。
2. 检索到的每个候选片段和相似度分数。
3. 被拼接进 Prompt 的最终片段。
4. 模型生成的答案。

同时检查三个问题：答案是否来自检索到的片段，片段是否真的与问题相关，相似度分数是否达到合理阈值。

如果检索到的片段与问题不相关，说明问题出在检索环节，调 Prompt 没有意义。这个判断顺序很重要。

5.4 评估：不能只看回答漂不漂亮

RAG 项目的效果评估需要拆成两个维度：检索质量评估和生成质量评估。

检索质量评估看两类指标：

生成质量评估可以建立测试集，每个问题带标准答案或评分标注，然后用大模型自动打分或人工抽样评估。至少要准备 50 到 100 条覆盖不同场景的测试问题，否则后续优化没有依据。

5.5 学习环境和生产环境的差异

学习环境一切从简，生产环境必须补齐以下能力：

• 配置外置化：模型名称、API Key、数据库地址不能写死在代码里，要用环境变量或配置中心管理。
• 日志：记录每轮问答的检索候选、分数、最终 Prompt、生成结果，方便定位问题。
• 监控：大模型接口延迟、Token 消耗、向量数据库查询耗时都要有指标。
• 权限：知识库内容可能涉及部门权限，检索侧要做元数据过滤。
• 回滚：模型升级、切块策略调整后，必须保留旧索引，支持快速回滚。

6. 常见问题排查链路

6.1 检索不到相关内容

现象：用户提出的问题明显在知识库里有答案，但检索结果完全不相关。

排查顺序如下：

1. 确认查询文本已经正确向量化，打印问题向量维度是否与索引维度一致。
2. 确认 Emebdding 模型是否与索引构建时一致。
3. 检查原始文档是否真的被写入索引，查询索引条数。
4. 检查切块逻辑，是否因为清洗或切块把关键内容截掉了。
5. 检查检索返回的 TopN 数量，是否因为 k 设置太小漏掉了正确内容。
6. 尝试降低相似度阈值，观察结果是否有改善。

如果问题可以直接用 BM25 命中，而向量检索不命中，说明当前 Embedding 模型对这类问题的语义表达能力有限，可以加入混合检索。

6.2 检索到了但答案不对

现象：检索结果看起来相关，但模型回答仍然错误或编造信息。

排查重点转向生成环节：

1. 查看最终输入大模型的 Prompt，确认检索片段是否真的被完整拼接。
2. 检查提示词是否明确要求“只使用资料中的信息回答”。
3. 检查检索片段数量是否过多，上下文被大量无关信息干扰。
4. 确认大模型版本和参数配置，过高的 temperature 会增强随机性，降低答案稳定性。

注意：RAG 调优的顺序永远是先查检索，再查生成。检索结果不对时，调整 Prompt 只是在放大错误信息。

6.3 向量维度或模型不一致

现象：写入向量数据库时报错，或者检索结果质量极差。

常见原因：

• 索引时用模型 A，查询时换成模型 B。
• 向量数据库集合创建时指定了固定维度，后来换模型后维度不同。
• 多个团队各自生成向量，没有统一模型版本。

解决方案：在向量数据库的集合元数据里记录模型名称和维度，检索代码启动时校验模型是否匹配。换模型一律全量重建索引。

6.4 响应太慢

现象：问答接口整体耗时过长，用户等待超过可接受范围。

耗时通常分布在四个环节：

6.5 一个可复用的 RAG 排错清单

• [ ] 确认 Embedding 模型版本一致。
• [ ] 确认向量维度一致。
• [ ] 确认文档已清洗、已切块、已写入索引。
• [ ] 打印问题向量和检索分数，确认检索结果合理。
• [ ] 检查最终 Prompt 内容，确认上下文包含检索片段。
• [ ] 确认大模型配置参数输出稳定。
• [ ] 检查日志，定位耗时集中在哪个环节。

7. 生产落地建议与扩展方向

7.1 上线前检查清单

RAG 系统上线前，这组清单可以帮助减少线上问题：

• 知识库是否需要权限隔离？检索时是否按用户身份过滤元数据？
• 文档更新频率是多少？是否需要定时重建索引或增量更新？
• 是否保留历史索引版本？切换失败能否快速回滚？
• 大模型 API 是否有超时、重试、熔断机制？
• 是否记录每轮问答的检索候选和最终 Prompt？
• 是否对敏感内容做数据脱敏和访问审计？
• 是否准备了一组评估问题集，用来监控线上效果漂移？

7.2 扩展方向：Agentic RAG、GraphRAG 与多路召回

RAG 不是一个终点，而是一个可以持续扩展的基础架构。

Agentic RAG 是目前很受关注的方向。普通 RAG 做一次检索、生成一次答案，Agentic RAG 则让大模型自己决定是否检索、检索几次、是否需要查询改写、是否结合工具。例如用户先问“帮我查一下上个月销售数据”，Agent 发现知识库检索不到最新数据，转而调用数据库查询工具。这种模式更适合复杂的多轮对话场景。

GraphRAG 是把知识图谱和 RAG 结合。先抽取文档中的实体和关系，构建成图结构，再基于图进行检索。它适合回答“实体之间有什么关系”这类多跳问题，例如“A 产品的供应商与 B 项目的负责人是否有合作”。普通向量检索很难处理这种关联关系，因为关联信息分散在不同文档片段里。

多路召回是生产环境更务实的优化方向。向量召回负责语义匹配，BM25 负责精确匹配，知识图谱检索负责实体关联，不同路的结果合并后经过 Rerank 统一排序。每一路召回对应一类信息需求，不追求单条路完美，而是组合取胜。

7.3 对入门者的学习路径建议

如果刚接触 RAG，建议按这个顺序学习：

1. 先用手写代码完成最小闭环：切块、Embedding、FAISS 检索、调用大模型。
2. 再引入切块优化，对比不同切块策略在测试集上的召回效果。
3. 然后接入向量数据库，把本地文件索引迁移到服务化存储。
4. 后续加入 BM25 混合检索和 Rerank，观察最终答案质量变化。
5. 最后再研究 LangChain、LlamaIndex 等框架，此时你已经能判断框架的封装是否合理，而不是被框架牵着走。

RAG 的学习难点从来不是某个单一组件，而是如何把组件组合成一条可靠的链路。只要把“文档怎么进、向量怎么存、问题怎么找、上下文怎么拼、答案怎么生成”这条主线理清楚，剩下的就是针对业务场景逐步优化。先把最小闭环跑起来，再按指标迭代，才是做 RAG 项目最有效的方式。