企业官网建设流程全解析

简介：面向需要为企业搭建智能问答系统的开发者，这份资源包提供了一套基于大语言模型与RAG检索增强生成的完整知识库问答方案，适用于知识管理、智能客服、内部文档检索等场景。核心优势在于开箱即用：支持直接上传文档、自动爬取在线文档，并完成文本拆分、向量化与检索增强生成，能有效缓解大模型幻觉问题；同时保持模型中立，可对接本地私有模型及国内外公共大模型，兼顾数据安全与接入灵活。附带的937个文件涵盖Python后端、Vue前端、TypeScript与SQL数据库脚本等，压缩包约31.99MB，目录结构清晰，便于二次开发。内置工作流引擎和函数库支持灵活编排，亦可零编码嵌入第三方业务系统。已有1403人学习，适合希望快速获得可落地问答能力的中级及以上AI应用开发者。

1. 基于大语言模型和 RAG 的知识库问答系统：为什么大模型非要外挂一个知识库

同一个问题，70B 的大模型可能答错，7B 的小模型接了 RAG 反而答对——这不是模型玄学，而是答案来源变了。基于大语言模型和 RAG 的知识库问答系统，核心就一句话：让模型不再凭记忆作答，而是先去你的知识库里检索，再根据检索结果生成回答。它解决的是大模型的三大软肋：私有数据没见过、知识停留在训练时刻、答不出来就编。适合三类人：要给企业文档做内部问答的、要给产品做智能客服的、以及把 RAG 实战当入门路线在做的开发者。下面把这条链路从原理到代码一次拆开。

2. 拆开 RAG 流水线：加载、分块、向量化、检索、生成五个环节与选型逻辑

RAG 不是某个单一算法，而是一条有固定顺序的数据流水线。很多人第一次搭系统时直接把文档扔给大模型，发现答得稀烂，回头骂模型不行——其实是前面几个环节没做对。先把这条流水线拆明白，再动手写代码。

2.1 RAG 与微调的分工：先选路线再选模型

做知识库问答，第一个岔路口是选 RAG 还是选微调。这不是二选一的对立关系，而是两条分工明确的路线。

微调适合的场景是：你需要模型改变表达风格、固定输出格式、学会某种领域术语的“说话方式”。比如让模型从 JSON 里提取字段、按固定模板生成报告，这些都是微调的强项。但微调有一个硬伤——它把知识塞进权重里，知识更新一次就要重训一次，成本高、周期长，而且训完你没法解释它到底记住了什么。

RAG 适合的场景正好相反：知识频繁更新、答案需要引用来源、数据是私有的。常见做法是文档更新后重新做一遍向量化，分钟级生效，不需要重训模型。RAG 的本质是不让模型“背答案”，而是让模型“查资料”。你可以把微调理解为让模型变成一个熟练工，把 RAG 理解为给熟练工配一个随时更新的资料库。实际项目中两者经常一起用：RAG 提供事实，微调提供说话方式。

顺带说一句，多模态大模型也是同样的逻辑。图文混排的知识库一样可以走 RAG 路线，只是把图片先做向量化，检索时图文块一起进提示词，原理没有变。

2.2 标准 RAG 流水线的五个环节

一条标准的 RAG 流水线有五个环节，每个环节都有明确的输入输出和责任边界。

前三个环节属于“入库”，后两个环节属于“问答”。你真正要调的参数集中在前三环和检索那一环，生成环节反而最省心。很多 RAG 项目做出来效果差，八成问题不在模型，而在入库阶段分块分得烂、检索阶段阈值设得松。

这里多说一句生态现状。RAG 的工程化已经很成熟了，有 LangChain、LlamaIndex 这类通用编排框架，也有 langchain4j 这种面向 Java 生态的实现，还有把 RAG 直接包装成服务的 AgentScope 2.0 RAG as Service。自己从零造轮子的时代已经过去了，重点应该放在理解链路和调参上。

2.3 分块是第一道质量关口：chunk_size 与 overlap 的设计逻辑

分块是整条流水线里最容易被低估的环节。文档切成块之后，每一块就是将来检索的最小单位。块太大，向量里混了太多无关主题，检索时相似度被稀释；块太小，一句话被拦腰切断，答案缺胳膊少腿。

分块的核心参数是 chunk_size 和 chunk_overlap。chunk_size 决定每块多大，chunk_overlap 决定相邻块之间重叠多少字符。重叠的目的是补偿切分造成的语义断裂——一个完整句子可能被切到两块里，overlap 让这个句子在两个块里都能完整出现，检索时命中率更高。

中文场景里，chunk_size 我一般取 300 到 500，overlap 取 50 到 80。这个范围不是拍脑袋定的：块太小，低于 150，语义单元不完整；块太大，超过 800，检索精度明显下降，因为一个块里塞了太多不相关句子，向量被平均掉了。overlap 低于 30 基本起不到补偿作用，高于 20% 又会让向量库膨胀。

更关键的是分割符顺序。中英文混排文档里，

如果只用\n\n切，长段落会被硬切成一大块，语义照样乱。要用递归分割器，按“换行 → 句号 → 分号 → 逗号”的优先级逐级切，保证切出来的每一块都尽量是完整句子。这一点在下一章写代码时会具体展开。

2.4 embedding 模型怎么选：中文场景的维度、体积与效果

embedding 模型决定了文本在向量空间里的“语义距离”算得准不准。选型时看三个指标：维度、体积、中文效果。

中文场景我优先推荐 BAAI 的 bge 系列。bge-small-zh-v1.5 是 512 维，模型文件约 100MB 左右，普通 CPU 就能跑，适合快速验证；bge-large-zh-v1.5 是 1024 维，效果更好但显存和内存压力大，适合对精度有要求的正式项目。text2vec-large-chinese 也是老牌选择，但新项目里 bge 的综合表现通常更稳。

选型有个常见误区：维度越高越好。维度高确实能表达更细的语义，但检索速度和存储成本也跟着涨。512 维在大部分知识库场景里完全够用，别一上来就上 1024 维。如果你的知识库是百万级文档，再考虑降维或者换稠密检索之外的其他方案。

3. 本地部署最小可跑的 RAG 系统：Ollama 加 LangChain 的完整命令与参数

原理链路理清了，现在落地。这一章的目标是让你在自己机器上跑通一个最小可用的本地知识库问答系统，数据、模型、代码全部本地化，不依赖任何云端 API。

3.1 环境准备：本地部署大模型与装依赖

先解决推理模型。本地跑大模型最省事的方案是 Ollama，一条命令就能把模型拉下来，自带 API 服务，LangChain 可以直接对接。选模型时我一般用 Qwen2.5 7B 级别的模型，中文能力强，显存需求约 8GB，普通游戏本就能跑。

# 拉取推理模型，首次执行会下载几个 GB ollama pull qwen2.5:7b # Python 依赖：框架、向量库、embedding、分词、检索 pip install langchain langchain-community chromadb sentence-transformers rank-bm25 jieba

参数说明：qwen2.5:7b是量化后的 7B 模型，显存不够可以换qwen2.5:3b，效果差一些但 4GB 显存也能跑。整套依赖里最重的是sentence-transformers，它会顺带装 PyTorch，下载时间较长。如果机器实在装不动，embedding 可以改用 fastembed 这类轻量库，但后续代码里的调用方式会略有不同。

提示：先把模型和依赖装好再继续。RAG 调试过程中要反复跑脚本，环境不稳定会让你误判问题出在代码还是环境。

3.2 加载文档并分块：中文分隔符顺序是关键

准备一份测试文档，比如产品手册、课程讲义或者运维文档，存成 txt。加载后直接进入分块环节，这里用 LangChain 的递归分割器，重点看分隔符配置。

from langchain.text_splitter import RecursiveCharacterTextSplitter # 读取本地文档 with open("kb/产品手册.txt", encoding="utf-8") as f: raw_text = f.read() # 创建分割器：按层级优先级切分中文文本 splitter = RecursiveCharacterTextSplitter( chunk_size=300, # 每块目标长度 chunk_overlap=50, # 相邻块重叠长度 separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""], ) chunks = splitter.split_text(raw_text) print(f"切分得到 {len(chunks)} 个知识块")

逻辑说明：RecursiveCharacterTextSplitter会按separators列表的顺序逐级尝试切分。先按段落切，段落太长就按句号切，再不行按逗号切，最后按字符硬切。这个顺序保证了切出来的块尽量语义完整。chunk_size是目标长度不是硬上限，切到超过上限才触发再切。

参数说明：中文场景下分隔符顺序必须调整，尤其要把。！？；，这些中文标点加进去。LangChain 默认的分隔符是英文标点，直接用在中文文档上会把整段话在一个句号处硬断，分块质量会很差。

3.3 向量化并写入向量库：bge 模型与 cosine 空间

分块完成，下一步把每个 chunk 转成向量，写入 Chroma 持久化存储。

from chromadb import PersistentClient from sentence_transformers import SentenceTransformer # 加载中文 embedding 模型 encoder = SentenceTransformer("BAAI/bge-small-zh-v1.5") # 创建持久化向量库，指定 cosine 空间 client = PersistentClient(path="./kb_store") collection = client.get_or_create_collection( name="product_kb", metadata={"hnsw:space": "cosine"}, ) # 写入知识块：id、原文、向量一并入库 collection.add( ids=[f"chunk_{i}" for i in range(len(chunks))], documents=chunks, embeddings=encoder.encode(chunks, normalize_embeddings=True).tolist(), ) print(f"已入库 {collection.count()} 条知识块")

逻辑说明：get_or_create_collection做幂等操作，反复运行脚本不会重复建库。documents存原文用于展示和拼提示词，embeddings存向量用于相似度计算。normalize_embeddings=True会把向量归一化，归一化后用点积算相似度等价于余弦相似度，检索结果更稳定。

参数说明："hnsw:space": "cosine"指定向量检索用余弦距离。如果知识库非常大，可以换"hnsw:space": "ip"（内积）配合归一化向量，检索速度更快，代价是精度略降。刚开始做项目不用纠结这个，cosine 是最稳的选择。

3.4 检索并组装提示词：约束模型只认知识块

入库完成，现在写问答侧的逻辑：把用户问题向量化，从向量库召回相关块，拼进提示词，交给本地模型生成答案。

from langchain_community.llms import Ollama # 对接本地 Ollama 服务 llm = Ollama(model="qwen2.5:7b", temperature=0.1, num_predict=512) def ask(question: str, top_k: int = 3) -> str: # 1. 问题向量化并从向量库检索 qv = encoder.encode([question], normalize_embeddings=True).tolist() hits = collection.query( query_embeddings=qv, n_results=top_k, ) contexts = hits["documents"][0] # 2. 组装带约束的提示词 context_text = "\n\n".join(f"[知识块{i+1}] {c}" for i, c in enumerate(contexts)) prompt = ( "你是知识库问答助手。只依据给出的知识块回答问题。" "如果知识块中没有答案，只回答：知识库中未找到相关信息。\n\n" f"知识块：\n{context_text}\n\n" f"问题：{question}\n" "答案：" ) # 3. 交给本地大模型生成 return llm.invoke(prompt) print(ask("这个产品的质保期是多久？"))

逻辑说明：整套流程的核心在提示词约束。你只依据给出的知识块回答这句是防幻觉的第一道防线，它告诉模型“没查到就不要编”。[知识块{i+1}]的编号让模型在引用时可以指出来源块。temperature=0.1把生成随机性压到最低，问答场景要的是稳定，不是发散。

参数说明：top_k决定召回几个块，起步设 3 就够。num_predict=512限制回答长度，防止模型长篇大论。这两个参数后面会反复调，建议在代码里留成函数参数而不是写死。

4. 检索质量决定答案质量：混合检索与 Rerank 的 rag 实战配置

把最小系统跑通之后，你会很快遇到一个现象：答案质量的上限不是模型决定的，而是检索决定的。查不到、查不准、查乱了，再强的模型也救不回来。这一章处理检索侧的三个核心问题。

4.1 纯向量检索的翻车场景：术语、编号与否定句

纯向量检索在 RAG 实战里翻车主要有三类场景。

第一类是专有名词和编号。向量检索擅长语义匹配，但遇到“A3-2024-07”这种型号编号，语义上没有任何相近的词，召回全靠字面匹配，向量检索很容易漏。第二类是精确术语，比如“BGP”“熔断器”这种词，语义相似但字形无关的替换词会把检索带偏。第三类是否定句，比如“不支持 5G”，模型检索到的块可能全是“支持 5G”的表述，语义高度相似但含义相反。

这三类问题的共同根源是：向量检索只认语义，不认字面。解决思路是引入关键词检索，把字面匹配的能力补回来。

4.2 BM25 与向量检索的加权融合

BM25 是经典的关键词检索算法，对字面命中非常敏感。它不关心语义，只关心查询词在文档里出现多少次、多罕见。RAG 里的标准做法是把 BM25 和向量检索的得分做加权融合。

from rank_bm25 import BM25Okapi import jieba import numpy as np # 对每个知识块做中文分词并构建 BM25 索引 tokenized_chunks = [list(jieba.cut(c)) for c in chunks] bm25 = BM25Okapi(tokenized_chunks) def hybrid_retrieve(question: str, top_k: int = 5, alpha: float = 0.5): # 1. 关键词得分：分词后查 BM25 q_tokens = list(jieba.cut(question)) bm25_scores = bm25.get_scores(q_tokens) # 2. 向量得分：复用之前的 encoder qv = encoder.encode([question], normalize_embeddings=True) vec_scores = (chunk_vecs @ qv.T).ravel() # chunk_vecs 是入库时的向量 # 3. 归一化后加权融合 bm25_norm = (bm25_scores - bm25_scores.min()) / (bm25_scores.max() - bm25_scores.min() + 1e-8) vec_norm = (vec_scores - vec_scores.min()) / (vec_scores.max() - vec_scores.min() + 1e-8) final_scores = alpha * bm25_norm + (1 - alpha) * vec_norm # 4. 取融合后的 top_k 索引 top_idx = np.argsort(final_scores)[::-1][:top_k] return [chunks[i] for i in top_idx]

逻辑说明：两种得分量纲不同，BM25 得分可能从 0 到十几，余弦相似度是 0 到 1，直接相加会被量纲大的那个主导。所以先各自做 min-max 归一化，再按alpha权重融合。alpha=0.5表示字面和语义各算一半，具体比例要看你的文档类型。

参数说明：alpha是融合权重，取值范围 0 到 1。术语、编号多的文档（设备型号、合同编号），alpha调到 0.6 到 0.7；问答语义复杂、问法千奇百怪的文档，alpha降到 0.3 到 0.4。这个参数值得多试几组，我见过不少项目靠调alpha就把召回准确率提了十几个百分点。

4.3 用 Rerank 修正召回顺序：top_k 的后悔药

混合检索拿回来的 5 个块，顺序不一定正确。向量检索和 BM25 各自给出的是“自己视角下的相关性”，融合后仍然可能有次优块排在最前面。这时候就需要 Rerank 模型上场，它把问题和候选块成对输入一个交叉编码器，重新打分排序。

from sentence_transformers import CrossEncoder # 加载中文 rerank 模型 reranker = CrossEncoder("BAAI/bge-reranker-base") def rerank(question: str, candidates: list, keep: int = 3) -> list: # 把问题和每个候选块组成 pair，交给交叉编码器打分 pairs = [[question, c] for c in candidates] scores = reranker.predict(pairs) # 按得分降序排序，取前 keep 个 ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True) return [c for c, _ in ranked[:keep]] # 使用：先混合检索召回 5 个，再 rerank 精排取 3 个 candidates = hybrid_retrieve("这个产品支持 5G 吗？", top_k=5) final_contexts = rerank("这个产品支持 5G 吗？", candidates, keep=3)

逻辑说明：Rerank 是“后悔药”式的修正手段——召回阶段宁可多召回一些，用 top_k=5 甚至 10，让可能正确的块都进候选池；精排阶段再用交叉编码器逐个比较，把最相关的 3 个块留在最终上下文里。交叉编码器比双塔向量模型慢，但它能看到问题和块之间的精确交互，排序质量高一个档次。

参数说明：keep是最终进入提示词的知识块数量，一般和纯向量检索的top_k保持一致，取 3 到 5。注意 Rerank 不能帮你找回没被召回的内容，它只能排序已有的候选——所以上一节那个alpha参数才是召回阶段的真正的上限来源。

5. 知识库问答系统避坑指南：五个真实踩坑记录

RAG 系统的调参与传统后端调参完全是两个节奏。传统接口出问题，报错信息会告诉你哪里坏了；RAG 出问题，系统照样流畅运行，只是答案不对。下面五个坑是我在知识库问答系统上踩过的，每条按“现象 → 原因 → 解决”记录。

5.1 分块太小导致答案被截断

现象：用户问“质保期多久”，系统回答里有“质保期见下页表格”这句话，但具体数字没了。知识库里明明有答案，检索也命中了，就是答不完整。

原因：分块时chunk_size设成了 100，文档里一句话就被切成了两半。质保期结论在上半块，具体月数在下半块，overlap 又只有 10，下半块没被检索到，答案自然缺一半。

解决：把chunk_size提到 300 到 500，chunk_overlap提到 50 以上。同时检查切分后有没有直接检查过每个块的完整性——我现在的习惯是打印前 20 个块，人工读一遍，看有没有半句话、断列表、拆表格的情况。分块是黑匣子，但黑匣子也得打开看。

5.2 不设相似度阈值，知识库外的问题也在硬答

现象：用户问“你们公司食堂几点开门”，知识库里完全没有相关信息，系统依然自信地答“食堂营业时间为 11:00 到 13:00”，跟真的一样。

原因：向量检索只按n_results取回指定数量的块，不管这些块跟问题实际相不相似。知识库没有答案时，它会硬凑几个“最不相似但矮子里拔高个”的块送进提示词，模型再照着编。

解决：加距离阈值，超过阈值就明确回答“未找到”。用 Chroma 时query返回结果里带distances，余弦距离大于 0.4 的我一般直接判为无答案。这个阈值需要拿一批真实问题实测标定，不要照抄网上的数值——不同 embedding 模型、不同文档类型，距离分布差别很大。

hits = collection.query(query_embeddings=qv, n_results=3) if hits["distances"][0][0] > 0.4: # 最相似块都超阈值，判定无答案 return "知识库中未找到相关信息"

5.3 上下文塞得太多，模型被无关块带偏

现象：把top_k从 3 调到 8，想着多给模型点资料，结果答案反而变差了，还出现了知识库里根本没有的信息。

原因：top_k越大，靠后的块相关性越低。这些低相关块被拼进提示词后成为噪声，模型分不清哪些是依据、哪些是干扰，注意力被稀释，甚至把无关块里的内容混进答案。

解决：top_k控制在 3 到 5，除非你的知识库主题高度统一。加了 Rerank 之后，召回阶段的top_k可以放宽到 10，但最终进入提示词的块必须经过精排截断。另外提示词里明确写一句“忽略与问题无关的知识块”，能显著减少模型被带偏的概率。

5.4 知识库更新后旧内容仍被召回

现象：文档已经改了一版，新版本里删掉了旧功能，但用户问起时系统还在引用旧版本的回答。查向量库，旧内容确实不在了，但问题依旧。

原因：向量库持久化之后，更新逻辑写的是“先新增后删除”，中间有一段时间新旧版本同时存在；更常见的是只写了新增逻辑，忘了按文档来源删除旧块。结果旧块一直躺在库里，和新块一起被召回。

解决：入库时给每个知识块打上文档 ID 或版本号，更新时先按来源删除旧块再写入新块。我的习惯是给每份文档算一个内容哈希，文档变了哈希就变，重建整个 collection 而不是在原库上增补。

# 按来源删除旧块，再写入新块，避免新旧共存 collection.delete(where={"source": "产品手册_2024.pdf"}) collection.add( ids=[f"chunk_{i}" for i in range(len(chunks))], documents=chunks, embeddings=encoder.encode(chunks, normalize_embeddings=True).tolist(), metadatas=[{"source": "产品手册_2024.pdf"} for _ in chunks], )

5.5 检索命中了，答案却还在编造

现象：这个问题最让人头疼——检索返回的块里明明有答案，生成的结果却跟原文对不上，数字不对、结论相反。模型像是“看过资料但没好好用”。

原因：提示词的约束不够硬。如果只写“根据知识块回答”，模型仍然会优先用自己训练时学到的知识来作答，知识块只是参考。多个知识块内容互相矛盾时，模型还会自行“折中”出一个看似合理的答案。

解决：三管齐下。第一，提示词里明确写“只能引用知识块中的原文表述，不得自行补充”；第二，把temperature降到 0；第三，生成前先检查召回块内部是否互相矛盾，如果有冲突，只喂给模型最相关的那个块而不是全部。这一步每一层都在砍幻觉空间，做完之后你会看到编造率明显下降。

6. 从能跑到能用：用 RAGAS 量化评测并规划升级路线

系统跑通了，坑也填了，但“感觉回答变好了”不算数。没有量化指标，你就不知道下一次该优化分块、换 embedding 还是调阈值。RAGAS 是当前用得最顺手的评测库，四个指标能覆盖 RAG 最主要的两个环节。

from datasets import Dataset from ragas import evaluate from ragas.metrics import faithfulness, answer_relevancy, context_precision, context_recall # 准备评测数据：至少 20 条真实问题，含标准答案 ds = Dataset.from_dict({ "question": ["这个产品支持 5G 吗？", "质保期多久？"], "answer": ["支持，见产品手册第 3 节。", "36 个月。"], "contexts": [["产品手册第 3 节：支持 5G 网络"], ["产品手册第 5 节：质保期为 36 个月"]], "ground_truth": ["支持 5G 网络", "36 个月"], }) result = evaluate(ds, metrics=[faithfulness, answer_relevancy, context_precision, context_recall]) print(result)

逻辑说明：四个指标各有分工。faithfulness衡量答案是否忠实于上下文，也就是幻觉程度，我把它排在第一位；context_precision衡量召回的块里有多少真正相关，对应你搜到的 rag hit rate——它和 5.2 的距离阈值强相关；context_recall衡量相关块有没有被全部召回，对应分块质量和检索算法；answer_relevancy衡量答案是否对得上问题，回答跑题时它先报警。

参数说明：评测集至少 20 到 50 条，覆盖简单问答、否定句、知识库外问题三类。用 3 条问题测出的分数没有统计意义。评测集要固定，每次调参后跑同一套数据，对比分数才有意义。我现在做 RAG 优化的习惯是：先跑一轮基线，再每改一个参数跑一轮，指标掉了马上回滚。

这一步做完，你手上的 RAG 系统已经从“能演示”变成了“能量化”。再往上走，方向是 Agentic RAG——让模型自己判断要不要检索、多轮追问、调用工具，解决复杂查询；以及 GraphRAG——把实体关系建成图谱再检索，回答“全局性问题”比纯向量块更强，Ontology RAG 则是在图谱上加本体约束，进一步压住幻觉。这三个方向我都试过，但都建立在一个前提上：基础 RAG 的指标先跑到合格线。指标没过就去追新架构，等于没学会走就学跑。

做知识库问答这一年多，我最大的教训是：不要一上来就换大模型、换框架，先把检索侧的每个参数老老实实标定一遍。数据长什么样、答错怎么量化，这两件事定下来，剩下的全是工程问题。希望帮到你。

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