企业官网建设流程全解析

这次我们直接把 RAG 的完整链路拆开看一遍。很多人接触 RAG 时，看到的是一堆名词：Embedding、向量检索、BM25、重排、TopK、知识库，实际上跑通一个最小可用系统并不难，难的是搞清楚每个环节在解决什么问题。这篇文章就从完整的 RAG 业务流程讲起，把 Embedding 嵌入模型的运行机制、向量检索的工作原理、本地部署和 API 接入一次性理清楚。无论你是刚入门大模型应用开发，还是准备把 RAG 接到自己的业务系统里，都可以按这篇文章的流程过一遍。

RAG 全称是 Retrieval-Augmented Generation，也就是“检索增强生成”。核心思路是：不直接让大模型凭记忆回答，而是先从外部知识库中检索出与当前问题相关的片段，再把片段和问题一起交给大模型生成答案。这样做的好处很直接——缓解大模型幻觉、支持私有知识问答、让模型能回答训练数据之外的内容，同时对模型更新不敏感：知识库更新后，不需要重新训练模型。

整条链路里最关键的三个技术点就是文本切块、Embedding 嵌入和向量检索。三者配合决定最终问答质量。尤其是 Embedding 模型的选择和向量检索的召回效果，是 RAG 项目能否真正落地的分水岭。

1. RAG 项目核心能力速览

很多同学看到 RAG 的第一反应是“这又是一个大而全的框架”。其实 RAG 不是单一框架，而是一套可拆成独立模块的架构。下面这张表把最常见的 RAG 项目能力整理出来，方便先建立一个整体判断。

这里不写死“16G 内存”“8G 显存”这类数字，因为不同 Embedding 模型、不同向量库、不同生成模型的占用差异非常大。判断门槛的关键是：Embedding 模型通常很轻量，CPU 也能跑；而生成大模型的资源要求更高，可以选本地模型，也可以走在线 API。实际部署前，先确认好自己的算力和部署场景。

2. RAG 完整业务流程拆解：从文档到答案

RAG 项目看起来组件多，但业务流程可以分成三个主要阶段：索引阶段、检索阶段、生成阶段。下面按顺序拆开讲。

2.1 索引阶段：把知识库变成可检索的向量库

这一阶段做的事情是“离线建库”，也就是把原始文档处理成向量检索系统能理解的格式。

第一步是文档加载。不同来源的数据需要不同的加载器：PDF、Markdown、Word、HTML、数据库记录、API 返回的 JSON 都可能成为知识来源。这一层要解决的是“把各类格式转成纯文本”，同时尽量保留标题、段落边界、表格结构等语义信息。

第二步是文本切块。直接把整篇文档丢给 Embedding 模型，很容易超出输入长度限制，而且一个段落包含多个主题时，向量会变得模糊。常见做法是按固定字符数切块，并设置重叠窗口，或者在 Markdown/HTML 的标题层级处切块，让每个块尽量表达一个完整主题。切块长度直接影响检索效果：切得太短，上下文信息缺失；切得太长，向量被无关内容稀释。后面专门有一节讲切块策略。

第三步是 Embedding 向量化。每个文本块通过嵌入模型转换成固定维度的向量。这个向量好比是文本在“语义空间”中的坐标，语义相近的文本，坐标距离也近。向量化之后，连同文本内容、文档元数据、唯一 ID 一起写入向量数据库。

第四步是构建索引。向量数据库会对向量建立近似最近邻索引，例如 HNSW、IVF 等，这样在千万级向量里搜索时也能快速返回 TopK 结果。普通业务场景用 Chroma、Milvus、Qdrant 等都能满足需求。

2.2 检索阶段：把问题变成 Query，再召回相关片段

用户提问时，系统先对问题做同样的 Embedding 处理，得到 Query 向量。然后向量数据库在索引中查找与该向量最相似的若干个文档块，返回 TopK 结果。

这里有个容易被忽略的问题：单纯向量检索擅长理解“语义相似”，但对“精确关键词匹配”并不敏感。比如一份合同里写“甲方应于 30 日内付款”，用户问“付款期限是多少天”，语义检索可能召回，但“30日”这种精确约束不一定稳定命中。于是很多 RAG 系统会加入混合检索：一路走向量语义检索，一路走 BM25 关键词检索，最后把两路结果合并，再用重排模型精排。

2.3 生成阶段：用召回片段增强 Prompt

召回到相关片段后，把它们按照一定格式拼进 Prompt，同时告诉大模型：请基于以下资料回答问题，不要使用资料外的内容。然后把完整的 Prompt 发给生成模型，得到最终答案。

这里有两个关键点：

• Prompt 里必须给出足够的上下文，但也不是越多越好，需要控制 token 长度。
• 要给生成模型明确的指令约束，否则模型可能凭记忆补充出与资料相矛盾的内容。

生成结果还可以附上来源文档 ID，方便用户追溯。这就是一个完整 RAG 业务流程：离线建库、在线检索、生成回答。

3. Embedding 嵌入模型运行机制与适用场景

Embedding 是整个 RAG 系统的地基。地基不稳，后面检索召回和答案生成都会受影响。

3.1 Embedding 是什么

Embedding 模型的核心能力是把一段文本映射成一个高维向量。这个向量不是随机生成的，而是通过大量文本训练出来的，它让语义相近的文本在向量空间中更接近。比如“怎么退款”和“退货流程是什么”，字面差异大，但语义相近，它们的向量距离就会比较小。

在实际工程中，Embedding 模型通常输出固定维度的向量。文本长度不同，模型会通过池化操作把整句编码成一个固定大小的表示。RAG 项目里，这条链路是：

文本 → Tokenizer → Transformer 编码 → 池化 → 固定维度向量

3.2 常见 Embedding 模型的选择思路

目前社区常用的开源模型包括 BGE、BGE-M3、M3E、text-embedding 系列等。选择时有几个维度需要关注：

• 中文效果：如果知识库以中文为主，优先选择中文语料上表现更好的模型。
• 最大输入长度：有些模型只支持 512 token，超过部分会被截断；需要处理长文档时，要考虑模型的上限或配合切块策略。
• 向量维度：维度越高不代表效果越好，但维度越高通常存储和检索成本越大。
• 是否支持稀疏向量：部分模型同时输出稠密向量和稀疏向量，可用来辅助混合检索。

BGE-M3 这类模型在 RAG 社区被提及较多，它能同时生成稠密向量、稀疏向量和多向量，在检索召回上比较灵活。具体选哪个，建议拿自己业务里的一批真实 Query 和文档做小规模评测，不要只看榜单分数。

3.3 Embedding 的适用场景

Embedding 不只是 RAG 的专属组件，它本身可以独立使用：

• 语义搜索：不依赖关键词精确匹配，能搜索出同义改写的内容。
• 文本聚类：把客户反馈、工单内容按语义分组，方便归纳。
• 数据去重：判断两段文本是否表达同一意思，用于清理重复文档。
• 案例分析：问答系统、推荐系统中的用户意图匹配。

但 Embedding 也有边界。它不擅长精确数字匹配，也不擅长长文本整体压缩后的细粒度检索。如果业务场景要求“必须包含某个ID”“数字范围过滤”，建议额外叠加关键词检索和元数据过滤。

4. 向量检索工作原理

向量检索负责从向量库中快速找到与 Query 最相关的 TopK 向量。理解这部分，才能在实际调优时知道问题出在“召回”还是“排序”。

4.1 向量相似度计算

向量检索的本质是计算相似度。常见度量方式有三种：

• 余弦相似度：计算两个向量夹角的余弦值，值越接近 1 表示越相似。对文本向量最常用。
• 欧氏距离：距离越小越相似。相比余弦，它对向量模长更敏感。
• 内积：适合某些已归一化的模型，计算效率高。

大多数 Embedding 模型都建议使用余弦相似度，但具体还是以模型文档为准。如果使用向量数据库，通常在集合配置里指定 metric 类型。

4.2 从暴力搜索到 ANN 近似检索

最直观的检索方式是暴力计算 Query 与所有向量的相似度，然后排序。这在几百万条数据以内也能接受，但数据量变大后，延迟会明显上升。

向量数据库普遍采用 ANN（Approximate Nearest Neighbor）算法来加速。常见算法有：

• HNSW：基于图的近似检索，召回率高，检索速度快，但内存占用相对高。
• IVF：倒排索引思想，先聚类再限定候选范围，内存占用更可控。

还有基于乘积量化的压缩方案，适合超大规模场景。对 RAG 项目来说，如果数据在百万级以内，HNSW 通常是默认选择。

4.3 混合检索与重排

纯向量检索的召回并不是万能的。为了提升召回质量，RAG 项目中经常使用混合检索：

• 一路使用向量语义检索，捕捉同义改写、语义相关的片段。
• 另一路使用 BM25 关键词检索，捕捉精确关键词、专有名词、编号等。
• 两路结果合并去重后，再用重排模型精排。

重排模型（Reranker）通常是 Cross-Encoder 结构，能把查询和候选片段拼接后一起编码，得到一个相关性分数。它比 Embedding 双塔模型的精度高，但计算成本也高，所以只对召回后的少量候选做重排。

一个典型的多路召回流程是：

Query ├─ Embedding 向量检索 → Top 50 ├─ BM25 关键词检索 → Top 50 └─ 合并去重 → 取前 50 ↓ Reranker 重排 → 取前 5 ↓ Prompt 组装 → LLM 生成

加入多路召回后，即使某一路没召回，其他路也能补齐，整体鲁棒性更好。

5. 环境准备与本地部署前置条件

RAG 项目的环境准备不像单一模型推理那么简单，需要同时准备 Python 环境、模型文件、向量数据库和可选的 GPU 环境。这里给出一套通用清单。

5.1 运行环境检查清单

5.2 创建虚拟环境

以下命令是通用模板，实际项目需要按目录和版本调整：

# 创建虚拟环境 python -m venv rag-env # 激活虚拟环境，Linux/macOS source rag-env/bin/activate # Windows PowerShell # rag-env\Scripts\Activate.ps1

5.3 安装核心依赖

一个最精简 RAG 链路至少需要以下类型的依赖：

• Embedding 模型推理：sentence-transformers、transformers、torch
• 向量数据库客户端：chromadb 或 pymilvus、qdrant-client
• API 服务：fastapi、uvicorn
• 数据处理：pypdf、markdown、beautifulsoup4 等，按文档格式选择

示例安装命令：

pip install torch transformers sentence-transformers chromadb fastapi uvicorn pypdf

实际项目通常有 requirements.txt，请优先使用项目锁定的依赖版本，避免版本冲突。

5.4 模型文件准备

Embedding 模型可以通过 Hugging Face 等渠道下载到本地。如果是内网环境，可以提前下载好模型目录，再通过代码指定本地路径加载。

from sentence_transformers import SentenceTransformer # 方式一：在线加载 model = SentenceTransformer("BAAI/bge-m3") # 方式二：本地路径加载，适合离线环境 model = SentenceTransformer("/models/bge-m3")

6. 部署启动一个最小 RAG 服务

这里提供一个不依赖具体框架的最小实现思路，方便你理解组件怎么串起来。实际生产项目可以使用 LangChain、LlamaIndex 或自研管线，但原理一致。

6.1 初始化 Embedding 模型和向量库

from sentence_transformers import SentenceTransformer import chromadb # 加载 Embedding 模型 embedder = SentenceTransformer("BAAI/bge-m3") # 创建持久化向量数据库 client = chromadb.PersistentClient(path="./kb_store") collection = client.get_or_create_collection("knowledge")

6.2 文档切块与入库

先写一个简单的切块函数，再批量写入向量库。这里给出的是模板，切块大小和重叠要根据文档类型和模型输入上限调整。

def split_text(text, chunk_size=512, chunk_overlap=128): chunks = [] start = 0 while start < len(text): end = start + chunk_size chunks.append(text[start:end]) start = end - chunk_overlap return chunks def index_document(doc_id, text): chunks = split_text(text) for i, chunk in enumerate(chunks): vector = embedder.encode(chunk).tolist() collection.add( ids=[f"{doc_id}_{i}"], documents=[chunk], embeddings=[vector], metadatas=[{"doc_id": doc_id}] )

6.3 检索函数

def search(query, top_k=5): query_vector = embedder.encode(query).tolist() results = collection.query( query_embeddings=[query_vector], n_results=top_k, include=["documents", "metadatas", "distances"] ) return results["documents"][0], results["metadatas"][0]

6.4 启动 LLM 问答服务

LLM 部分可以接本地部署的模型，也可以接在线 API。为了让示例完整，先用一个抽象函数表示生成逻辑，实际替换成自己的模型调用即可。

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class ChatRequest(BaseModel): query: str class ChatResponse(BaseModel): answer: str sources: list def build_prompt(query, contexts): context_block = "\n\n".join(contexts) prompt = f"""请根据以下资料回答问题，不要使用资料之外的信息。 资料： {context_block} 问题：{query} 回答：""" return prompt def llm_generate(prompt): # 这里替换成实际模型调用 return "生成的答案" @app.post("/chat", response_model=ChatResponse) def chat(req: ChatRequest): contexts, metadatas = search(req.query) prompt = build_prompt(req.query, contexts) answer = llm_generate(prompt) return ChatResponse(answer=answer, sources=contexts)

启动服务：

uvicorn main:app --host 127.0.0.1 --port 8000

这样你就得到了一个最简 RAG 服务：先运行文档入库脚本，再启动 API 服务，就可以用 /chat 接口提问了。

7. 功能测试与效果验证

RAG 项目跑起来容易，跑得好难。这里给出几组可复现的测试步骤，每次改造切块、检索或 Prompt 之后，都应该按这套流程验证。

7.1 测试文档入库

在入库脚本里加入日志，输出每个文档切块数量、向量维度、入库耗时。判断入库成功的标准是：向量库中能按元数据查询到对应文档块。

def test_index(): doc_text = "RAG 是检索增强生成，它通过外部知识库增强大模型回答能力。" index_document("doc001", doc_text) print("入库完成")

7.2 测试检索召回质量

准备一个语义相近但文本表述不同的 Query，看 TopK 是否包含期望的文档块。例如知识库里有一段关于“退款规则”的内容，Query 写成“怎么申请退货”，看能否召回“退款规则”相关段落。

判断标准：

• 相关片段是否出现在 TopK 中。
• 不相关但字面相似的片段占比高不高。
• TopK 设置为 5 时，前 1 名的相关性是否足够。

如果召回效果差，优先检查切块大小、Embedding 模型选择、是否缺少混合检索。

7.3 测试完整问答效果

向 /chat 接口发送问题，观察：

• 答案是否基于资料内容，而不是模型“自由发挥”。
• 答案是否能追溯到具体文档块。
• 答案是否覆盖资料中的关键信息。
• 当问题超出知识库范围时，模型是否明确说明“无法从资料中得知”。

这组测试可以用脚本自动化，把问题、期望答案来源、实际回答保存到日志中，再人工复核。

7.4 批量评测脚本

为了对比不同切块策略或不同 Embedding 模型，准备一个小批量测试集。

test_cases = [ {"query": "如何申请退款？", "expected_doc": "refund_policy.md"}, {"query": "RAG 是什么？", "expected_doc": "rag_intro.md"}, {"query": "系统支持哪些文件格式？", "expected_doc": "file_format.md"}, ] def evaluate(questions): hit_count = 0 for case in questions: docs, metas = search(case["query"], top_k=5) if case["expected_doc"] in [m.get("doc_id") for m in metas]: hit_count += 1 print(f"Top5 命中率: {hit_count / len(questions):.2%}")

这个脚本可以放在知识库更新之后定期执行，用来检查检索质量是否回退。

8. 接口 API 调用示例与批量任务

生产环境里，RAG 服务通常以 API 形式暴露给上层应用。这里给出一个通用调用示例，实际字段名以你自己项目的接口文档为准。

8.1 调用问答接口

假设服务地址是http://127.0.0.1:8000，使用 curl 调用：

curl -X POST http://127.0.0.1:8000/chat \ -H "Content-Type: application/json" \ -d '{"query": "什么是向量检索？"}'

使用 Python requests 调用：

import requests url = "http://127.0.0.1:8000/chat" payload = {"query": "什么是向量检索？"} resp = requests.post(url, json=payload, timeout=60) if resp.status_code == 200: data = resp.json() print("答案:", data["answer"]) print("来源:", data["sources"]) else: print("请求失败:", resp.status_code, resp.text)

8.2 设计文档索引接口

在实际系统中，文档入库不能总靠脚本，更多是通过接口触发。你可以在 FastAPI 里加一个 /ingest 接口：

from pydantic import BaseModel class IngestRequest(BaseModel): doc_id: str text: str @app.post("/ingest") def ingest(req: IngestRequest): index_document(req.doc_id, req.text) return {"status": "ok", "doc_id": req.doc_id}

调用示例：

curl -X POST http://127.0.0.1:8000/ingest \ -H "Content-Type: application/json" \ -d '{"doc_id": "doc001", "text": "RAG 是检索增强生成。"}'

8.3 批量任务处理

批量任务的核心是控制速度和可观测性。不建议直接 for 循环一次性灌入所有请求，容易把服务打满。可以做一个简单的队列思路：

• 读取批量文档列表。
• 逐个入库并记录成功/失败状态。
• 失败任务记录原因，稍后重试。
• 所有任务完成后输出统计报告。

示例伪代码：

import time import logging def batch_index(documents): success = 0 failed = 0 for doc in documents: try: index_document(doc["doc_id"], doc["text"]) success += 1 except Exception as e: logging.error(f"入库失败: {doc['doc_id']} - {e}") failed += 1 time.sleep(0.1) return {"success": success, "failed": failed}

批量问答测试同理，可以对每个问题调用 /chat，把答案记录到 JSON 文件，再分析成功率与响应时间。

9. 资源占用与性能观察

RAG 服务和单模型推理不同，资源占用分为多个部分。部署后需要分别观察。

9.1 观察哪些指标

• Embedding 模型推理：CPU 和内存占用；如果使用 GPU，则看显存。
• 向量数据库：内存占用、磁盘占用、连接数。
• LLM 推理服务：显存或 CPU/内存占用，这通常是最大资源消耗方。
• API 服务：进程 CPU、内存、请求延迟。

常用命令：

# 查看 GPU 显存占用 nvidia-smi # 查看 CPU 内存 top # 查看内存概况 free -h # 查看端口占用 netstat -tlnp | grep 8000

9.2 影响资源占用的因素

• 文本切块大小：切块越大，单个向量化耗时会增加，但入库总条数变少。
• Embedding 模型 batch size：批量推理能提升吞吐，但会占用更多内存。
• TopK 数量：检索时返回的候选越多，后续重排和 Prompt 组装开销越大。
• LLM 上下文长度：Prompt 越长，生成延迟和算力消耗越高。
• 并发请求：并发越多，资源占用增长越快。

9.3 如何降低资源占用

• 如果知识库规模不大，选择轻量 Embedding 模型。
• 用向量数据库的批量写入接口代替逐条写入。
• LLM 推理使用量化版本模型，或使用在线 API 减少本地资源压力。
• 对 API 服务做限流，避免突发流量打满 CPU 或显存。
• 定时清理向量库中废弃索引和临时数据。

资源占用的判断必须基于实际环境，不要照搬别人的数字。建议先在小数据集上跑通，再逐步扩大，一边扩大一边观察各项指标变化。

10. 常见问题与排查方法

RAG 项目常见的坑不少，下面整理了一张排查表，遇到问题时按表定位。

11. 最佳实践与合规建议

11.1 切块策略优先做实验

切块没有绝对最优，只有适合你的数据。可以准备三到五套切块参数，用同一批测试问题跑检索，对比 TopK 命中率。常见思路包括：

• 固定大小切块：实现简单，适合段落结构不明显的文本。
• 重叠切块：减少关键信息被截断的概率，但要控制重叠比例，避免冗余。
• 结构切块：按 Markdown 标题、段落、表格分隔符切分，保留语义单元。
• 父子块：父块保留上下文，子块做检索，召回子块后展示父块。

11.2 混合检索优先于单一向量检索

如果你的知识库包含大量专有名词、编号、产品型号，建议尽早加入 BM25 关键词检索和重排模型。多路召回能明显降低“语义匹配但字面不匹配”的遗憾。

11.3 做好数据合规与授权

RAG 的核心是把外部文档纳入知识库。使用这些文档前，必须确认数据来源合法、有权使用。涉及企业内部资料、个人隐私、受版权保护的文本时，要设置访问权限和审计日志。涉及人脸、声音、商业版权素材的场景，必须获得明确授权。问答结果对外发布或商用前，需要人工或规则复核，避免脱敏不完整或内容错误。

11.4 API 服务安全

如果 RAG 服务暴露在网络上，至少要做三件事：

• 加接口鉴权，比如 API Key 或 Token。
• 限制请求频率，防止暴力调用。
• 内网部署时不要随便映射公网端口。

12. 总结与下一步

RAG 的完整业务流程并不复杂：文档切块 → Embedding → 向量检索 → Prompt 增强 → 大模型生成。真正影响效果的是细节：切块策略合不合理、Embedding 模型适不适合你的语言和领域、向量检索是否加入了多路召回、Prompt 是否有足够强的约束。

建议你先跑通一个最小链路：选一个 Embedding 模型，建一个小的向量库，导入几篇文档，再启动一个问答 API。这个流程验证通过后，再逐步深入调整检索质量、接入重排、支持多轮对话，甚至往 Agentic RAG 方向扩展。

最容易踩的坑是跳过了检索质量验证，直接调 Prompt。实际上大部分 RAG 效果差的问题都出在“该召回的内容没召回”。把注意力先放在切块和检索上，效果提升往往会更明显。建议收藏备用，RAG 这条链路越早亲手跑一遍，后面看架构、调优都会更顺。