1. 为什么企业都在折腾 RAG 知识库这两年但凡跟企业内部系统打过交道的人应该都听过 RAG 这个词。全称是 Retrieval-Augmented Generation检索增强生成。说人话就是让大模型在回答问题之前先去你的资料库里翻一翻找到相关内容再组织语言回答而不是全靠它脑子里记的那些训练数据。我最早接触 RAG 是因为一个很实际的问题。公司内部有几千份产品文档、技术手册、客服工单记录新来的同事想查一个参数配置得在好几个系统里翻半天。当时想的是能不能做个问答机器人直接问它就行。试过直接把文档塞给大模型结果就是胡编乱造明明文档里写的是 A它给你答成 B。后来才转向 RAG 这条路。RAG 的核心价值在于解决大模型的三个硬伤知识过时、幻觉严重、无法访问私有数据。你不可能每次文档更新都去微调一遍模型成本扛不住。但 RAG 可以做到文档一更新重新灌入向量库就行模型本身不用动。那为什么是腾讯云向量数据库说实话向量数据库的选择很多Milvus、Qdrant、Weaviate、Chroma 都能用。但企业场景下要考虑的东西不一样运维成本、权限管理、网络延迟、数据安全、跟现有云基础设施的整合难度。腾讯云向量数据库在这些方面对国内企业比较友好尤其是已经在用腾讯云其他服务的团队内网打通之后延迟很低权限体系也能直接复用。这篇文章适合谁看如果你是后端开发、算法工程师、技术负责人正在考虑给公司搭一套内部知识库问答系统或者你自己想练手一个 RAG 项目那接下来的内容应该能帮你少走一些弯路。我会从架构设计讲到代码实现再到实际踩过的坑尽量把每个环节说透。2. 整体架构设计与技术选型思路2.1 RAG 系统的核心链路拆解一个完整的 RAG 系统从用户提问到拿到答案中间要经过好几个环节。我把它拆成两条线离线索引线和在线查询线。离线索引线负责把原始文档处理成向量库能存的东西。流程是文档采集 → 格式解析 → 文本清洗 → 分块 → 向量化 → 存入向量数据库。这条线通常是批处理文档更新时触发。在线查询线负责实时响应用户。流程是用户提问 → 问题向量化 → 向量库检索 → 召回结果重排序 → 拼接 Prompt → 大模型生成 → 返回答案。这条线要求低延迟通常几百毫秒到几秒。两条线的交汇点就是向量数据库。它既是离线索引的终点也是在线查询的起点。所以向量数据库选得好不好直接决定了整个系统的上限。2.2 为什么选腾讯云向量数据库而不是自建我一开始是用 Chroma 在本地搭的原型跑通没问题但一上生产就露馅了。Chroma 单机部署数据量一大查询就慢而且没有高可用挂了就全挂。后来评估了几个方案方案优势劣势适用场景Chroma轻量、上手快单机、无高可用、性能有限原型验证、个人项目Milvus功能全、社区活跃运维复杂、资源占用高有专职运维的团队Qdrant性能好、Rust 编写国内文档少、生态一般技术栈匹配的团队腾讯云向量数据库托管运维、内网低延迟、权限体系完善绑定云厂商已在用腾讯云的企业选腾讯云向量数据库的核心理由是运维成本。自建 Milvus 集群你得考虑节点扩缩容、数据备份、监控告警、版本升级这些加起来至少得半个人力。托管服务把这些都包了你只需要关注数据怎么灌、怎么查。另一个理由是网络延迟。如果你们的应用已经部署在腾讯云上向量数据库走内网延迟能控制在个位数毫秒。走公网的话光网络往返就得几十毫秒检索环节的延迟直接翻倍。2.3 大模型的选择与接入方式向量库解决了“找得到”的问题大模型解决“答得好”的问题。这两者要配合好。大模型的选择要看几个维度上下文长度、推理成本、响应速度、中文能力。上下文长度决定了你能往 Prompt 里塞多少召回内容。一般 RAG 场景召回 3 到 5 个片段每个片段 500 字左右加上系统提示词和用户问题总共 3000 到 5000 token 就够了。但如果你的文档片段比较长或者需要召回更多结果那就得选上下文窗口更大的模型。接入方式上可以用腾讯云的大模型 API也可以用其他兼容 OpenAI 接口的模型服务。关键是接口要稳定延迟要可控。我实测下来同一个问题不同模型的回答质量差异很大建议在正式接入前先做一轮评测用你们自己的业务问题测一遍。3. 核心细节解析与实操要点3.1 文档分块策略RAG 效果的分水岭文档分块是 RAG 系统里最容易被忽视、但对效果影响最大的环节。分块分得好检索命中率高分块分得烂向量库再强也白搭。我踩过的坑是这样的一开始图省事按固定字数切每 500 字一块。结果一个问题涉及跨段落的内容检索出来的片段全是半截话大模型拿到之后也拼不出完整答案。后来改成按语义分块效果好很多。具体怎么做几个原则按文档结构分Markdown 按标题层级分PDF 按章节分HTML 按 DOM 结构分。这样每块内容是完整的语义单元。控制块大小一般 300 到 800 字比较合适。太短了信息量不够太长了检索精度下降。设置重叠区相邻块之间重叠 50 到 100 字避免边界信息丢失。保留元数据每块要带上来源文档、章节标题、页码等信息方便后续溯源和过滤。腾讯云向量数据库支持在插入向量时附带 metadata这个功能一定要用起来。比如你可以给每块打上“部门”“文档类型”“更新时间”的标签查询时就能按条件过滤缩小检索范围。3.2 向量化模型的选择与调用文本转向量得用 Embedding 模型。这个模型的选择直接影响检索质量。国内常用的有腾讯云自己的 Embedding 服务、百度文心的 Embedding、还有开源的 BGE 系列。我对比过几个BGE-large-zh开源里中文效果最好的之一但需要自己部署推理有延迟。腾讯云 Embedding托管服务调用方便跟向量数据库同厂兼容性好。其他云厂商 Embedding效果参差需要实测。选 Embedding 模型要看两个指标检索准确率和推理速度。准确率可以用标注好的问答对来测看 Top-5 召回里有多少是相关的。速度的话批量处理时吞吐量很重要单条查询时延迟更重要。调用方式上腾讯云向量数据库的 SDK 支持直接传入文本它内部会调用 Embedding 服务。也可以自己先算好向量再传入这样更灵活但要多一步处理。3.3 检索策略从粗排到精排向量检索不是万能的。纯向量检索有个问题它擅长语义相似但不擅长精确匹配。比如你搜一个产品型号“XR-2000”向量检索可能给你返回一堆“XR-1000”“XR-3000”的内容因为语义上它们很像。所以生产环境一般用混合检索向量检索 关键词检索然后融合排序。腾讯云向量数据库支持标量过滤可以配合向量检索做混合查询。比如你先用关键词过滤出包含“XR-2000”的文档再在这些文档里做向量检索精度会高很多。检索出来之后还有一步重排序。可以用 Cross-Encoder 模型对召回结果重新打分把最相关的排前面。这一步会增加延迟但对最终答案质量提升明显。如果延迟敏感可以只对 Top-10 做重排取 Top-3 送给大模型。4. 实操过程与核心环节实现4.1 环境准备与依赖安装先把环境搭起来。Python 版本建议 3.8 以上我用的 3.10兼容性比较好。pip install tcvectordb pip install langchain pip install sentence-transformers pip install pypdf pip install markdown腾讯云向量数据库的 Python SDK 是tcvectordb这是官方提供的。LangChain 用来做文档加载和分块sentence-transformers 用来做本地 Embedding如果你想自己算向量的话pypdf 和 markdown 用来解析不同格式的文档。安装完之后去腾讯云控制台创建一个向量数据库实例。注意选地域要跟你应用部署的地域一致这样走内网。创建的时候会让你设置用户名密码记下来后面连接要用。4.2 连接向量数据库与创建集合连接代码大概长这样import tcvectordb from tcvectordb.model.collection import Collection from tcvectordb.model.document import Document from tcvectordb.model.index import Index, FilterIndex, VectorIndex client tcvectordb.VectorDBClient( url你的实例访问地址, username你的用户名, key你的密钥 ) db client.database(knowledge_base) # 创建集合 index Index() index.add(VectorIndex(vector, 768, HNSW)) index.add(FilterIndex(doc_id, string)) index.add(FilterIndex(chunk_index, int64)) index.add(FilterIndex(source, string)) collection db.create_collection( nameenterprise_docs, shard1, replicas1, description企业知识库文档集合, indexindex )这里有几个关键点。向量维度 768 是因为我用的 Embedding 模型输出是 768 维你要根据自己用的模型调整。索引类型选 HNSW这是目前最常用的近似最近邻算法查询快召回率也不错。FilterIndex 是标量索引用来做条件过滤doc_id、chunk_index、source 这些字段建上索引查询时过滤会快很多。分片数和副本数根据数据量来。数据量小的话1 分片 1 副本就够。数据量大了再扩。4.3 文档处理与向量化入库文档处理是重头戏。我写了一个处理管道支持 Markdown、PDF、纯文本三种格式。import os from langchain.text_splitter import MarkdownHeaderTextSplitter, RecursiveCharacterTextSplitter from langchain.document_loaders import PyPDFLoader def process_markdown(file_path): with open(file_path, r, encodingutf-8) as f: content f.read() headers_to_split_on [ (#, h1), (##, h2), (###, h3), ] splitter MarkdownHeaderTextSplitter(headers_to_split_onheaders_to_split_on) chunks splitter.split_text(content) # 二次分块控制大小 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, length_functionlen, ) final_chunks [] for chunk in chunks: if len(chunk.page_content) 800: sub_chunks text_splitter.split_text(chunk.page_content) for sub in sub_chunks: final_chunks.append({ text: sub, metadata: chunk.metadata }) else: final_chunks.append({ text: chunk.page_content, metadata: chunk.metadata }) return final_chunksMarkdown 先按标题层级切这样每块内容有明确的章节归属。如果切完还是太大再用 RecursiveCharacterTextSplitter 二次切分。重叠区设 80 字保证边界信息不丢。PDF 处理类似但 PDF 解析出来经常有格式问题比如换行错乱、表格丢失。我的经验是PDF 最好先转成 Markdown 再处理可以用一些转换工具或者人工校对一遍。表格内容单独处理转成结构化数据存。入库的时候批量插入比单条插入快很多。腾讯云向量数据库支持批量写入一次传 100 条左右比较合适。def insert_documents(collection, chunks, doc_id, source): documents [] for i, chunk in enumerate(chunks): doc Document( idf{doc_id}_{i}, vectorNone, # 让服务端自动计算 textchunk[text], doc_iddoc_id, chunk_indexi, sourcesource ) documents.append(doc) # 批量插入 for i in range(0, len(documents), 100): batch documents[i:i100] collection.upsert(documentsbatch)这里 vector 传 None让腾讯云向量数据库自己调用 Embedding 服务算向量。这样省事但要注意 Embedding 服务的调用配额和费用。4.4 查询链路实现与 Prompt 组装查询链路的核心是问题向量化 → 检索 → 组装 Prompt → 调用大模型。def query_knowledge_base(collection, question, top_k5): # 检索 results collection.search( vectors[None], # 自动计算问题向量 query_texts[question], limittop_k, output_fields[text, source, doc_id] ) # 组装上下文 context_parts [] for result in results[0]: context_parts.append(f[来源: {result.source}]\n{result.text}) context \n\n---\n\n.join(context_parts) # 组装 Prompt prompt f你是一个企业知识库助手。请根据以下参考资料回答用户问题。 如果参考资料中没有相关信息请如实告知不要编造。 参考资料 {context} 用户问题{question} 请给出准确、简洁的回答 return promptPrompt 组装有几个技巧。第一明确告诉模型“没有相关信息就如实说”这能大幅降低幻觉。第二给每个片段标注来源方便用户溯源。第三控制上下文长度别超过模型的上下文窗口。调用大模型的时候温度参数建议设低一点0.1 到 0.3 之间这样回答更稳定不容易发散。5. 常见问题与排查技巧实录5.1 检索不准怎么办这是最常见的问题。用户问了一个问题检索出来的内容完全不相关。排查思路分几步走。先看分块是不是有问题把检索出来的片段打印出来看看内容是不是完整的。如果片段是半截话那就是分块策略要调整。再看 Embedding 模型是不是适合你的领域通用 Embedding 模型在专业领域可能表现不好可以考虑用领域数据微调一下。最后看检索参数top_k 设了多少相似度阈值设了多少这些都会影响结果。我遇到过一个案例用户问“报销流程是什么”检索出来的全是“报销标准”“报销范围”就是没有流程。后来发现是分块的时候流程部分被切成了好几块每块都不完整。改成按步骤分块之后问题解决了。5.2 大模型回答胡编乱造RAG 的初衷就是减少幻觉但如果检索环节没做好大模型拿不到正确信息还是会编。解决办法有几个。第一Prompt 里明确要求“只根据参考资料回答”。第二设置相似度阈值检索结果相似度低于阈值的直接丢弃宁可告诉用户“没找到相关信息”。第三加一个校验环节让大模型在回答时标注引用的来源如果它标不出来说明它在编。实测下来相似度阈值设在 0.7 左右比较合适。太低了很多不相关的内容会被召回太高了可能漏掉一些相关内容。这个值要根据你的数据特点调。5.3 响应速度慢怎么优化RAG 系统的延迟主要来自三个环节向量检索、大模型推理、网络传输。向量检索的优化建好索引HNSW 的参数调一调ef 值设大一点查询更准但更慢设小一点更快但可能漏。数据量大的话用分区或者分片。大模型推理的优化用流式输出用户能更快看到第一个字。选推理速度快的模型或者用更小的模型做初步回答复杂问题再路由到大模型。网络传输的优化向量数据库和应用部署在同一地域走内网。大模型 API 如果支持就近接入也选最近的地域。我实测下来一个优化好的 RAG 系统端到端延迟能控制在 2 秒以内。如果超过 5 秒用户就会觉得卡了。5.4 常见问题速查表问题现象可能原因排查方法解决方案检索结果不相关分块不合理打印检索片段检查完整性调整分块策略按语义分块回答胡编乱造检索没命中模型硬编检查检索相似度分数设相似度阈值Prompt 加约束响应慢索引未优化看检索耗时和大模型耗时调 HNSW 参数用流式输出重复内容多分块重叠过大检查 chunk_overlap 设置减小重叠区去重专业术语检索不到Embedding 模型不匹配用专业术语测试检索微调 Embedding 或加关键词检索6. 企业级 RAG 的进阶优化方向6.1 混合检索与重排序的实战配置纯向量检索在生产环境是不够的。我现在的配置是向量检索召回 Top-20关键词检索召回 Top-20合并去重后得到大概 30 条候选然后用重排序模型精排取 Top-5 送给大模型。关键词检索可以用 Elasticsearch 或者腾讯云向量数据库自带的标量过滤。如果文档里有明确的关键词字段比如产品型号、错误码标量过滤效率很高。重排序模型推荐用 BGE-Reranker中文效果不错。部署一个轻量级的重排序服务延迟增加 100 毫秒左右但答案质量提升明显。6.2 多轮对话与上下文管理用户不会只问一个问题多轮对话是常态。RAG 系统要能记住上下文。实现方式是在 Prompt 里带上历史对话。但要注意历史对话不能太长否则会挤占召回内容的空间。我的做法是只带最近 3 轮对话而且只带用户问题和系统回答的摘要不带完整内容。另一个问题是指代消解。用户第二句问“那它的参数呢”这个“它”指的是什么系统得知道。可以在 Prompt 里让大模型先做指代消解把“它”替换成具体名词再去检索。6.3 权限控制与数据隔离企业知识库不是所有人都能看所有文档。权限控制必须在检索环节就做好不能等大模型回答完了再过滤。腾讯云向量数据库支持在 metadata 里存权限标签查询时用标量过滤。比如每个文档块打上“部门:技术部”“密级:内部”的标签用户查询时带上自己的部门信息只检索有权限的内容。这个逻辑要在应用层实现用户登录 → 获取权限信息 → 查询时拼装过滤条件 → 只返回有权限的结果。6.4 效果评估与持续迭代RAG 系统上线不是终点是起点。要持续评估效果持续优化。评估指标分两类检索指标和生成指标。检索指标看召回率、准确率、MRR。生成指标看答案相关性、忠实度、完整性。可以用人工评估也可以用大模型自动评估。我一般会维护一个测试集包含 100 到 200 个典型问题每个问题有标准答案。每次调整参数或者更新模型都跑一遍测试集看指标有没有提升。这样能避免拍脑袋决策。7. 一些实操心得与避坑建议先说一个最容易踩的坑文档清洗不彻底。很多企业的文档里有大量格式噪音比如页眉页脚、水印、乱码。这些内容如果不清洗会被当成正文灌入向量库检索时就会干扰结果。我的做法是入库前先跑一遍清洗规则把明显的噪音去掉然后再人工抽检一批。第二个坑是 Embedding 模型的维度不匹配。不同模型输出的向量维度不一样有的 768 维有的 1024 维有的 1536 维。创建集合的时候维度一定要跟模型对齐否则插入会报错。而且一旦创建了集合维度就不能改了要改只能重建集合。第三个坑是忽略了增量更新。企业文档是不断更新的今天加了一份新文档明天改了一份旧文档。RAG 系统要支持增量更新不能每次都全量重建。腾讯云向量数据库支持按 ID 更新和删除用文档 ID 作为主键更新时直接覆盖就行。第四个坑是 Prompt 太长导致截断。大模型的上下文窗口是有限的如果召回内容太多加上历史对话很容易超。超了之后模型会截断可能把关键信息截掉。我的做法是在组装 Prompt 之前先算一下 token 数超了就减少召回数量或者压缩历史对话。最后一个建议不要追求一步到位。先搭一个最小可用版本跑通链路然后再逐步优化。我见过太多团队一开始就想做完美结果三个月过去了还没上线。先上线再迭代这才是正道。这个系统后续还可以扩展的方向很多比如接入更多文档源、支持多模态内容、做主动推荐、跟业务系统深度集成。但那是下一步的事了先把核心链路跑稳再说。