企业官网建设流程全解析

这次我们来看一个已经从概念讨论阶段走到企业落地阶段的技术方向——RAG，也就是检索增强生成。如果你关心大模型回答经常编造内容、知识更新滞后、内部文档无法直接接入模型这些问题，RAG 是目前工程上最现实的解决方案之一。它不是要重新训练一个模型，而是把“外部知识检索”和“大模型生成”拼成一条完整链路，让模型在回答前先去查资料，再基于资料给出答案。

这篇文章会把 RAG 从零开始拆开：先讲清楚它的工作原理，再带你把环境、向量库、Embedding 模型、LLM 接口全部串起来，最后落到一套可运行的 RAG 项目上。整体内容兼顾入门者和做企业落地的同学，包含代码示例、功能验证、效果评估、常见问题和接口化部署。

文章里所有代码都按通用项目结构给出，命令和路径需要根据你本机的实际环境做替换。重点不是照着敲一遍就行，而是理解每一层在做什么，遇到问题知道去哪排查。

1. RAG 核心能力速览

在开始动环境之前，先给 RAG 建立一张完整的能力图景。RAG 不是一个单独的模型，而是一套系统组合，不同层级决定它能做到什么程度。

从表的顺序可以看出，RAG 是一个多模块组合工程。对入门者，最友好的路径是先用开源框架跑通一套最小系统，再逐步替换每一层组件。对企业落地，则需要额外关注权限控制、知识库版本管理、监控评估和 API 接口规范。

2. RAG 工作原理与完整流程拆解

RAG 的完整流程可以概括为两条链路：一条是知识库构建链路，另一条是问答检索链路。两条链路互相独立，但最终在检索环节汇合。

2.1 知识库构建链路

知识库构建链路是离线过程。它的目标是把你手头的原始资料转换成可检索的向量数据，通常分四步：

第一，文档加载。把 PDF、Word、Markdown 等不同格式的文件读入系统。这一步看起来简单，实际最容易被低估。扫描版 PDF 需要 OCR，文字版 PDF 还要处理页眉页脚、多栏排版、表格错位，纯度不够的文本会直接影响后续切分和向量化效果。

第二，文本切分。把长文档切成固定长度或按语义边界的块。切分粒度直接决定检索质量：块太大，语义混杂，检索结果不够精确；块太小，上下文断裂，模型回答缺少足够背景。通用做法是先按标题结构切分，再对超长段落做二次切分。

第三，向量化。通过 Embedding 模型将文本块转换成向量。Embedding 模型输出的向量维度从几百到几千不等，不同模型适合不同语言场景，中文场景需要优先考虑中文语料训练过的模型。

第四，写入向量数据库。向量数据库既存储原始文本，也存储向量，并建立索引。查询时通过相似度检索快速召回最相关的若干个文本块。

2.2 问答检索链路

问答检索链路是在线过程。当用户发起一个问题时，系统执行如下步骤：

1. 用户问题向量化。用与知识库构建时相同的 Embedding 模型，把用户问题转成向量。
2. 相似度检索。在向量数据库中查询与问题向量最相似的 Top K 个文本块，并返回原始文本。
3. 可选的重排序。对召回结果做一次粗排或精排，去除与问题无关的噪声块。重排序可以用 Cross Encoder 模型，也可以用简单的关键词重叠过滤。
4. 组装 Prompt。把用户问题与检索到的文本块拼成一个带上下文的 Prompt，明确告诉模型“请根据以下资料回答，如果资料中没有相关信息，请直接说明不知道”。
5. LLM 生成答案。大模型根据 Prompt 生成最终回复，并把引用来源一并输出。

链路越靠后，对系统整体效果的影响越直接。检索质量差，后面接什么模型都救不回来；Prompt 设计差，检索结果正确但答案还是答非所问。这也是为什么 RAG 项目调试时要一层一层排查，而不是一上来就换模型。

3. RAG 技术选型：框架、Embedding 模型、向量库与 LLM

零基础入门最容易卡住的问题是技术选型。这里给出一套“先用什么、后换什么”的思路，避免一开始就陷入过多选项。

3.1 RAG 框架选择

从零基础角度看，推荐顺序是：先用 Dify 或 FastGPT 跑通“上传文档—知识库问答—API 调用”的完整体验，再用 LlamaIndex 或 LangChain 手写一遍核心逻辑。前者让你建立信心，后者让你真正理解原理。

3.2 Embedding 模型选型

Embedding 模型选型要看三个指标：语言适配度、向量维度、模型体积。

中文场景优先选择中文语料训练过的模型。开源可选项包括 BGE 系列、M3E 系列，商用接口则有各家云厂商的 Embedding API。判断一个 Embedding 模型是否适合你的知识库，最直接的方法是用一批真实问题去检索测试，计算召回结果是否真正命中正确答案，而不是只看某份排行榜分数。

3.3 向量数据库选型

向量数据库选型取决于数据量和部署环境。

• 学习与原型验证：Chroma、FAISS 足够，安装简单，单机可跑。
• 生产环境小规模：Qdrant 或 PGVector，具备持久化能力，部署可控。
• 大规模企业级：Milvus 或 Elasticsearch，适合分布式场景，支持复杂过滤和权限控制。

3.4 LLM 选型

RAG 里的 LLM 不限制必须使用某一家模型。只要模型支持通过 API 或本地服务调用，且能正确处理较长的上下文 Prompt，就能接入 RAG 系统。

本地部署场景需要准备足够的 GPU 资源；没有 GPU 时可以考虑使用云厂商的模型接口。无论选择哪种方式，都要把“模型输出是否忠实于检索资料”作为重要评估指标，而不是只看回答是否流畅。

4. 环境准备与前置条件

RAG 项目对环境的要求相对宽松，但需要按功能模块拆开看。

4.1 操作系统与基础依赖

推荐使用 Linux 或 macOS 进行开发部署，Windows 也支持，但遇到路径与依赖问题时需要额外处理。需要预装以下基础环境：

• Python 3.9 及以上版本
• pip 或 conda 包管理器
• Git
• 网络访问能力，用于下载 Python 包和模型文件

查看本机基础环境：

python --version pip --version git --version

4.2 CPU 与 GPU

• 纯 CPU 环境可以运行 RAG 全流程，但大规模向量化和 LLM 推理会明显变慢。适合学习测试和文本量小的场景。
• GPU 环境推荐至少具备 6G 以上显存，可以较流畅地运行本地 Embedding 模型和中型 LLM。更大参数量的 LLM 需要更大显存或量化方案。

具体显存占用取决于模型规模和推理参数，这里不写死数字。实际测试时建议用nvidia-smi命令实时观察。

4.3 磁盘空间

原始文档、切分后的文本、向量索引、Embedding 模型、LLM 模型都需要占用磁盘。建议预留 20G 以上的可用空间。如果使用本地 LLM，模型文件往往占据大部分空间，需要按模型实际大小评估。

4.4 安装 Python 依赖示例

RAG 项目要装的包较多，建议创建虚拟环境，避免污染全局环境：

# 创建并激活虚拟环境 python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate # 安装基础依赖 pip install openai python-dotenv chromadb sentence-transformers pypdf langchain

如果安装速度慢，可以临时换成国内 pip 镜像源：

pip install -i https://pypi.tuna.tsinghua.edu.cn/simple openai python-dotenv chromadb sentence-transformers pypdf langchain

5. 手把手搭建一套完整 RAG 项目

这一节直接进入实战。下面的代码是通用实现思路，使用 LangChain 生态与 Chroma 向量数据库组合，适合学习原理和二次改造。项目结构如下：

rag-demo/ ├── data/ # 存放原始文档 ├── embed/ # 存放 Embedding 模型缓存 ├── index_db/ # 存放向量数据库文件 ├── rag.py # 主脚本：知识库构建 + 问答 ├── requirements.txt └── .env # 存放 API Key 等敏感配置

5.1 读取环境变量

在.env中配置模型 API 信息。如果你使用本地模型服务，URL 改为本地服务地址；如果使用云厂商模型，填入对应密钥。

# .env 示例，实际值需要按你的模型服务填写 LLM_API_KEY=your-api-key LLM_BASE_URL=https://api.example.com/v1 LLM_MODEL=gpt-4o-mini EMBED_MODEL=BAAI/bge-small-zh-v1.5

这里不指定具体模型厂商，只说明通用配置结构。

5.2 文档加载与切分

文档加载的核心目标是得到干净的纯文本。不同文件格式需要不同加载器，下面以 PDF 和纯文本为例：

# load_docs.py from pathlib import Path from langchain_community.document_loaders import PyPDFLoader, TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter def load_documents(data_dir: str): docs = [] data_path = Path(data_dir) for file_path in data_path.glob("*.pdf"): loader = PyPDFLoader(str(file_path)) docs.extend(loader.load()) for file_path in data_path.glob("*.txt"): loader = TextLoader(str(file_path), encoding="utf-8") docs.extend(loader.load()) return docs def split_documents(docs, chunk_size=500, chunk_overlap=50): splitter = RecursiveCharacterTextSplitter( chunk_size=chunk_size, chunk_overlap=chunk_overlap, separators=["\n\n", "\n", "。", "！", "？", " ", ""], ) return splitter.split_documents(docs) if __name__ == "__main__": raw_docs = load_documents("./data") chunks = split_documents(raw_docs) print(f"原始文档数量: {len(raw_docs)}") print(f"切分后文本块数量: {len(chunks)}")

切分参数chunk_size=500和chunk_overlap=50是一个通用起点，实际要根据文档类型调整。疑问句密集的 FAQ 类文档可以分小块，长段落说明文可以分大块。

5.3 向量化与写入向量数据库

用 Embedding 模型把文本块向量化并写入 Chroma：

# build_vector_store.py from langchain_huggingface import HuggingFaceEmbeddings from langchain_chroma import Chroma from load_docs import load_documents, split_documents # 使用本地 HuggingFace Embedding 模型 embedding_model = HuggingFaceEmbeddings( model_name="BAAI/bge-small-zh-v1.5", cache_folder="./embed", ) # 也可以使用 OpenAI 兼容的 Embedding 接口 # from langchain_openai import OpenAIEmbeddings # embedding_model = OpenAIEmbeddings(model="text-embedding-3-small") docs = load_documents("./data") chunks = split_documents(docs) vector_store = Chroma.from_documents( documents=chunks, embedding=embedding_model, persist_directory="./index_db", ) print(f"向量库构建完成，共 {vector_store._collection.count()} 条向量记录")

构建完成后，index_db目录下会生成向量索引文件。后续问答阶段直接复用这个目录，不需要重新切分文档。

5.4 检索问答主流程

这一步是把检索结果和 LLM 生成串联起来：

# rag.py import os from dotenv import load_dotenv from langchain_chroma import Chroma from langchain_huggingface import HuggingFaceEmbeddings from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser from langchain_core.runnables import RunnablePassthrough load_dotenv() embedding_model = HuggingFaceEmbeddings( model_name="BAAI/bge-small-zh-v1.5", cache_folder="./embed", ) vector_store = Chroma( embedding_function=embedding_model, persist_directory="./index_db", ) retriever = vector_store.as_retriever( search_type="similarity", search_kwargs={"k": 4}, ) llm = ChatOpenAI( api_key=os.getenv("LLM_API_KEY"), base_url=os.getenv("LLM_BASE_URL"), model=os.getenv("LLM_MODEL"), temperature=0.1, ) PROMPT_TEMPLATE = """ 你是一个企业内部知识助手。请严格根据以下资料回答问题。 如果资料中没有相关信息，请直接回答“根据现有资料无法回答”，不要编造内容。 资料内容： {context} 用户问题： {question} 回答时先给出结论，再简要说明依据。 """ prompt = ChatPromptTemplate.from_template(PROMPT_TEMPLATE) def format_docs(docs): return "\n\n".join(doc.page_content for doc in docs) rag_chain = ( { "context": retriever | format_docs, "question": RunnablePassthrough(), } | prompt | llm | StrOutputParser() ) if __name__ == "__main__": question = "请根据知识库介绍什么是 RAG？" answer = rag_chain.invoke(question) print("问题:", question) print("回答:", answer)

这个rag_chain的语义可以这样理解：先把用户问题交给检索器，检索器返回 Top 4 文本块，格式化后作为context；原始问题作为question；两者拼成 Prompt 后交给 LLM，最终输出答案文本。temperature=0.1是相对较低的采样温度，目的是减少发散性回答，让模型更贴近资料内容。

5.5 运行验证

在项目根目录执行：

python rag.py

预期输出是：

问题: 请根据知识库介绍什么是 RAG？ 回答: 根据资料，RAG 是检索增强生成，它通过外部检索为大模型提供相关知识...

判断成功的标准有三条：

1. 回答内容确实来自知识库，而不是模型凭记忆编造。
2. 当问题超出知识库范围时，模型会明确说“根据现有资料无法回答”。
3. 检索到的文本块能对应到原始文档的具体位置。

如果回答仍然像漫谈，优先检查 Prompt 中是否强调了“仅根据资料回答”，以及检索器返回的文本块是否真正相关。

6. 提升检索质量：从能用走向好用

最小系统跑通之后，下一步是优化检索质量。这一步经常决定 RAG 项目能否走向生产环境。

6.1 重排序

单纯依赖向量相似度召回，容易混入语义相近但实际不相关的文本块。重排序是用一个额外的相关性模型对召回结果重新打分，把更相关的块排到最前。常用的实现是使用 Cross Encoder 模型进行粗排。

# rerank_example.py from sentence_transformers import CrossEncoder # 加载重排序模型 rerank_model = CrossEncoder("BAAI/bge-reranker-base") # 假设 query 是用户问题，passages 是检索阶段召回的文本列表 query = "什么是 RAG？" passages = [ "RAG 是检索增强生成，结合检索模块与大模型生成。", "向量数据库用于存储文本向量。", "大模型容易出现幻觉问题。", ] # 逐个计算相关性分数 scores = rerank_model.predict([(query, passage) for passage in passages]) ranked = sorted(zip(passages, scores), key=lambda x: x[1], reverse=True) for passage, score in ranked: print(score, passage)

重排序并不适合所有场景。当知识库切片数量少、召回质量已经很高时，额外增加重排序模型会拖慢响应速度。典型做法是先用粗召回 Top 20，再用重排序精排取 Top 4。

6.2 混合检索

向量检索擅长语义匹配，但有时会忽略关键词完全一致的精确匹配，比如型号编码、订单号、法律条款编号。混合检索同时使用关键词匹配与向量检索，再对结果做融合排序。

Elasticsearch 天然支持 BM25 关键词检索与向量检索的混合查询。使用 PostgreSQL 的场景则可以用全文检索加上 pgvector 的向量检索组合实现。

6.3 查询改写

用户问题往往包含口语表达、指代不明的词或隐含意图。查询改写模块在进入检索之前，先让 LLM 把问题改写为更利于检索的形式。例如“它的价格是多少”改写为“产品价格是多少”。这个模块会增加一次 LLM 调用，适合复杂问题场景，简单知识库可以直接跳过。

6.4 元数据过滤

企业知识库通常包含部门、时间、文档类型等属性。在检索时，只对满足条件的数据子集进行向量搜索，可以大幅提升准确性。Chroma、Milvus、Qdrant 都支持在查询时附加过滤条件。

7. RAG 效果评估：知识库指标与调优方向

没有评估体系，RAG 项目就停留在“感觉回答还行”的层面。要把它做成可持续优化系统，必须定义可量化的指标。

7.1 核心指标

7.2 评估数据集建设

要给出一套可靠的评估结果，至少需要准备 50 到 100 条测试问题。问题类型包括：

• 直接抽取型：答案在文档某个固定位置。
• 多文档综合型：需要把多个文档的信息合并。
• 无答案型：知识库中完全没有相关信息，理想回答是拒绝回答。
• 时序变化型：不同版本的文档对同一问题有不同答案，需要明确回答依据的版本。

每条测试问题需要标注：正确答案、关联文本块、可接受回答的判定标准。评估集建设完成后，每次修改切分策略、Embedding 模型或 Prompt 模板，都要重新跑一遍测试集，对比指标变化。

7.3 调优方向

如果检索召回率低，优先调整切分策略和 Embedding 模型；如果准确率低，优先增加重排序和元数据过滤；如果忠实度低，优先调整 Prompt 模板和降低 LLM 采样温度；如果相关性低，优先优化问题改写和回复长度控制。

调优顺序建议是：切分策略 > Embedding 模型 > 检索方式 > 重排序 > Prompt 模板 > LLM 参数。过早调 LLM 参数，往往是在掩盖检索层的问题。

8. 企业级 RAG 落地：可视化框架与 API 接口

如果你已经理解了核心逻辑，下一步可以借助企业级框架提高交付效率。可视化 RAG 框架的核心价值在于，将文档解析、文本切分、向量检索、Prompt 编排、模型调用这些步骤以可视化方式配置，并提供现成的 API 接口。

8.1 Dify 与企业框架部署思路

使用 Dify 或 FastGPT 部署时，典型路径如下：

1. 通过 Docker Compose 启动框架服务。
2. 在管理后台创建知识库应用。
3. 上传文档，选择切分策略与 Embedding 模型。
4. 配置 LLM 模型提供商。
5. 在调试页面测试问答效果。
6. 发布为 API 应用，获取 API 密钥和调用地址。

这类框架适合快速验证和交付演示项目，但底层细节被封装，遇到复杂检索问题时排查难度会增加。建议在业务初期使用框架提高效率，在业务稳定后逐步沉淀内部知识库构建规范。

8.2 API 接口化改造

通过 FastAPI 将 RAG 问答能力封装为 HTTP 接口是常见的工程做法：

# api_server.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel import rag app = FastAPI() class QueryRequest(BaseModel): question: str top_k: int = 4 class QueryResponse(BaseModel): question: str answer: str sources: list[str] @app.post("/api/rag/query", response_model=QueryResponse) def query_rag(request: QueryRequest): if not request.question.strip(): raise HTTPException(status_code=400, detail="问题不能为空") answer = rag.rag_chain.invoke(request.question) # 实际项目中还需要返回检索到的来源文本块 sources = [] return QueryResponse( question=request.question, answer=answer, sources=sources, ) if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=8000)

启动 API 服务：

python api_server.py

验证接口：

curl -X POST "http://127.0.0.1:8000/api/rag/query" \ -H "Content-Type: application/json" \ -d '{"question": "请根据知识库介绍什么是 RAG？"}'

调用示例：

import requests url = "http://127.0.0.1:8000/api/rag/query" payload = {"question": "请根据知识库介绍什么是 RAG？", "top_k": 4} response = requests.post(url, json=payload, timeout=120) print(response.json())

接口访问范围要严格控制。生产环境不应将 RAG 服务直接暴露在公网，需要通过内部网络或网关代理访问，并做请求频率限制和身份认证。

8.3 批量任务设计

企业级 RAG 中，文档更新是高频场景。批量任务通常包含以下队列：

1. 文件上传与格式检测。
2. 文档解析与文本清洗。
3. 切分策略执行。
4. 向量化与写库。
5. 索引更新与旧数据清理。

批量任务建议使用消息队列管理，任务状态需要可追踪。每次全量重刷知识库之前，可以先跑小批数据集验证向量化效果，再逐步扩大到全量。

9. 资源占用与性能观察

RAG 系统的性能瓶颈通常在三个位置：文档解析、向量化、LLM 推理。

9.1 观察显存与内存

模型加载后，用以下命令实时监控 GPU 状态：

nvidia-smi -l 2

如果是 CPU 环境，可以用top或htop监控内存与 CPU 占用。需要注意，加载本地 Embedding 模型与 LLM 模型后，即使没有任何请求，显存也会被占用。多个服务共享 GPU 时，要预留足够空闲显存。

9.2 影响推理速度的关键参数

• 文本块数量：切分粒度越细，向量库条数越多，检索速度会下降。
• Embedding 模型大小：大模型语义能力更强，但推理更慢，批量向量化也更耗时。
• LLM 上下文长度：加入的检索文本块越多，Prompt 越长，生成速度越慢。
• 批量数：批量向量化能充分利用 GPU 并行能力，但过大的批处理会导致显存溢出。

9.3 降低资源占用的方法

• 使用 Embedding 模型时添加normalize_embeddings=True参数，减少向量计算开销。
• 本地 LLM 使用量化版本，例如 4bit、8bit 量化，可以明显降低显存占用。
• 检索结果控制在 3 到 5 个文本块，避免无意义的上下文膨胀。
• 批量任务安排在低峰时段执行，避免与在线问答服务争抢资源。

10. 常见问题与排查方法

下表整理了 RAG 项目从零搭建到企业落地最常见的故障，以及对应的排查思路：

11. 最佳实践与合规使用建议

RAG 项目的工程化程度决定了它能走多远。下面的实践建议来自大量真实落地项目的共性经验，值得在项目初期就纳入设计。

第一，知识库原始文档与向量索引要分开管理。原始文档保留在独立目录或对象存储中，向量索引可以随时重建。不要把索引库当作唯一数据源。

第二，每个文本块保留完整元数据。包括来源文件名、页码、更新时间、所属部门、权限级别。元数据是后续做权限过滤、数据追溯、效果分析的基础。

第三，建立最小可运行配置模板。固定一套参数组合，例如 chunk_size=500、chunk_overlap=50、top_k=4、temperature=0.1，作为每次调优的基准线。每次调参只改一个变量，方便对比效果。

第四，批量任务必须加日志和失败重试。建议记录每个文件的解析耗时、向量化耗时、错误信息。单个文件失败时不影响整个批次，任务结束后统一输出失败报告。

第五，接口服务必须限制访问范围。RAG API 可能涉及企业内部敏感资料，生产环境不要暴露公网访问。内部访问也需要鉴权，设置请求频率限制，防止内部接口被滥用。

第六，涉及人脸、声音、版权素材以及个人隐私信息时，必须确认数据来源合法并获得使用授权。RAG 知识库经常包含合同、简历、客户信息等敏感数据，部署时需要考虑数据脱敏和访问审计。

第七，发布输出前进行人工抽查。RAG 的忠实度不是百分之百保证的。即使检索和 Prompt 都做得很规范，模型仍可能在边界问题上产生不准确的表述。重要场景必须有人工复核。

第八，知识库有更新时，要触发对应文档的增量索引。建议设计一个简单的版本管理机制，让用户可以在回答中看到答案依据的知识版本时间，避免新旧资料混用导致回答前后矛盾。

12. 总结与下一步建议

RAG 是目前大模型应用落地最容易见效、也最容易验证效果的技术路线。它不需要训练模型，不要求团队具备模型微调能力，只要有一份知识库和一个可调用的 LLM 服务，就能在几天内搭建出可演示的问答系统。核心难点从“能不能跑通”转移到“检索质量是否能持续保持”，这意味着项目后期的重心在数据治理、评估体系和监控告警，而不是模型本身。

最先建议验证的功能是你的知识库切分与检索效果。在你自己的文档上测试，远比使用公开示例更有说服力。第一次跑通时，固定小批量文档，打印检索环节返回的原始文本块，肉眼判断是否相关，再做后续优化。

最容易踩的坑是跳过检索质量评估直接调 LLM。回答不满意时先问一个问题：检索到的文本块是否包含正确答案？如果不包含，问题在切分、向量化或检索策略，和 LLM 没有关系。

后续可以继续扩展的方向包括：多轮对话中的指代消解、多知识库路由与权限过滤、表格与图片的多模态检索、文档更新的增量索引机制、基于 LLM 自动评估 RAG 效果的回归测试集。等这些模块逐步补齐，你的 RAG 项目就会从“能回答问题的 demo”变成“能长期运行的企业应用”。

这篇文章建议收藏备用。动手搭一套最小 RAG 系统，再慢慢往里加组件，效果会比你直接套用大型框架要好得多。