企业官网建设流程全解析

从接手第一个“把公司内部文档变成可对话问答系统”的需求开始，我就一直在折腾基于 LangChain 的 RAG 应用。这个项目标题“基于LangChain RAG问答应用实战”看起来简单，但真正落地时会发现，从文档解析、向量化、检索到生成，每个环节都有不少坑。这篇博文我会从方案选型、核心实现、完整实操到问题排查，把我实操过的完整经验拆开讲清楚，希望能给正在做类似项目或者准备入坑的朋友一些参考。

1. 项目概述：RAG 在什么场景下真正解决问题

1.1 先搞清楚 RAG 到底在解决什么问题

RAG 全称是 Retrieval-Augmented Generation，检索增强生成。通俗来说，大模型本身是一个“记忆模糊”的通用大脑，它训练时见过的数据虽然多，但当你要它回答公司内部的制度、某款设备的维护手册、某套系统的操作说明时，它往往只能胡编。原因很简单，这些私有知识根本不在它的训练数据里。

RAG 的核心思路，是在大模型回答问题之前，先从你准备好的知识库中检索出最相关的片段，把这些片段作为“参考资料”塞进提示词里，让大模型基于这些资料来回答。打个比方，大模型像一个知识渊博但记性不好的顾问，你开会前先递给他一摞相关文件，他翻着文件给你答复，准确率自然就上来了。

这个项目选 RAG 而不是微调（Fine-tuning），有一个很现实的原因——企业内部知识库的内容是高频更新的，制度版本会改、设备手册会变、FAQ 会不断扩充。如果用微调，每一次知识更新都要重新训练模型，成本高、周期长，而且微调适合的是改变模型的“行为习惯”或“专业风格”，而不是记住事实类内容。RAG 只需要更新向量数据库里的文档，几个小时就能生效，这是它被广泛应用的根本理由。

1.2 项目核心需求与应用场景拆解

我做的这个实战项目，场景设定是给某企业内部搭建一个“智能知识库问答助手”。知识库里有几类典型的文档：员工手册、产品说明书、技术规范、历史故障处理记录。用户通过自然语言提问，系统要能给出有依据、可追溯的答案，最好还能附带“这段回答来自哪篇文档”。

这样的需求，拆解下来有几个硬性指标：

• 问答结果必须基于给定的知识库，而不是让大模型自由发挥；
• 需要支持多文档、多种格式输入（PDF、Word、Markdown、TXT）；
• 中文场景下要能正确处理语义相似的检索，比如“报销流程”和“费用报销审批”应该是同一类问题；
• 每次回答最好能引用具体来源，方便人工复核；
• 响应时间要控制在几秒级别，不能让人等太久。

带着这些需求，我开始了技术选型。项目基础框架选了 LangChain，原因很直接：它把 RAG 流程中的文档加载、文本分割、向量化、存储、检索、问答链这几个环节都封装好了，开发速度快，调试也方便。尤其对于不想从零手写 Prompt 拼接逻辑和检索管线的团队来说，LangChain 的抽象层次刚好合适。

1.3 LangChain 与 RAG 的契合点分析

LangChain 对 RAG 的支持是体系化的，从DocumentLoader统一了多格式文档接口，到TextSplitter管理分块逻辑，再到VectorStore抽象屏蔽了后端差异，最后是用Chain的方式把“检索 + 生成”串成一条流水线。这意味着你在开发阶段可以快速换组件——比如今天先用本地向量库做验证，明天换成生产环境的云向量库，改动成本很小。

当然也有人会质疑，LangChain 太“重”、封装太多、Debug 困难。我的看法是，项目初期和中期，LangChain 的收益远大于成本。它提供了标准和默认实现，先让项目跑起来，卡在具体瓶颈时再绕过它直接操作底层接口，这才是务实路线。

2. 工具选型与架构设计思路

2.1 系统整体架构

这个项目的架构并不复杂，核心是一条单向的数据流：原始文档 → 加载与解析 → 文本分割 → Embedding 向量化 → 写入向量数据库。查询时则是反向流程：用户问题 → Embedding 向量化 → 向量检索 TopK → 组装 Prompt → 大模型生成 → 返回答案和引用来源。

具体的组件选型如下：

2.2 向量数据库怎么选

向量数据库是 RAG 里的“记忆仓库”，它的职责是把 Embedding 向量存下来，并在查询时快速找到最相似的向量。市面上选择很多，FAISS、Chroma、Milvus、Weaviate、pgvector 各有千秋。

我这次实战分两阶段处理：开发验证阶段用 FAISS，因为它是纯本地、免服务的，安装一个包就能用，非常适合跑通流程。到了模拟生产阶段，我切换到了 Milvus，因为它的规模扩展性好，支持过滤查询，并且有独立的查询服务，更适合真正要上线的项目。

提示：数据量小于几十万条向量时，FAISS 的检索速度其实完全够用，没必要一上来就上分布式向量库。先跑通场景，再考虑性能扩展。

2.3 Embedding 模型选择的细节

Embedding 是决定 RAG 效果的重要因素，甚至可以说比大模型本身还重要。检索这一步如果召回不到正确内容，后面的生成再好也是无米之炊。

我试过几种方案：通用英文 Embedding 模型中文效果很差；中英双语的模型比纯中文模型在常见语料上稍弱；最终选了一款中文效果稳定的 Embedding 模型。关键参数方面，向量维度一般是 768 或 1024，维度越高往往表达力越强，但存储和计算开销也越大。我的经验是，先别过度纠结模型选择，用一款通用表现好的模型跑通，记录基线效果，再做对比测试。

另外提醒一点，查询语句和知识库里的文档写法往往不一样。用户会问“工伤怎么申请”，文档里写的是“员工工伤申报流程”。所以有些项目会做查询改写（Query Rewriting），先让大模型把用户问题转成更适合检索的形式，再去做向量检索。这个技巧对检索效果提升明显，后面实战部分我会详细说。

2.4 大模型 API 对接方式

大模型选择上，我建议优先接入当前效果较好的通用大模型 API。实战中用 LangChain 的ChatOpenAI类来统一接入，传入api_base、api_key、model_name就行。这样做的好处是，后续如果要换模型或者切换服务商，只需改环境变量和实例化参数，其余链路不需要动。

还有一个容易被忽略的点：temperature参数。问答场景我一般设为 0.1 到 0.2，让输出尽量稳定保守。如果设太高，模型容易在资料不足时自由发挥，产生幻觉。而如果是创意类任务，比如让模型写摘要或润色文案，温度可以适当调高到 0.7 左右。不同场景要有意识地调整这个参数。

3. 核心环节的详细实现解析

3.1 文档加载与内容清洗

文档加载是 RAG 流程的第一步，也是最容易出现问题的地方。不同类型文档有不同的解析库：

• PDF 用 PyMuPDF 或 pdfplumber，尤其对于层叠文字、表格较多的排版，pdfplumber 提取更准；
• Word 用 python-docx，但如果文档里有复杂的页眉页脚，需要后处理；
• Markdown 和 TXT 直接读文本即可，但要去除代码块中无关的修饰符号；
• 扫描版 PDF 需要 OCR 配合，不建议先用 RAG 环节直接处理，成本高且效果差。

加载完成之后一定要做清洗，这是很多人忽略的步骤。我的清洗规则包括：去空行、去多余空格、修正中文标点错乱、去掉页眉页脚中的页码和公司名称水印、将全角半角统一。这些噪声如果留在文档里，分块后会被向量化，检索时容易干扰相关性判断。

注意：清洗的目标是保持语义完整，不是越干净越好。比如代码块里的缩进如果被误删，语义就变了。清洗前后最好对比抽样看一下效果。

3.2 文本分块策略的深度分析

分块，是把长文档切成长度适中的片段。这个环节很考验经验，分太大则检索粒度太粗，相关片段混入大量无关内容；分太小则语义不完整，比如一个段落被从中间切开，义群被破坏。我常用的策略是RecursiveCharacterTextSplitter，它按分隔符优先级递归切分，优先保护段落完整性。

我在这套知识库上尝试了多组参数：

最终我选了 chunk_size=256、chunk_overlap=32。其中 overlap（重叠）的作用是把上下文衔接处保留下来，避免一个完整意思恰好被切分在边界上导致信息丢失。对于中文知识文档，建议分隔符优先级设置成：\n\n→\n→。→！→？→；→，。这样中文句子结构会更完整。

还有一个小经验：如果文档中有明确的标题结构，最好用一个“自定义分割器”按标题层级先切大块，再在大块内细切。这样能保证小节标题和正文内容在一个片段里，检索时上下文更清晰。

3.3 向量化与索引构建

分块完成后，每一块文本要转成向量。这个步骤 LangChain 封装得很简单，核心代码就几行：

from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import FAISS embeddings = HuggingFaceEmbeddings( model_name="your-chinese-embedding-model", encode_kwargs={"normalize_embeddings": True} ) vectorstore = FAISS.from_documents(docs, embeddings) vectorstore.save_local("faiss_index")

这里我强调一个细节：normalize_embeddings=True很重要。向量归一化之后，内积计算等价于余弦相似度，某些向量库采用的内积距离会更稳定。如果不做归一化，向量的模长不一致，检索结果可能会偏向长文档，导致短而精的内容反而排不上号。

索引构建完成后，建议随机挑几个问题做一轮召回验证，看看检索结果是否合理。这一步不能省，因为它是在检验前两个环节的分块与向量化质量。如果召回不对，后面生成再漂亮也白搭。

3.4 检索逻辑与 TopK 设置的艺术

检索是 RAG 的中枢环节，决定了给大模型“喂”什么资料。LangChain 的默认检索器是similarity_search，只按语义相似度取 TopK 个片段。但实际生产场景，我建议至少要增加两个能力：

第一，相似度分数阈值过滤。默认检索不管相关性多低都会返回结果，这会导致模型拿毫不相干的片段硬答。我给检索器加了score_threshold，低于某个分数的片段直接丢弃。具体阈值要根据验证集调，比如 0.3 起步，检索不到再逐步下调。

第二，一个查询至少还应该支持按文档来源过滤。比如用户问的是“设备维护”，应该优先限定在产品手册类别内。实现方式是用向量库的元数据过滤条件，比如filter={"source_type": "device_manual"}。

TopK 的设置也需要斟酌，不是越大越好。K 值太大，会把大量弱相关片段塞进提示词，既占用上下文窗口，又分散模型注意力；K 值太小，可能遗漏关键内容。经验值是 K=4 起步，最多不超过 10。配合上述阈值使用，效果更好。

3.5 问答链与提示词设计

LangChain 提供的RetrievalQA链，快速搭起来很容易，但这套默认实现只是“能跑”。我在实战中自己组装了提示词模板，核心思路是给大模型立规矩：

from langchain.chains import RetrievalQA from langchain.prompts import PromptTemplate template = """ 你是一个企业知识库问答助手。请严格基于以下资料片段回答问题。 资料内容： {context} 用户问题： {question} 回答规则： 1. 如果资料片段中包含答案，请基于资料内容回答，不要添加资料中没有的信息。 2. 如果资料片段中不包含答案，请直接回答“资料库中没有相关内容”。 3. 回答时引用资料中的关键表述，标注引用来源编号，格式如[1]、[2]。 4. 保持回答简洁，控制在200字以内。 回答： """ prompt = PromptTemplate( template=template, input_variables=["context", "question"] ) qa_chain = RetrievalQA.from_chain_type( llm=llm, retriever=vectorstore.as_retriever(search_kwargs={"k": 4}), chain_type="stuff", return_source_documents=True, chain_type_kwargs={"prompt": prompt} )

提示词里的“如果资料中没有答案，就承认不知道”这句，是减少幻觉的关键。大模型倾向讨好用户，没有规矩时它会强答，但加上这条明确指令后，模型会老实很多。

还有一个可取的做法是把历史对话也拼进去，形成多轮问答。但不建议无限累积历史——对话轮次多了之后，上下文会淹没检索结果。我一般只保留最近两轮对话。

3.6 引用溯源能力的实现

给回答附上出处，是这个项目能落地的关键。企业知识库问答，最怕的就是模型给出一个看似合理但其实无据可查的答案。实现思路很简单：在检索时记录每个片段来自哪个文档的哪个分块，组装回答时把来源编号传给模型，返回时把编号对应的文档路径整理成引用列表返回给前端。

result = qa_chain({"query": user_query}) answer = result["result"] source_docs = result["source_documents"] sources = [] for doc in source_docs: sources.append({ "content": doc.page_content[:50], "source": doc.metadata.get("source", ""), "page": doc.metadata.get("page", "") })

前端拿到sources后，可以在回答下方渲染“参考来源”，这样用户能点开文档核对，管理员也能审核系统的回答质量。这一步做与不做，对项目的可信度影响很大。

4. 实操过程与完整落地步骤

4.1 环境准备与依赖安装

开发环境是 Python 3.10 + 虚拟环境。安装依赖时建议固定版本，LangChain 更新频繁，不同版本接口差异较大。我用的是 LangChain 0.1.x 版本，接口相对稳定，网上资料也多。

pip install langchain==0.1.0 pip install langchain-community==0.0.10 pip install langchain-openai==0.0.5 pip install faiss-cpu==1.7.4 pip install pymupdf==1.23.8 pip install python-docx==1.1.0 pip install huggingface-hub

如果你的 Embedding 模型是从 HuggingFace 拉取的，需要先确认本地网络能否访问 HF Hub。拉取过程中如果断网，后面检索会直接崩溃，我的做法是先下载到本地模型目录，然后离线加载。

4.2 数据准备与处理流程

这套知识库我准备了 20 份文档，总共约 200 页，格式涵盖 PDF、Word、Markdown 和 TXT。为了方便后续调试，我统一把它们放到了data/目录下，并在文档加载后用 JSONL 格式输出处理结果，每次修改参数后对比分块结果。

这里我把加载函数做了一个通用封装，对每种扩展名走不同的解析逻辑：

from pathlib import Path import fitz from docx import Document from langchain.schema import Document def load_document(file_path): file_path = Path(file_path) ext = file_path.suffix.lower() if ext == ".pdf": doc = fitz.open(file_path) text = "\n".join([page.get_text() for page in doc]) metadata = {"source": str(file_path)} elif ext == ".docx": doc = Document(file_path) text = "\n".join([para.text for para in doc.paragraphs]) metadata = {"source": str(file_path)} elif ext in [".md", ".txt"]: text = file_path.read_text(encoding="utf-8") metadata = {"source": str(file_path)} else: raise ValueError(f"Unsupported file type: {ext}") return Document(page_content=text, metadata=metadata)

加载后统一做清洗，主要处理页眉页脚和多余空行。这一步我是配合正则完成的，比如去掉Page \d+ of \d+这类页码模式。

4.3 构建向量库的完整代码

有了加载和分块，构建向量库的代码其实很短，但我要提醒一个容易踩坑的地方——FAISS.from_documents是一次性批量向量化，如果文档量大，会一次性占用大量内存，还可能在 Embedding API 调用时触发限流。稳妥做法是分批处理，并加入重试机制：

def build_index(docs, embeddings, batch_size=32): vectorstore = None for i in range(0, len(docs), batch_size): batch = docs[i:i + batch_size] if vectorstore is None: vectorstore = FAISS.from_documents(batch, embeddings) else: vectorstore.add_documents(batch) print(f"Processed {i + len(batch)}/{len(docs)} docs") return vectorstore vectorstore = build_index(docs, embeddings) vectorstore.save_local("faiss_index")

注意，这里假设 Embedding 模型是本地加载的，不涉及 API 调用。如果使用 API Embedding 服务，批次建议调更小，比如 8 或 16，同时加上指数退避的重试逻辑。

4.4 问答接口的完整实现

问答接口我用 FastAPI 包了一层，方便后续接入前端或者即时通信工具。核心代码如下：

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class QueryRequest(BaseModel): question: str history: list = [] @app.post("/ask") def ask(request: QueryRequest): result = qa_chain({"query": request.question}) sources = [ { "content": doc.page_content[:100], "source": doc.metadata.get("source", ""), "page": doc.metadata.get("page", "") } for doc in result["source_documents"] ] return { "answer": result["result"], "sources": sources }

跑起来后，我用 curl 做了几轮冒烟测试：

curl -X POST http://localhost:8000/ask \ -H "Content-Type: application/json" \ -d '{"question": "员工如何申请年假？"}'

返回结果带了引用来源时，说明整条链路是通的。接下来就是效果调优的环节。

4.5 检索效果的人工评估与调优

这一步属于“看不见的功夫”。我建立了一个小规模评估集，包含 30 个典型问题，覆盖简单事实类、流程类、相似术语易混淆类。每调整一个参数，跑一遍评估集，统计“检索正确率”和“答案可接受率”。

调优顺序很讲究：先调检索，检索准了再调生成。如果直接调提示词，基础没打牢，治标不治本。一个印象深刻的例子是，员工手册里既有“年假制度”又有“请假审批流程”，一开始检索时，问“请年假需要提前几天”，召回结果经常混入“病假证明”的内容。后来我在分块时特意保留小标题作为 metadata，并加入“标题上下文”到块内容里，召回准确率提升非常明显。

5. 常见问题与排查技巧实录

5.1 检索不到相关内容的处理思路

这是 RAG 上线后最经常被吐槽的问题。用户明明知道知识库里有这个规定，但系统回答“资料库中没有相关内容”。排查步骤我建议按下面的顺序来：

• 检查原始文档里是否真的有这个信息，有时候是文档确实没涵盖；
• 检查分块后的文本，看看关键句是否被切碎了；
• 用同样的查询语句直接对向量库做相似度搜索，打印出 TopK 分数；
• 如果分数很低，考虑调整 Embedding 模型或增大 chunk_size。

如果你有正确的预期答案，还可以把预期答案的文本也做一遍向量化，看看和哪块文档相似度高，反推分块问题还是 Embedding 问题。这个方法在 Debug 时很快。

5.2 回答幻觉问题的治理

大模型基于资料回答时，仍然有 10% 到 20% 的概率在资料不完整时“脑补”。我的治理手段是组合拳：

• 提示词中强制声明“资料中没有时直接说不知道”；
• 设置temperature=0.1或更低，控制随机性；
• 使用score_threshold过滤低相关片段，宁可没答案，不要错答案；
• 在回答后附上引用来源，让用户能复核。

如果你部署的身份是客服场景，有一条更稳妥的兜底：当检索结果的最高相似度分数低于阈值时，直接返回一句“该问题暂时无法自动回答，我已记录并将转交人工处理”。把机器答不出来的问题交给人工，比强行作答更体面。

5.3 中文场景下的分块与检索问题

中文和英文在分词上有本质区别。英文按空格分词，天然有词语边界；中文词与词之间没有分隔符。我实测中发现，直接用英文场景的默认分隔符切中文，效果很差。于是我把分隔符数组定制成按中文标点切分，同时对每块做了“去首尾空白”，避免检索时匹配到空字符干扰向量。

另外，建议在分块时把标题一起带进块内。例如：

## 员工年假制度 年假天数根据员工累计工作年限确定...

这里把“员工年假制度”作为块开头，能让向量化结果带上主题信息，检索时与查询“年假怎么算”的语义距离更近。我当时用这个技巧解决了不少低频词的召回问题。

5.4 上下文超长与成本控制

当你把 TopK 设为 6 到 8，每个块约 256 个字符时，上下文拼接长度很快就超了。大模型 API 是按 token 计费的，上下文越长，成本越高。控制成本的方法有几个：

• 压缩检索结果，只保留每个块的前 200 字给大模型；
• 用重排模型（Reranker）把 TopK 从 20 粗选后精排到 4 个，再进上下文；
• 长文档检索时，先按摘要级别过滤文档，再对命中文档做深度检索。

我这次实战尚未引入重排，但对于正式生产级项目，强烈建议加一层 Reranker。它虽然增加了一点耗时，但对答案准确率的提升非常值得。

5.5 并发与性能优化

当问答接口要面向多个用户同时使用时，有几个性能瓶颈需要提前考虑。本地 Embedding 模型默认是单线程推理，多个请求进来时算力会成为瓶颈。我用了ThreadPoolExecutor做批量向量化，另外在 GPU 可用时优先把 Embedding 模型放到 GPU 做推理。

向量检索层面，FAISS 的IndexFlatIP是暴力检索，十万级向量也可以接受；但百万级就要考虑 IVF 或 HNSW 索引。LangChain 里 FAISS 构建索引是可以传index参数的，自定义索引类型后保存和检索逻辑不变，迁移代价很小。

大模型 API 调用方面，建议加一层缓存。同一问题的向量检索结果可以缓存，问答结果也可以按问题哈希缓存。对于企业内部知识库这种“增量更新、存量稳定”的场景，缓存命中率会很高，能省不少 API 调用成本。

一些我对 LangChain 与 RAG 的实战心得

做这个项目最大的体会是，RAG 链路长，效果好坏不是单一环节决定的，而是一个木桶效应。分块、向量化、检索、提示词，每一个环节都需要亲自实验和验证。不要迷信某个“最优参数”，不同知识库、不同文档风格，最优配置都不一样。

我在实际调优中发现，先建立一个小的评估集，所有的改动都通过评估集量化对比，比凭感觉调整可靠得多。哪怕只是 20 到 30 个问题，也能帮你快速发现改动到底是在提升还是降低整体效果。

另外有一点想写给刚入坑的朋友：LangChain 的抽象虽然方便，但正式项目里你迟早会遇到需要突破框架限制的场景。比如自定义检索逻辑、接入特殊格式解析、精细控制提示词组装，这些时候不用犹豫，直接绕过 LangChain 去调用底层的向量库和模型 API。框架是拿来用的，不是拿来供着的。把这些底层逻辑捋顺之后，你组装自己的 RAG 拼图只会更快。