企业官网建设流程全解析

1. 为什么我要自己搭一套用户级RAG

先说结论：我搭这套东西的起因特别朴素——我受够了每次回答用户问题都要翻十几个文档、聊天记录和工单截图。你可能觉得这听起来像是个知识管理问题，但它本质上是个检索问题。RAG这个词现在被炒得很热，但落到实际场景里，它要解决的核心矛盾只有一个：用户的问题千变万化，而你的知识库是死的。怎么让死知识匹配活问题，这就是RAG存在的全部意义。

我最初接触RAG是在做一个内部客服辅助工具的时候。当时团队里有人提议直接上大模型微调，我算了一笔账：微调一次的成本够我买三年的向量数据库服务，而且每次业务知识更新都要重新训练，这个迭代速度根本跟不上业务变化。RAG的好处就在这里——知识库更新只需要重新索引，模型本身不用动。打个比方，微调像是把整本书背下来再回答问题，RAG像是带着一本书去考试，随时翻查。显然后者更适合知识频繁变动的场景。

但市面上的RAG方案有个通病：它们大多是面向企业级知识库设计的，动辄要接Elasticsearch、Milvus、Neo4j，配置复杂得让人头皮发麻。我就想，能不能做一套轻量的、个人开发者或者小团队能直接用的用户级RAG方案？不需要分布式，不需要GPU集群，一台普通开发机就能跑起来，检索效果还过得去。这就是我动手的起点。

这套方案适合谁？我认为三类人最需要：一是独立开发者，想给自己的应用加个智能问答但不想搞太重的基础设施；二是小团队的技术负责人，需要快速验证RAG在业务场景里的可行性；三是对RAG感兴趣但被各种框架劝退的初学者，想找一个能跑通全流程的最小实现。如果你属于这三类，接下来的内容应该能帮你省下不少试错时间。

注意：我这里说的“用户级RAG”，指的是面向终端用户直接提供问答服务的RAG系统，不是后台的知识管理工具。两者的设计目标完全不同，前者对响应速度和答案相关性要求更高。

2. 整体架构设计与技术选型思路

2.1 核心链路的四个环节

一套完整的RAG链路拆开来看就四步：文档加载与切分、向量化与索引、检索与重排、生成与引用。听起来简单，但每一步都有坑。我的设计原则是：每个环节都用最成熟的方案，不追求最新最炫，只追求稳定可控。

文档加载这块，我选的是LangChain的DocumentLoader体系。原因很简单，它支持的格式足够多，PDF、Markdown、HTML、CSV都有现成的加载器，省得自己写解析逻辑。切分策略我用的是递归字符切分，块大小设800字符，重叠200字符。这个参数不是拍脑袋定的——800字符大约对应中文400到500字，刚好是一个完整论述段的长度；200字符的重叠是为了防止关键信息被切断在边界上。我试过块大小设400，结果检索出来的片段太碎，模型拼不出完整答案；设1500又太粗，检索精度明显下降。

向量化模型我选了BGE-M3，这是目前中文场景下性价比最高的开源嵌入模型之一。它支持多语言、多粒度，而且对长文本的处理比早期的BGE-large要好不少。最关键的是，它可以在消费级显卡上跑，甚至CPU推理也能接受。如果你连显卡都没有，用OpenAI的text-embedding-3-small也行，成本很低，效果稳定。

向量数据库我用的是ChromaDB。选它的理由很直接：pip install就能用，支持持久化，API简单到令人发指。Milvus和Qdrant功能更强，但对于用户级RAG来说，那些分布式特性根本用不上，反而增加了运维负担。ChromaDB的本地模式完全够用，几万条文档的检索延迟在毫秒级。

生成环节我默认用DeepSeek或者通义千问的API。这里有个经验：生成模型的选择比嵌入模型更影响最终体验。嵌入模型决定“找得准不准”，生成模型决定“答得好不好”。如果预算有限，嵌入模型可以用本地的，生成模型建议用API，因为生成质量对用户体验的影响更直接。

2.2 为什么我不推荐一上来就上GraphRAG

现在GraphRAG很火，知识图谱加RAG听起来很高级。但我的建议是：除非你的知识本身有强关联结构，否则别碰GraphRAG。我试过用GraphRAG处理一批产品文档，结果发现构建图谱的成本远高于收益。实体抽取需要额外的模型调用，关系定义需要人工介入，最后检索效果相比朴素RAG只提升了不到5%。

GraphRAG真正适用的场景是：知识之间存在多跳推理需求。比如“A产品的某个零件由B供应商提供，B供应商的工厂在C地，C地最近有政策变化”——这种需要串联多个实体才能回答的问题，GraphRAG才有优势。如果你的知识库主要是独立的事实性文档，朴素RAG加一个好的重排模型就足够了。

2.3 重排环节的必要性

很多人做RAG会跳过重排这一步，直接拿向量检索的Top-K结果丢给模型。我实测下来，加一个重排模型能让答案准确率提升15%到25%。原理不复杂：向量检索是基于语义相似度的粗筛，它找的是“意思相近”的片段，但不一定是“能回答问题”的片段。重排模型（我用的是BGE-Reranker-v2-m3）会逐对计算问题和片段的匹配分数，精度高得多。

代价是延迟增加。重排20个片段大约需要200到400毫秒，这个开销在用户级场景下完全可以接受。我的策略是：向量检索召回Top-20，重排后取Top-5送给生成模型。这样既保证了召回率，又控制了生成模型的输入长度。

3. 核心细节解析与实操要点

3.1 文档切分的三个关键参数

切分策略直接决定了检索质量的上限。我总结下来有三个参数最关键：

块大小（chunk_size）：我最终定在800字符。这个值的确定方法很简单——拿一批典型问题去测，看多长的片段能完整包含答案。如果片段太短，答案被切碎，模型拼不出来；太长则噪声太多，检索精度下降。中文场景下，600到1000字符是比较稳妥的区间。

重叠长度（chunk_overlap）：设为块大小的20%到30%。重叠的作用是防止关键信息刚好落在切分边界上。比如一个定义句被切成两半，前半段在块A末尾，后半段在块B开头，没有重叠的话两个块都检索不到完整定义。200字符的重叠能覆盖绝大多数情况。

分隔符优先级：递归切分器会按分隔符列表依次尝试。我的设置是：先按双换行（段落）切，再按单换行切，再按句号、问号、感叹号切，最后按逗号切。这个顺序很重要——优先保持段落完整性，实在不行才在句子级别切分。千万别把逗号放在前面，否则会把一个完整句子切得七零八落。

实操心得：切分完之后一定要抽样检查。我通常会随机抽10个块，看看有没有明显的语义断裂。如果发现某个块以“但是”开头，或者以“因为”结尾，说明切分策略需要调整。

3.2 向量化的批量处理与缓存

向量化是RAG流程里最耗时的环节。几万条文档逐条调用嵌入模型，可能要跑几个小时。我的优化方案是批量处理加缓存：

批量大小设为64。太小则调用次数多，太大则单次显存占用高。64是个比较平衡的值，在16GB显存的机器上跑BGE-M3没问题。如果你用API，批量大小可以设到256，因为API通常有并发限制但单次可以处理更多。

缓存机制是必须的。我用的是基于文档哈希的缓存——每个文档块计算MD5，如果哈希已经存在向量库里，就跳过重新向量化。这样在增量更新时，只有新增或修改的文档会被处理，速度提升非常明显。我有个项目知识库有3万多个块，全量向量化要40分钟，增量更新通常只要几十秒。

3.3 检索策略的混合方案

纯向量检索有个致命问题：它对精确匹配不敏感。比如用户问“错误码E5021怎么解决”，向量检索可能返回一堆关于错误处理的通用文档，但就是找不到那个特定错误码的说明。这时候需要关键词检索来兜底。

我的方案是混合检索：向量检索召回Top-20，BM25关键词检索也召回Top-20，然后合并去重，再用重排模型统一打分。BM25我用的是rank_bm25这个轻量库，不需要额外部署搜索引擎。两路召回的结果合并后通常有25到30个片段，重排后取Top-5。

这个混合策略对两类问题特别有效：一是包含专有名词的问题（产品名、错误码、人名），二是包含精确数值的问题（版本号、日期、金额）。纯向量检索在这两类问题上经常翻车，加上BM25之后召回率明显改善。

3.4 提示词模板的设计要点

生成环节的提示词模板看似简单，其实很讲究。我的模板包含四个部分：

角色定义：告诉模型它是谁，比如“你是一个技术支持助手，基于提供的文档片段回答用户问题”。

上下文注入：把检索到的片段按相关度排序后拼接，每个片段前面加编号，方便模型引用。

回答约束：明确要求“如果文档中没有相关信息，直接说不知道，不要编造”。这句话能大幅降低幻觉率。

引用格式：要求模型在回答中标注引用的片段编号，比如“根据[1]和[3]”。这样用户能追溯答案来源，信任度更高。

我试过不加引用格式要求，结果模型经常把多个片段的信息混在一起，用户无法验证。加上引用后，不仅可追溯性好了，模型本身也更谨慎，因为它知道每个说法都要有出处。

4. 完整实操流程与关键环节实现

4.1 环境准备与依赖安装

整个方案的核心依赖就四个：langchain、chromadb、sentence-transformers、rank_bm25。Python版本建议3.10以上，3.9也能跑但有些库的兼容性会出问题。

pip install langchain langchain-community chromadb sentence-transformers rank-bm25 pypdf unstructured

如果你用OpenAI或者DeepSeek的API做生成，还需要装对应的SDK：

pip install openai

硬件方面，嵌入模型BGE-M3在CPU上也能跑，但速度大概是GPU的十分之一。如果你有NVIDIA显卡，建议装CUDA版本的PyTorch。没有显卡的话，用API做嵌入也完全可行，成本大约是每百万token几毛钱。

4.2 文档加载与切分的代码实现

from langchain_community.document_loaders import PyPDFLoader, TextLoader, UnstructuredMarkdownLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 加载文档 def load_documents(file_path): if file_path.endswith('.pdf'): loader = PyPDFLoader(file_path) elif file_path.endswith('.md'): loader = UnstructuredMarkdownLoader(file_path) else: loader = TextLoader(file_path, encoding='utf-8') return loader.load() # 切分配置 splitter = RecursiveCharacterTextSplitter( chunk_size=800, chunk_overlap=200, separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""], length_function=len, ) docs = load_documents("knowledge_base.pdf") chunks = splitter.split_documents(docs) print(f"切分完成，共{len(chunks)}个块")

这段代码里有个细节：分隔符列表里我把中文标点放在了英文标点前面。因为中文文档里句号、问号的使用频率远高于英文句点，优先按中文标点切分能更好地保持语义完整性。

4.3 向量化与索引构建

from sentence_transformers import SentenceTransformer import chromadb import hashlib # 初始化嵌入模型 embed_model = SentenceTransformer('BAAI/bge-m3') # 初始化ChromaDB client = chromadb.PersistentClient(path="./rag_db") collection = client.get_or_create_collection( name="knowledge", metadata={"hnsw:space": "cosine"} ) # 批量向量化并入库 def index_chunks(chunks, batch_size=64): for i in range(0, len(chunks), batch_size): batch = chunks[i:i+batch_size] texts = [c.page_content for c in batch] ids = [hashlib.md5(t.encode()).hexdigest() for t in texts] # 检查是否已存在 existing = collection.get(ids=ids) new_indices = [j for j, id_ in enumerate(ids) if id_ not in existing['ids']] if not new_indices: continue new_texts = [texts[j] for j in new_indices] new_ids = [ids[j] for j in new_indices] new_metadatas = [batch[j].metadata for j in new_indices] embeddings = embed_model.encode(new_texts, normalize_embeddings=True) collection.add( ids=new_ids, documents=new_texts, embeddings=embeddings.tolist(), metadatas=new_metadatas ) print(f"已索引 {i+len(batch)}/{len(chunks)}") index_chunks(chunks)

这里有个关键点：normalize_embeddings=True。BGE系列模型在训练时使用了归一化后的向量，推理时也必须归一化，否则相似度计算会有偏差。这个坑我踩过，不归一化的话检索结果会明显变差。

4.4 混合检索与重排

from rank_bm25 import BM25Okapi import jieba # 构建BM25索引 tokenized_corpus = [list(jieba.cut(c.page_content)) for c in chunks] bm25 = BM25Okapi(tokenized_corpus) def hybrid_retrieve(query, top_k=20): # 向量检索 query_embedding = embed_model.encode([query], normalize_embeddings=True) vector_results = collection.query( query_embeddings=query_embedding.tolist(), n_results=top_k ) # BM25检索 tokenized_query = list(jieba.cut(query)) bm25_scores = bm25.get_scores(tokenized_query) bm25_top_indices = sorted(range(len(bm25_scores)), key=lambda i: bm25_scores[i], reverse=True)[:top_k] # 合并去重 seen = set() merged = [] for doc, id_ in zip(vector_results['documents'][0], vector_results['ids'][0]): if id_ not in seen: seen.add(id_) merged.append(doc) for idx in bm25_top_indices: doc = chunks[idx].page_content if doc not in seen: seen.add(doc) merged.append(doc) return merged

BM25的中文分词我用的是jieba。如果你处理的是英文文档，直接用空格分词就行。这里有个细节：BM25的分数和向量相似度的量纲完全不同，不能直接加权合并。我的做法是分别取Top-20然后合并去重，让重排模型来做最终的排序决策。

4.5 重排与生成

from sentence_transformers import CrossEncoder # 重排模型 reranker = CrossEncoder('BAAI/bge-reranker-v2-m3') def rerank_and_generate(query, candidates, top_n=5): # 重排 pairs = [[query, doc] for doc in candidates] scores = reranker.predict(pairs) ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True) top_docs = [doc for doc, _ in ranked[:top_n]] # 构建提示词 context = "\n\n".join([f"[{i+1}] {doc}" for i, doc in enumerate(top_docs)]) prompt = f"""你是一个技术支持助手。请基于以下文档片段回答用户问题。 文档片段： {context} 用户问题：{query} 要求： 1. 只使用文档片段中的信息回答 2. 如果文档中没有相关信息，直接说"根据现有资料无法回答" 3. 在回答中标注引用的片段编号，如[1][3] """ return prompt, top_docs

重排模型我选的是BGE-Reranker-v2-m3，它和BGE-M3嵌入模型是配套的，配合使用效果最好。CrossEncoder的推理速度比双塔模型慢，但精度高很多。20个片段的重排大约需要300毫秒，这个延迟在可接受范围内。

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

5.1 检索结果不相关的排查思路

这是最常见的问题。我一般按以下顺序排查：

第一步，检查切分质量。随机抽几个检索到的片段，看看它们本身是否语义完整。如果片段本身就是断断续续的，那检索再准也没用。切分问题通常表现为片段以连词开头、以逗号结尾、或者包含多个不相关的主题。

第二步，检查嵌入模型是否匹配。如果你用中文模型处理英文文档，或者用通用模型处理专业领域文档，效果都会打折扣。BGE-M3虽然支持多语言，但在特定领域（比如医疗、法律）上，用领域数据微调过的嵌入模型效果会好很多。

第三步，检查查询改写。用户的问题往往很短，比如“怎么退款”。这种查询的向量表示信息量太少，检索效果自然差。我的做法是加一个查询改写步骤，用一个小模型把用户问题扩展成更完整的查询，比如“用户申请退款的操作流程和条件是什么”。这一步能显著提升召回率。

第四步，检查重排模型。如果重排后的Top-5仍然不相关，可能是重排模型和嵌入模型不兼容。建议用同一系列的模型，比如BGE-M3配BGE-Reranker-v2-m3。

5.2 生成答案包含幻觉的处理

幻觉是RAG的顽疾。我的经验是，幻觉主要来自三个原因：

上下文不足：检索到的片段没有包含答案，但模型还是硬答。解决方案是在提示词里加一句“如果文档中没有相关信息，直接说不知道”。这句话看起来简单，但效果立竿见影。

上下文冲突：检索到的多个片段包含矛盾信息。这时候模型会倾向于选择它认为更合理的那个，而不是更准确的那个。解决方案是在提示词里要求模型“如果发现信息冲突，请指出冲突并分别说明”。

模型过度推理：模型基于片段中的信息做了超出范围的推理。比如片段说“A产品支持退款”，模型推理出“A产品支持无条件退款”。解决方案是要求模型“只陈述文档中明确写出的信息，不要做额外推断”。

实操心得：我通常会在生成后加一个校验步骤，用另一个模型调用检查答案中的每个说法是否能在检索片段中找到依据。这个步骤会增加一次API调用，但对降低幻觉率非常有效。

5.3 性能优化的几个实用技巧

嵌入模型常驻内存：不要在每次请求时重新加载模型。把模型加载放在服务启动时，后续请求复用同一个实例。加载BGE-M3大约需要10秒，如果每次请求都加载，响应时间根本没法看。

向量索引预热：ChromaDB在首次查询时会加载索引到内存，第一次查询可能比较慢。可以在服务启动后先跑一个空查询预热。

异步处理：检索和生成可以并行。向量检索和BM25检索互不依赖，可以用asyncio.gather同时执行。重排必须在检索之后，但生成可以在重排的同时准备提示词模板。

缓存高频查询：用户的问题往往有重复。我用一个简单的LRU缓存存储最近1000个查询的结果，命中率大约在30%左右，对降低延迟帮助很大。

5.4 常见问题速查表

6. 对知乎看山项目组的一点建议

看山项目组做的是知识问答方向的产品，我作为用户和开发者双重身份，有一些观察想分享。这些建议不是批评，纯粹是从技术实现角度出发的思考。

6.1 检索层可以更透明

目前看山的回答有时候会让人困惑——为什么这个问题给出了这个答案？用户看不到检索过程，只能看到最终结果。我的建议是，在回答下方增加一个“参考来源”区域，列出检索到的关键片段。这不仅能提升用户信任度，还能让用户自己判断答案是否可靠。技术上实现很简单，就是把检索到的Top-3片段摘要展示出来。

6.2 混合检索值得尝试

纯向量检索在精确匹配场景下的短板很明显。如果看山目前用的是纯向量方案，建议加入BM25或类似的稀疏检索作为补充。特别是当用户问题包含专有名词、产品名、错误码时，关键词检索的召回率远高于向量检索。两路合并再重排，成本增加不多，但效果提升明显。

6.3 查询改写是个低成本高回报的优化点

用户的问题往往很短、很口语化。直接拿这种查询去检索，效果天然受限。加一个轻量的查询改写步骤——用一个小模型把口语化问题扩展成结构化查询——能显著提升召回率。这个步骤的额外延迟大约100到200毫秒，但检索质量的提升是值得的。

6.4 反馈闭环很重要

RAG系统最怕的是“不知道自己做得好不好”。建议在回答旁边加一个简单的反馈按钮（有用/没用），收集用户的隐式反馈。这些数据可以用来评估检索质量，也可以用来微调重排模型。没有反馈闭环的RAG系统，优化全靠猜。

6.5 别过度追求新技术

GraphRAG、Agentic RAG这些概念很热，但落到实际产品里，稳定性和响应速度才是用户最关心的。我的建议是先把朴素RAG加混合检索加重的方案做扎实，把检索准确率和响应延迟优化到极致，再考虑引入更复杂的架构。用户不会因为你的技术栈先进而满意，他们只会因为答案准确、响应快速而满意。

这套用户级RAG方案我在几个小项目里跑了大半年，检索准确率（Top-5命中率）稳定在85%以上，平均响应时间控制在2秒以内。对于个人开发者和小团队来说，这个投入产出比是相当划算的。如果你也在做类似的事情，欢迎交流踩坑经验。