尧图网页设计 
写好一个企业级的智能问答系统Embedding 和向量化这一环往往决定了整个系统的上限。很多人最开始搭 RAG 问答的时候习惯把注意力放在模型选型和 Prompt 设计上结果上线以后才发现文档切得稀碎、检索召回一堆不相关片段、答非所问最后还得回来折腾向量化这块。这一章专门把 Embedding 与向量化实战拆开揉碎讲一遍。我会从最朴素的原理说起讲清楚企业和个人在搭建智能问答系统时应该如何选择 Embedding 模型、如何设计向量化流程、如何在召回质量和工程成本之间做取舍最后附上可以直接抄走的落地代码和踩坑记录。不管你是刚入门想做一个人知识库问答机器人还是公司里要接一套正式的智能问答基础设施这一章的内容都能直接参考。1. 内容整体设计与思路拆解1.1 为什么向量化是智能问答系统的“地基”智能问答系统的核心链路简单来说就四步文档解析、文本切块、向量化、召回应答。嵌入向量Embedding做的事情是把自然语言转换成一串浮点数。这串数字在向量空间中表示文本的“语义坐标”——语义相近的文本坐标上距离就近语义无关的文本坐标上就离得远。这套思路之所以能跑通是因为现代语言模型LM在预训练阶段已经学到了大量语言规律与知识。Embedding 模型则是把这种语义理解能力压缩成稠密向量。比如“今天上海天气怎么样”和“上海今日气温”两句话表面词完全不同但语义相近经过一个优秀的 Embedding 模型编码后它们的余弦相似度会明显高于与“今天股票涨了”这类无关句子的相似度。在实际项目中向量化环节为两个下游模块服务第一离线建库阶段把知识库文档向量化之后写入向量数据库构建索引第二在线问答阶段把用户问题向量化在库里做相似度检索召回 top-k 候选片段。可以说向量化的质量直接决定检索质量而检索质量又直接决定问答系统的准确性。在真实的问答系统测试里我发现相当一部分“模型回答得不好”的问题根子其实在检索阶段就错了——相关片段根本没被召回给到大模型的上下文就是残缺的。所以Embedding 与向量化的定位是整个系统的地基工程。这块地基没打好后续的模型调优、Prompt 优化都只是表面功夫。1.2 构建这一章的三个核心思路在开始动手之前我先梳理了三条贯穿全程的思路这也是我这一章内容设计的骨架。第一条思路用教训驱动原理。 我不会一上来就堆公式而是从实际业务问题出发。比如“为什么长文档直接丢进模型效果很差”——引导我们发现切块的必要性“为什么同一个模型在中文场景下时而好用时而离谱”——引导我们理解训练语料与模型场景匹配的重要性。每一个技术点都对应一个实际痛点这样理解起来才不会飘。第二条思路限制条件下的工程选型。 企业级应用和实验室玩具最大的区别在于约束条件。实验室可以随便选个开源模型跑一跑企业级要考虑推理成本、响应延迟、并发量、运维复杂度、数据隐私、合规要求。所以在模型选型、向量数据库选型、索引配置上每一步都要展开“为什么这么选”的权衡过程。第三条思路全链路可复现、可度量。 只会在 Notebook 里跑通 demo 没有意义真正的工程化至少要满足三点代码可重复执行数据可追踪哪些文档入库了、什么版本效果可量化召回率、命中率、端到端准确率。这一章每个实操环节都会朝这个方向靠拢给出一套可复现的流程。2. Embedding 模型选型与新趋势2.1 主流 Embedding 模型对比与选型逻辑进入模型选型环节先看一组当前技术社区里讨论热度比较高的模型覆盖闭源 API 和开源本地部署两条路线。这张表的数据是我在多个真实场景下的综合体验评估具体数值会因测试集不同有浮动但可以反映大方向模型维度语言侧重最大输入长度部署方式适用场景text-embedding-3-small1536/512多语言8191 tokensAPISaaS 快速验证text-embedding-3-large3072/1024多语言8191 tokensAPI对精度要求高的场景bge-m31024中英多语8192 tokens开源/本地中文为主的企业私有化部署bge-large-zh-v1.51024中文512 tokens开源/本地中文检索、句子相似度m3e-base768中英2048 tokens开源/本地中文语义匹配siglip21152图文图像/文本开源/本地图文多模态问答先说 API 路线。OpenAI 的 text-embedding-3 系列最大的优势是省事、稳定、语义能力强documents 和 query 都直接调接口就行。企业如果想要两三天内做出一个可用的问答系统可以先用它跑通流程。代价是数据要出网并且每次调用都有费用。如果公司有严格的数据安全要求这条路线直接跳过。开源路线里bge 系列BAAI General Embedding是我在中文场景里用得最多的。bge-m3 是第三代多语言模型同时支持稠密检索、稀疏检索和多向量检索。它的训练数据覆盖了中英等多种语言最大长度到 8k非常适合中文企业知识库场景。它最让我满意的是不需要像第一代 bge 那样给 query 加“为这个句子生成表示以用于检索相关文章”这种指令前缀减少了很多不必要的麻烦。m3e-base 则是更轻量级的选择768 维、2.04 亿参数CPU 上也能跑。如果文档量不大、只需要简单的中文语义匹配它的性价比很高。这里多说一句不是维度越大越好。 维度越高单条向量的存储空间越大在相同内存下能支撑的向量数量就越少检索耗时也会增加。1536 维和 1024 维之间每百万条向量的存储差异大约 0.5-1GB对生产环境的成本有明显影响。维度选择要和业务数据量、硬件资源一起综合考虑。2.2 多模态与推理型向量模型的新趋势最近技术社区里“siglip2 向量化”的热度上升很快。SIGLIP 系列是“基于 Sigmoid Loss 的图像-语言预训练”模型SIGLIP2 进一步增强了图文联合嵌入能力。它输出的视觉与文本嵌入在同一个向量空间可以直接用文本向量去检索图像也可以用图像向量匹配文本描述。这个能力在很多企业场景里价值很大。比如企业内部的知识工单里经常同时包含截图和文字描述传统的方案是把图片先 OCR 转文本再做文本检索信息损耗很大用 siglip2 这种多模态向量模型可以把图片直接编码成向量和文字信息放在同一个库里统一检索。另外一个值得关注的趋势是“推理增强的 Embedding”。以前我们觉得嵌入模型是静态的——给定一段文本输出一个固定的向量不考虑下游任务。但新一代模型开始引入推理能力可以通过自然语言描述检索意图、忽略掉文本里不相关的部分、甚至对文本做二次润色。这个方向的代表有 Qwen3-Embedding 等新一代模型。它在检索问答里带来的变化是用户问“这个东西怎么维修”系统不是简单做关键词匹配而是理解“维修”这个核心意图后在文档里定位真正和维修步骤有关的那段内容。2.3 模型选型避坑经验我踩过最深的坑是换模型之后向量库全部要重建。 这不是开玩笑。不同模型的向量空间完全不同维度也不一样理论上讲A 模型生成的向量和 B 模型的向量直接计算相似度没有任何意义。生产环境一旦要升级 Embedding 模型意味着离线索引全部重新算一遍。如果知识库有几千万条文本这个重建成本是相当惊人的。所以选型的时候一定要想清楚未来规模化增长路径宁可初期稍微多花一点成本选一个长期够用、社区活跃的模型。另外无论选什么模型都建议在项目早期就固定一条“模型版本管理向量版本管理”的规则。比如模型文件保存到专门的对象存储路径下向量数据集在库里带上版本号字段。这样即便后续要重建也能清楚知道哪批向量对应哪个模型版本不至于混在一起导致检索混乱。3. 向量化实战核心技术环节拆解3.1 文本清洗与切块策略拿到原始文档之后第一件事从来不是直接向量化而是清洗。常见来源的文档比如 Word、PDF、Markdown、扫描件转出的文本往往会带着各种噪声多余换行、页眉页脚、乱码、表格错位、引用编号、无意义符号。这些噪声如果不处理进到 Embedding 里的就是脏数据直接影响检索精度。这里分享一套我反复验证过的清洗流程统一字符编码转成 UTF-8剔除无法解析的控制字符。把全角标点转半角数字和英文字母统一格式。去掉文档中重复出现的页眉页脚。可以用规则匹配比如“第 X 页共 Y 页”对 OCR 出来的文本做简单的纠错和粘连修复。最后用正则把连续 3 个以上的换行压缩成 1 个方便后续切块。清洗完成之后才是切块。切块这一步看似简单其实是最影响检索效果的因素之一。切得太短单块缺乏足够上下文语义不完整切得太长一块里包含多个知识点向量被平均拉偏检索精确度下降。我常用的切块基线策略如下固定最大长度 200~300 个字符中文场景按字符数或者 250~350 个 token英文场景按 token 数带 50~80 个字符的重叠。优先按 Markdown 标题#、##和段落边界切。如果是在段落中间截断要把截断位置回退到最近的句号、问号、感叹号。对结构化文档比如操作手册、FAQ、规格书可以用父子分块策略Parent-Child Chunking把大块作为“父块”放进检索候选把更小的子块向量化用于精确匹配。召回时先找到子块再映射回父块作为上下文喂给大模型。这样既保证语义完整又提升精确度。还有几种进阶策略比如基于语义切分通过句子向量判断语义边界、基于文档结构的递归切分这些在 LangChain 这类框架里都有实现但并不意味着“框架自带的一定好”——生产环境里我反而发现纯规则切分往往最可控、最好排查问题。不要一上来就迷信高级方案先把规则切分的效果跑出来再决定要不要上更复杂的策略。3.2 Embedding 批量向量化与数据格式设计文本处理完之后进入向量化环节。实际生产过程中我们很少逐条调用模型基本都是批量处理。批量处理时有两个字段必须想清楚一个是 chunk_id 或者 doc_chunk_id——它是区块的唯一标识另一个是 metadata——用来记录文档来源、标题、页码、章节路径、入库时间、向量模型版本等信息。metadata 非常重要我单独强调一下。原因有两个。第一向量数据库支持 metadata 过滤常见的“只看某个产品线的文档”“只检索最近半年发布的文档”等功能都必须依赖 metadata 过滤实现第二问答系统上线以后需要做效果分析和排查如果你不知道一条被召回的内容来自哪个文档就无法定位问题出在文档本身还是切块策略上。向量化对象应该同时包括文本内容本身和 metadata 信息。有些实现方式会把“标题 章节路径 正文片段”拼接后一起编码让最终的向量携带更多位置信息。在 bge-m3 这类模型下我实测过这个方法的收益对长文档的定位检索准确率有一定提升特别是当正文中出现代词、省略语时标题补全语义的作用非常明显。下面给一个批量向量化的最小参考实现以 bge-m3 FlagEmbedding 为例from FlagEmbedding import BGEM3FlagModel import numpy as np import json # 加载本地模型设备可以指定 cuda:0 或 cpu model BGEM3FlagModel(BAAI/bge-m3, use_fp16True) def embed_texts(texts: list[str], batch_size: int 32) - np.ndarray: 批量向量化输入文本列表返回稠密向量矩阵。 这里只使用 dense 向量忽略 sparse 和 colbert 向量。 all_vectors [] for i in range(0, len(texts), batch_size): batch texts[i : i batch_size] output model.encode(batch, max_length2048)[dense_vecs] all_vectors.append(output) print(fprocessed {min(i batch_size, len(texts))}/{len(texts)}) return np.vstack(all_vectors) # 读取清洗后的切片文本 with open(cleaned_chunks.json, r, encodingutf-8) as f: chunks json.load(f) # 每个元素是 {chunk_id: str, text: str, metadata: dict} texts [c[text] for c in chunks] vectors embed_texts(texts, batch_size64) # 将向量和 metadata 写到磁盘方便后续导入向量数据库 with open(chunk_vectors.npy, wb) as f: np.save(f, vectors)这段代码是完整的离线向量化流程把切好的文本块批量喂给模型拿到向量之后保存成 .npy 文件。实际生产环境里这段代码会包在任务调度系统里跑完一步记录一步状态。批大小建议从 32 或者 64 开始如果你的 GPU 显存有限一次 batch 太大很容易 OOM——这个问题放在后面“常见问题”里细说。3.3 相似度计算与归一化细节向量化产出之后所有下游工作都是围绕“相似度计算”展开的。最常见的两种度量余弦相似度和内积。余弦相似度公式是cos(A, B) (A·B) / (|A| × |B|)。它度量的是两个向量的方向一致性不受向量模长影响。对文本语义匹配来说方向一致就意味着语义相近。而内积则同时考虑方向和模长。在 Embedding 模型默认不归一化的情况下不同长度文本的向量模长会有差异内积结果会偏向长文本所以一般推荐用余弦相似度。不过这里有一个工程上的细节如果对向量做 L2 归一化那么余弦相似度和内积在数值上是完全等价的。很多向量数据库比如 Qdrant、Milvus在构建索引时内部都会做归一化然后在查询时直接算内积加速计算。所以如果使用这类数据库你需要明确知道它的相似度配置是“Cosine”还是“Dot”。如果模型输出的向量没有归一化而数据库端又选了 Dot召回结果会出现偏差。我建议你养成一个习惯在向量入库前做一次显式 L2 归一化并且保留归一化后的向量。这样做有三个好处第一相似度计算语义明确第二后续如果换用内积加速方案不会踩坑第三部分数据库对向量做归一化后配合量化压缩存储成本可以显著下降。4. 向量数据库选型与索引配置4.1 主流向量数据库与场景匹配向量化之后的数据需要一个专门的地方来存储和检索。过去我们可能直接用 Elasticsearch 的 dense_vector 字段或者用关系型数据库的 pgvector 插件但这些方案各有优劣。我把几个主流选项放在一起对比数据库部署方式索引方式适用规模优点注意点QdrantDocker/分布式HNSW亿万级以下轻量、API 简洁、过滤能力强分布式需要单独部署MilvusK8s/分布式HNSW/IVF亿万级功能全、生态好架构较重运维成本高pgvectorPostgreSQL 插件HNSW/IVF千万级以下复用现有 PG 设施高并发检索性能受限Elasticsearch集群HNSW亿级全文检索向量混合配置复杂成本高FAISS嵌入式库HNSW/IVF/PQ内存级性能极致灵活无服务化能力适合研究选择建议很直接中小团队、希望上手快、要控制运维成本用 Qdrant数据量到了亿级、公司已经有 K8s 运维能力选 Milvus业务里已经在重度用 PostgreSQL、不想多维护一套存储系统那 pgvector 是合理的轻量选择如果要同时做关键词检索和向量检索并且预算充足Elasticsearch 可以一套搞定。我在实际项目里用得最多的是 Qdrant它的 metadata payload 支持很灵活检索时可以先按 payload 过滤再搜索返回结果的 score 默认就是余弦相似度方便判断质量。4.2 HNSW 索引参数配置经验分享向量数据库的检索性能很大程度上取决于索引参数的配置。HNSWHierarchical Navigable Small World是目前最常用的 ANNApproximate Nearest Neighbor索引算法它的基本思想是构建一个多层图结构检索时从顶层开始快速向下跳转找到近似最近邻。HNSW 有三个关键参数M每个节点的最大连接数。M 越大图越稠密召回率越高但内存占用和索引时间也增加。推荐范围 16~64。ef_construction建索引时动态候选列表大小。它控制索引质量值越大索引越精确但建库时间越长。推荐 100~200。ef_search查询时的搜索范围。这个参数直接影响查询召回率。实际生产中可以先设成 ef_search 100 左右观察召回质量再逐步加大。这三者的关系可以用一个生活例子帮助理解好比你要在一个大型商场里找人M 决定你最多能找多少位朋友帮你打听ef_construction 决定你打听到的候选人数ef_search 则是你真正愿意逐一询问的人数。三个值配合好才既能找到人又不用跑遍整个商场。从实践看我会推荐这样一组起点配置索引配置: M: 16 ef_construction: 128 ef_search: 128 distance: Cosine对于千万级数据量、单机内存 32G 以上的场景这组配置通常能保证召回率在 95% 以上同时单次查询延迟控制在几十毫秒。如果你的数据量更大可以考虑开启向量量化Scalar Quantization 或 Product Quantization但要注意量化会带来少量精度损失——我用过 PQ 后召回率下降大约 1~2 个百分点接受度取决于业务场景。5. 从零到一的完整实操建立第一个可检索的产品问答知识库5.1 搭建环境与准备样例数据前面铺垫了这么多现在进入实战环节。我们这次的目标是把一批 Markdown 格式的产品操作手册构建成可检索的知识库并实现一问一答的原型验证。技术栈选择如下Embedding 模型BAAI/bge-m3本地部署满足数据不出内网的要求向量数据库QdrantDocker 启动简单快速文本切块自研规则切块按标题和段落边界LLM 应答层调用内部大模型服务如果你本机还没有环境先把基础环境准备好# 创建项目目录 mkdir qa-system-demo cd qa-system-demo # 启动 Qdrant 容器 docker run -p 6333:6333 -p 6334:6334 -v $(pwd)/qdrant_storage:/qdrant/storage qdrant/qdrant # 验证服务运行 curl http://localhost:6333/collections # 预期返回 {result:{collections:[]}}然后准备样例数据。假设有一批 Markdown 文档例如product_manual.md内容是产品安装说明、故障排查等。我们要把它转成可供检索的文本块。5.2 文档解析与切块的完整代码先写一个通用的 Markdown 解析切块逻辑。核心思路按标题层级切出大纲结构保留标题信息在章节内部再按段落切块。import re import json def split_markdown_by_heading(md_text: str): 把 Markdown 按标题层级切块同时保留章节路径。 返回的每个 chunk 包含chunk_id, text, metadata. lines md_text.split(\n) chunks [] current_heading_path [] # 保存多级标题路径 current_lines [] chunk_index 0 heading_pattern re.compile(r^(#{1,4})\s(.*)$) def flush(): nonlocal current_lines, chunk_index if not current_lines: return content \n.join(current_lines).strip() if content: title / .join(current_heading_path) if current_heading_path else full_text f{title}\n{content} if title else content metadata { title: title, chunk_index: chunk_index, source: document_name, } chunks.append({ chunk_id: f{document_name}-{chunk_index}, text: full_text, metadata: metadata, }) chunk_index 1 current_lines [] for line in lines: match heading_pattern.match(line) if match: flush() level len(match.group(1)) heading_text match.group(2).strip() # 多级标题路径截断到当前层级 current_heading_path current_heading_path[: level - 1] [heading_text] else: current_lines.append(line) flush() return chunks这里有一个设计细节值得解释为什么在切块时把标题拼进正文因为很多操作手册里的正文段落经常出现“它”“该功能”这类代词如果没有标题信息单独看正文完全不知道在说哪个模块。把“产品安装指南 / 软件安装步骤”这样的标题拼在正文前能显著提升向量检索时命中的准确性。再看一个段落内切块的补充逻辑如果段落本身超过最大长度限制按句子边界截断并把截断点对齐到标点符号def split_long_paragraph(text: str, max_chars: int 250, overlap: int 50): 将一个过长的段落按句子边界切成多个短块块之间带 overlap。 sentences re.split(r(?[。.!?]), text) chunks [] current_chunk for sent in sentences: if not sent: continue if len(current_chunk) len(sent) max_chars: current_chunk sent else: if current_chunk: chunks.append(current_chunk) # 保留上一句末尾的部分字符作为 overlap if len(current_chunk) overlap: current_chunk current_chunk[-overlap:] sent else: current_chunk sent if current_chunk: chunks.append(current_chunk) return chunks这套切块逻辑在我的项目里迭代过很多次说结论对企业知识库常见的 Markdown 文档标题层级切分段落内按句子切分已经能覆盖 80% 场景。不要一开始就引入复杂的语义切分模型规则简单、结果可控这才是生产系统的正确做法。5.3 向量化入库与查询验证切块完成后就可以做向量化入库。下面的代码把上一步输出的 chunks 批量向量化并写入 Qdrant。先安装依赖pip install qdrant-client FlagEmbedding numpy然后写入库脚本from qdrant_client import QdrantClient from qdrant_client.models import Distance, VectorParams, PointStruct from FlagEmbedding import BGEM3FlagModel import numpy as np import json # 连接 Qdrant client QdrantClient(hostlocalhost, port6333) # 创建 collection维度必须和模型输出一致bge-m3 稠密向量为 1024 维 collection_name product_kb vectors_config VectorParams(size1024, distanceDistance.COSINE) client.recreate_collection( collection_namecollection_name, vectors_configvectors_config, ) # 加载 Embedding 模型 model BGEM3FlagModel(BAAI/bge-m3, use_fp16True) # 读取切块 with open(chunks.json, r, encodingutf-8) as f: chunks json.load(f) points [] batch_size 64 for start in range(0, len(chunks), batch_size): batch chunks[start : start batch_size] texts [c[text] for c in batch] embeddings model.encode(texts)[dense_vecs] for i, emb in enumerate(embeddings): # 显式做 L2 归一化 norm np.linalg.norm(emb) emb_normalized (emb / norm).tolist() point PointStruct( idstart i, vectoremb_normalized, payload{text: batch[i][text], **batch[i][metadata]}, ) points.append(point) # 批量写入 client.upsert( collection_namecollection_name, pointspoints, batch_size64, ) print(ftotal upserted: {len(points)})入库之后来做一次查询验证模拟线上问答环境test_query 产品的保修期是多久 query_vec model.encode([test_query])[dense_vecs][0] norm np.linalg.norm(query_vec) query_vec_normalized (query_vec / norm).tolist() results client.search( collection_namecollection_name, query_vectorquery_vec_normalized, limit5, ) for res in results: print(fscore{res.score:.4f}) print(res.payload[text][:150]) print(---)这一步如果走通你就拥有了一个最小可用的向量检索问答底层。它虽然还是一个原型但是架构上已经具备生产系统的雏形文档可增量更新、检索可实现 metadata 过滤、向量可版本管理。5.4 结合大模型的问答链路向量检索只是整个问答系统的前半段。要让用户得到自然的答案还需要把检索到的 top-k 文本块拼装成上下文交给大模型生成回答。在设计上下文拼装时有几点经验值得分享top-k 不要贪多。 一般取 3~5 个文本块就够了。取太多会把不相关的噪声引入上下文反而降低生成质量还会成倍增加 token 消耗和响应延迟。在上下文里显式标注来源。 比如“[来自文档产品操作指南章节故障排查-电源问题]”这样大模型回答时可以结合来源措辞用户也能追溯到答案出处。召回分数可以作为“置信度”参考。 如果最高分超过 0.7回答可信度较高如果最高分低于 0.5建议让模型直接说“抱歉没有找到足够相关的信息”而不是强行编造。下面是一个简化的组装 Prompt 的示例def build_prompt(query: str, retrieved_chunks: list) - str: context_parts [] for idx, chunk in enumerate(retrieved_chunks): source chunk.payload.get(title, 未知来源) context_parts.append(f[{idx 1}] 来源{source}\n{chunk.payload[text]}) context \n\n.join(context_parts) prompt f你是一个企业知识库问答助手。请基于提供的参考片段回答用户问题。 如果参考片段中不包含答案请直接说明。回答时尽量引用来源。 参考片段 {context} 用户问题{query} 请回答 return prompt到这一步一个“文档进来答案出去”的完整问答链路就搭好了。这段链路看似简单但在真实项目里每一个环节都值得打磨——现在你已经具备了一个可以不断优化的基线。6. 问答系统效果评估与调优6.1 离线评估构建测试集与指标计算问答系统搭完之后最重要的事情不是继续加功能而是建立评估体系。没有评估就没有优化方向。我建议所有项目都做一套离线检索评估集。做法是从知识库里抽取 100~200 个真实用户问题每个问题标记 1~3 个标准答案对应的文档块 ID。然后批量跑检索计算两个常见指标Hit Rate命中率标准答案块是否出现在召回的前 K 个结果中。这是最直观的指标。MRRMean Reciprocal Rank标准答案块在排序中越靠前得分越高。计算方法是 1/rank取所有问题的平均。举个例子假设一个问题有 3 个标准文档块召回 top-5 结果里命中了其中 1 个块排在第二位那这个问题的 MRR 贡献是 1/2 0.5如果完全没命中MRR 为 0。Hit Rate 则相对宽松只要命中就算成功。下面给一个简单的评估脚本骨架def evaluate_retrieval(qa_pairs, retrieved_fn, k5): hit_count 0 mrr_sum 0.0 for item in qa_pairs: query item[query] gold_ids set(item[gold_ids]) hits retrieved_fn(query, kk) hit_list [h.chunk_id for h in hits] if gold_ids set(hit_list): hit_count 1 # MRR 计算 for rank, h in enumerate(hit_list, start1): if h in gold_ids: mrr_sum 1.0 / rank break return hit_count / len(qa_pairs), mrr_sum / len(qa_pairs)我用这套方法在很多项目里做过调优最有价值的发现是在很多所谓“效果不好”的问题里不是模型能力不行而是测试者根本没有建立评估集全靠主观感受调 Prompt。有了离线评估指标你每次改动切块参数、换模型、调索引时都能立刻看到数字变化而不是玄学调参。6.2 常见问题排查与调优路径在大量问答项目的调试过程中我把高频问题和对应排查方向整理成了一个速查表问题现象可能原因排查方向召回结果完全不相关向量化模型与应用场景不匹配或者 query 与文档语言/风格差异过大换模型并在小样本上做召回对比召回结果相关但排序靠后chunk 切得太大信息被稀释或者 query 和文档表述方式差异大缩小 chunk 尺寸增加重叠引入 query 改写特定领域术语检索不到领域词汇在模型词表中语义覆盖不足引入同义词扩展或微调 Embedding 模型某些文档完全不被召回清洗时文档内容被误删或者 metadata 过滤条件错误检查入库日志验证向量库中该文档是否存在检索速度慢索引参数不合理、内存不够、未使用量化增大 ef_search 试试但更优先检查 M 和 ef_construction检索结果被长文本块占据归一化或距离度量配置出了问题检查向量是否做了 L2 归一化数据库距离函数是否为 Cosine逐一展开讲几个。第一个坑向量模型和场景不匹配。 在企业知识库里很多文档有极强的领域特性——比如医疗、法律、工业制造。通用 Embedding 模型可能在这些领域的语义理解上不够精准导致“相关文本召回率低”。这种情况下建议先搜集领域内几万条句子做微调如果量不够退而求其次在检索前对 query 做改写把口语化的用户问题转换成更贴近文档表述的书面语言。比如用户问“机器坏了找谁”可以检索前改写为“设备故障报修流程”。第二个坑query 与文档风格不一致。 这是企业场景里非常常见的问题。用户提问往往很简短口语化而知识库文档是正式书面语。比如用户问“退货怎么弄”文档里写的是“退换货申请流程”。语义上相关但向量相似度可能不高。解法之一是维护一个“同义表达扩展表”在 query 进入模型前做扩展更工程化的方案是用一个小的 rerank 模型比如 bge-reranker对召回结果做精排让第一轮粗召回的范围可以放宽比如 top-30再由 rerank 挑出真正的 top-5。这个方案在实践中效果明显成本只在线的 rerank 推理可以接受。第三个坑chunk 尺寸和重叠的经验值。 在 bge-m3 这类支持较长输入的模型上有的人喜欢把 chunk 加到 800 字觉得上下文丰富。但实测效果通常不是这样。检索阶段的目标是“定位到包含答案的精确位置”而不是“给模型完整的阅读资料”。太长的 chunk 会让向量落在多个主题的中心位置反而偏离任何一个精确主题。我的经验值是中文文档 200~300 字符重叠 50~80 字符技术文档可以适当加长到 400~500 字符因为单步操作说明往往需要完整上下文。7. 实战避坑指南与进阶扩展方向7.1 生产环境下最容易踩的五个坑这里再集中分享几个生产环境里容易踩的坑都是我自己花过时间总结出来的教训。第一批量向量化的时候batch size 调太大导致 GPU 显存溢出。 这不是单纯的显存问题——如果内存不足一部分进程会开始写 swap整批任务卡死甚至被系统 kill。稳妥做法是先按 16、32、64 三档做小测试观察显存占用率再定最终 batch size。一般 1024 维的模型生成任务8G 显存建议 batch 不超过 64。第二没有做向量维度校验就直接入库。 换模型之后新的输出维度是 1024但 collection 配置的还是 768Qdrant 直接报错。更隐蔽的是同一模型不同版本onnx、fp16、int8 导出输出特征维度可能相同但特征分布有差异混在一起用会拖低检索精度。所以入库之前务必校验维度、记录模型版本号。第三删文档之后没有更新向量库。 知识库是动态的文档更新之后旧版本向量还留在库里。用户检索时系统可能把两个版本的矛盾内容同时召回导致答案前后不一致。建议建立增量更新的调度任务检测文件 hash 变化对变更文档做重切分、重向量化、旧向量替换。这一步虽然不复杂但是能避免生产环境里很多隐蔽的 bug。第四忘了做权限和租户隔离。 在很多企业内部不同部门的知识库文档互相之间不允许访问。如果向量库的 payload 里没有 tenant_id 字段检索时不带过滤条件就会产生数据越权访问风险。哪怕你现在只有一个部门使用也建议从一开始就在 metadata 里带上权限维度字段避免后面数据量大了再改造的代价。第五不加日志和监控。 向量检索链路长任何一个环节出问题都可能导致线上问答异常。建议至少监控这几个指标入库文档量、向量化成功率、平均检索延迟、召回为空的比例、答案不满意率可参考用户反馈打标。这样接到线上客诉时才有数据支持快速定位。7.2 向量检索 Rerank 的进阶实战在 6.2 里提到过 rerank 方案这里展开讲一下因为它是对检索效果提升最显著的一招。Rerank 模型和 Embedding 模型的根本区别在于Embedding 模型需要把文本压缩成固定向量这一步会有信息损失而 rerank 模型直接计算“给定查询与候选文档的相关性得分”可以对整篇文本做精细匹配信息损失更少。所以把粗召回 精排分成两段几乎总能带来召回质量的提升。一个典型的 rerank 流程用户 query 向量化在向量库中召回 top-30 候选。用 rerank 模型例如 bge-reranker-base 或 bge-reranker-v2-m3对 30 个候选重新打分。取精排后 top-3~5 的文本块拼装 Prompt 调用大模型。代码层面最简单的用法from FlagEmbedding import FlagReranker reranker FlagReranker(BAAI/bge-reranker-v2-m3, use_fp16True) query 产品的保修期是多久 candidates [chunk.payload[text] for chunk in top30_results] pairs [[query, cand] for cand in candidates] scores reranker.compute_score(pairs, normalizeTrue) # 按分数降序排列 ranked sorted(zip(top30_results, scores), keylambda x: x[1], reverseTrue) top5 [r[0] for r in ranked[:5]]需要注意rerank 模型的计算量随候选数量线性增长如果召回 30 条一次查询就要做 30 次模型推理。生产环境建议限制粗召回上限在 50 条以内同时用独立的 GPU 部署 rerank 服务避免阻塞主链路。7.3 增量更新、多模态扩展与微调方向系统进入稳定运行期之后有三个方向值得继续投入。第一个方向是增量数据管道建设。 知识库不是一次性导入的每个月都有新文档、修订文档。我建议搭一个简单的轻量管道监控文件目录或者对接企业的文档管理系统文件变化后触发“解析 - 切块 - 向量化 - 入库”的流程。这个管道的核心是记录每个 chunk 的 source 信息和 hash这样更新时只需要处理变化的文件而不是全量重建。第二个方向是多模态扩展。 前面提到的 siglip2 这类模型可以作为多模态问答的技术基座。比如产品手册里大量使用截图说明操作步骤只靠 OCR 会把关键信息丢失引入多模态向量化之后可以直接把截图编码为向量入库。查询“这个报错画面是什么意思”时直接用图像向量做匹配效果提升明显。这个方向在客服工单、设备运维、质检场景都有很大的落地空间。第三个方向是 Embedding 模型的领域微调。 如果离线评估发现通用模型在领域术语和表达习惯上确实有不小的 gap且你积累了一定数量的领域语料可以考虑用领域数据微调 Embedding 模型。常用的训练思路是构造“问答-正例-负例”三元组用 Multiple Negatives Ranking LossMNRL或 InfoNCE 这类对比学习目标做微调。微调后的模型往往能在专业场景里带来几个百分点的召回提升。但是要提醒一点领域微调投入不小需要数据标注、算力和迭代周期。如果现有方案通过 query 改写和 rerank 已经能解决 80% 的问题建议先把这些轻量手段用足再考虑微调。根据我个人的经验Embedding 与向量化这个环节花再多时间都不算多。它和上层大模型之间的配合关系是模型负责“生成”向量库负责“找对”。找错了模型再强也答不对。把这套链路里的每个细节都踏踏实实做扎实你的智能问答系统才真正具备上线运营的底气。后续如果继续深入可以考虑把向量检索、rerank 和 LLM 生成三层做更紧密的联动和自动化调参但那是另一个话题了。 智能问答系统实战：Embedding与向量化全流程详解
写好一个企业级的智能问答系统Embedding 和向量化这一环往往决定了整个系统的上限。很多人最开始搭 RAG 问答的时候习惯把注意力放在模型选型和 Prompt 设计上结果上线以后才发现文档切得稀碎、检索召回一堆不相关片段、答非所问最后还得回来折腾向量化这块。这一章专门把 Embedding 与向量化实战拆开揉碎讲一遍。我会从最朴素的原理说起讲清楚企业和个人在搭建智能问答系统时应该如何选择 Embedding 模型、如何设计向量化流程、如何在召回质量和工程成本之间做取舍最后附上可以直接抄走的落地代码和踩坑记录。不管你是刚入门想做一个人知识库问答机器人还是公司里要接一套正式的智能问答基础设施这一章的内容都能直接参考。1. 内容整体设计与思路拆解1.1 为什么向量化是智能问答系统的“地基”智能问答系统的核心链路简单来说就四步文档解析、文本切块、向量化、召回应答。嵌入向量Embedding做的事情是把自然语言转换成一串浮点数。这串数字在向量空间中表示文本的“语义坐标”——语义相近的文本坐标上距离就近语义无关的文本坐标上就离得远。这套思路之所以能跑通是因为现代语言模型LM在预训练阶段已经学到了大量语言规律与知识。Embedding 模型则是把这种语义理解能力压缩成稠密向量。比如“今天上海天气怎么样”和“上海今日气温”两句话表面词完全不同但语义相近经过一个优秀的 Embedding 模型编码后它们的余弦相似度会明显高于与“今天股票涨了”这类无关句子的相似度。在实际项目中向量化环节为两个下游模块服务第一离线建库阶段把知识库文档向量化之后写入向量数据库构建索引第二在线问答阶段把用户问题向量化在库里做相似度检索召回 top-k 候选片段。可以说向量化的质量直接决定检索质量而检索质量又直接决定问答系统的准确性。在真实的问答系统测试里我发现相当一部分“模型回答得不好”的问题根子其实在检索阶段就错了——相关片段根本没被召回给到大模型的上下文就是残缺的。所以Embedding 与向量化的定位是整个系统的地基工程。这块地基没打好后续的模型调优、Prompt 优化都只是表面功夫。1.2 构建这一章的三个核心思路在开始动手之前我先梳理了三条贯穿全程的思路这也是我这一章内容设计的骨架。第一条思路用教训驱动原理。 我不会一上来就堆公式而是从实际业务问题出发。比如“为什么长文档直接丢进模型效果很差”——引导我们发现切块的必要性“为什么同一个模型在中文场景下时而好用时而离谱”——引导我们理解训练语料与模型场景匹配的重要性。每一个技术点都对应一个实际痛点这样理解起来才不会飘。第二条思路限制条件下的工程选型。 企业级应用和实验室玩具最大的区别在于约束条件。实验室可以随便选个开源模型跑一跑企业级要考虑推理成本、响应延迟、并发量、运维复杂度、数据隐私、合规要求。所以在模型选型、向量数据库选型、索引配置上每一步都要展开“为什么这么选”的权衡过程。第三条思路全链路可复现、可度量。 只会在 Notebook 里跑通 demo 没有意义真正的工程化至少要满足三点代码可重复执行数据可追踪哪些文档入库了、什么版本效果可量化召回率、命中率、端到端准确率。这一章每个实操环节都会朝这个方向靠拢给出一套可复现的流程。2. Embedding 模型选型与新趋势2.1 主流 Embedding 模型对比与选型逻辑进入模型选型环节先看一组当前技术社区里讨论热度比较高的模型覆盖闭源 API 和开源本地部署两条路线。这张表的数据是我在多个真实场景下的综合体验评估具体数值会因测试集不同有浮动但可以反映大方向模型维度语言侧重最大输入长度部署方式适用场景text-embedding-3-small1536/512多语言8191 tokensAPISaaS 快速验证text-embedding-3-large3072/1024多语言8191 tokensAPI对精度要求高的场景bge-m31024中英多语8192 tokens开源/本地中文为主的企业私有化部署bge-large-zh-v1.51024中文512 tokens开源/本地中文检索、句子相似度m3e-base768中英2048 tokens开源/本地中文语义匹配siglip21152图文图像/文本开源/本地图文多模态问答先说 API 路线。OpenAI 的 text-embedding-3 系列最大的优势是省事、稳定、语义能力强documents 和 query 都直接调接口就行。企业如果想要两三天内做出一个可用的问答系统可以先用它跑通流程。代价是数据要出网并且每次调用都有费用。如果公司有严格的数据安全要求这条路线直接跳过。开源路线里bge 系列BAAI General Embedding是我在中文场景里用得最多的。bge-m3 是第三代多语言模型同时支持稠密检索、稀疏检索和多向量检索。它的训练数据覆盖了中英等多种语言最大长度到 8k非常适合中文企业知识库场景。它最让我满意的是不需要像第一代 bge 那样给 query 加“为这个句子生成表示以用于检索相关文章”这种指令前缀减少了很多不必要的麻烦。m3e-base 则是更轻量级的选择768 维、2.04 亿参数CPU 上也能跑。如果文档量不大、只需要简单的中文语义匹配它的性价比很高。这里多说一句不是维度越大越好。 维度越高单条向量的存储空间越大在相同内存下能支撑的向量数量就越少检索耗时也会增加。1536 维和 1024 维之间每百万条向量的存储差异大约 0.5-1GB对生产环境的成本有明显影响。维度选择要和业务数据量、硬件资源一起综合考虑。2.2 多模态与推理型向量模型的新趋势最近技术社区里“siglip2 向量化”的热度上升很快。SIGLIP 系列是“基于 Sigmoid Loss 的图像-语言预训练”模型SIGLIP2 进一步增强了图文联合嵌入能力。它输出的视觉与文本嵌入在同一个向量空间可以直接用文本向量去检索图像也可以用图像向量匹配文本描述。这个能力在很多企业场景里价值很大。比如企业内部的知识工单里经常同时包含截图和文字描述传统的方案是把图片先 OCR 转文本再做文本检索信息损耗很大用 siglip2 这种多模态向量模型可以把图片直接编码成向量和文字信息放在同一个库里统一检索。另外一个值得关注的趋势是“推理增强的 Embedding”。以前我们觉得嵌入模型是静态的——给定一段文本输出一个固定的向量不考虑下游任务。但新一代模型开始引入推理能力可以通过自然语言描述检索意图、忽略掉文本里不相关的部分、甚至对文本做二次润色。这个方向的代表有 Qwen3-Embedding 等新一代模型。它在检索问答里带来的变化是用户问“这个东西怎么维修”系统不是简单做关键词匹配而是理解“维修”这个核心意图后在文档里定位真正和维修步骤有关的那段内容。2.3 模型选型避坑经验我踩过最深的坑是换模型之后向量库全部要重建。 这不是开玩笑。不同模型的向量空间完全不同维度也不一样理论上讲A 模型生成的向量和 B 模型的向量直接计算相似度没有任何意义。生产环境一旦要升级 Embedding 模型意味着离线索引全部重新算一遍。如果知识库有几千万条文本这个重建成本是相当惊人的。所以选型的时候一定要想清楚未来规模化增长路径宁可初期稍微多花一点成本选一个长期够用、社区活跃的模型。另外无论选什么模型都建议在项目早期就固定一条“模型版本管理向量版本管理”的规则。比如模型文件保存到专门的对象存储路径下向量数据集在库里带上版本号字段。这样即便后续要重建也能清楚知道哪批向量对应哪个模型版本不至于混在一起导致检索混乱。3. 向量化实战核心技术环节拆解3.1 文本清洗与切块策略拿到原始文档之后第一件事从来不是直接向量化而是清洗。常见来源的文档比如 Word、PDF、Markdown、扫描件转出的文本往往会带着各种噪声多余换行、页眉页脚、乱码、表格错位、引用编号、无意义符号。这些噪声如果不处理进到 Embedding 里的就是脏数据直接影响检索精度。这里分享一套我反复验证过的清洗流程统一字符编码转成 UTF-8剔除无法解析的控制字符。把全角标点转半角数字和英文字母统一格式。去掉文档中重复出现的页眉页脚。可以用规则匹配比如“第 X 页共 Y 页”对 OCR 出来的文本做简单的纠错和粘连修复。最后用正则把连续 3 个以上的换行压缩成 1 个方便后续切块。清洗完成之后才是切块。切块这一步看似简单其实是最影响检索效果的因素之一。切得太短单块缺乏足够上下文语义不完整切得太长一块里包含多个知识点向量被平均拉偏检索精确度下降。我常用的切块基线策略如下固定最大长度 200~300 个字符中文场景按字符数或者 250~350 个 token英文场景按 token 数带 50~80 个字符的重叠。优先按 Markdown 标题#、##和段落边界切。如果是在段落中间截断要把截断位置回退到最近的句号、问号、感叹号。对结构化文档比如操作手册、FAQ、规格书可以用父子分块策略Parent-Child Chunking把大块作为“父块”放进检索候选把更小的子块向量化用于精确匹配。召回时先找到子块再映射回父块作为上下文喂给大模型。这样既保证语义完整又提升精确度。还有几种进阶策略比如基于语义切分通过句子向量判断语义边界、基于文档结构的递归切分这些在 LangChain 这类框架里都有实现但并不意味着“框架自带的一定好”——生产环境里我反而发现纯规则切分往往最可控、最好排查问题。不要一上来就迷信高级方案先把规则切分的效果跑出来再决定要不要上更复杂的策略。3.2 Embedding 批量向量化与数据格式设计文本处理完之后进入向量化环节。实际生产过程中我们很少逐条调用模型基本都是批量处理。批量处理时有两个字段必须想清楚一个是 chunk_id 或者 doc_chunk_id——它是区块的唯一标识另一个是 metadata——用来记录文档来源、标题、页码、章节路径、入库时间、向量模型版本等信息。metadata 非常重要我单独强调一下。原因有两个。第一向量数据库支持 metadata 过滤常见的“只看某个产品线的文档”“只检索最近半年发布的文档”等功能都必须依赖 metadata 过滤实现第二问答系统上线以后需要做效果分析和排查如果你不知道一条被召回的内容来自哪个文档就无法定位问题出在文档本身还是切块策略上。向量化对象应该同时包括文本内容本身和 metadata 信息。有些实现方式会把“标题 章节路径 正文片段”拼接后一起编码让最终的向量携带更多位置信息。在 bge-m3 这类模型下我实测过这个方法的收益对长文档的定位检索准确率有一定提升特别是当正文中出现代词、省略语时标题补全语义的作用非常明显。下面给一个批量向量化的最小参考实现以 bge-m3 FlagEmbedding 为例from FlagEmbedding import BGEM3FlagModel import numpy as np import json # 加载本地模型设备可以指定 cuda:0 或 cpu model BGEM3FlagModel(BAAI/bge-m3, use_fp16True) def embed_texts(texts: list[str], batch_size: int 32) - np.ndarray: 批量向量化输入文本列表返回稠密向量矩阵。 这里只使用 dense 向量忽略 sparse 和 colbert 向量。 all_vectors [] for i in range(0, len(texts), batch_size): batch texts[i : i batch_size] output model.encode(batch, max_length2048)[dense_vecs] all_vectors.append(output) print(fprocessed {min(i batch_size, len(texts))}/{len(texts)}) return np.vstack(all_vectors) # 读取清洗后的切片文本 with open(cleaned_chunks.json, r, encodingutf-8) as f: chunks json.load(f) # 每个元素是 {chunk_id: str, text: str, metadata: dict} texts [c[text] for c in chunks] vectors embed_texts(texts, batch_size64) # 将向量和 metadata 写到磁盘方便后续导入向量数据库 with open(chunk_vectors.npy, wb) as f: np.save(f, vectors)这段代码是完整的离线向量化流程把切好的文本块批量喂给模型拿到向量之后保存成 .npy 文件。实际生产环境里这段代码会包在任务调度系统里跑完一步记录一步状态。批大小建议从 32 或者 64 开始如果你的 GPU 显存有限一次 batch 太大很容易 OOM——这个问题放在后面“常见问题”里细说。3.3 相似度计算与归一化细节向量化产出之后所有下游工作都是围绕“相似度计算”展开的。最常见的两种度量余弦相似度和内积。余弦相似度公式是cos(A, B) (A·B) / (|A| × |B|)。它度量的是两个向量的方向一致性不受向量模长影响。对文本语义匹配来说方向一致就意味着语义相近。而内积则同时考虑方向和模长。在 Embedding 模型默认不归一化的情况下不同长度文本的向量模长会有差异内积结果会偏向长文本所以一般推荐用余弦相似度。不过这里有一个工程上的细节如果对向量做 L2 归一化那么余弦相似度和内积在数值上是完全等价的。很多向量数据库比如 Qdrant、Milvus在构建索引时内部都会做归一化然后在查询时直接算内积加速计算。所以如果使用这类数据库你需要明确知道它的相似度配置是“Cosine”还是“Dot”。如果模型输出的向量没有归一化而数据库端又选了 Dot召回结果会出现偏差。我建议你养成一个习惯在向量入库前做一次显式 L2 归一化并且保留归一化后的向量。这样做有三个好处第一相似度计算语义明确第二后续如果换用内积加速方案不会踩坑第三部分数据库对向量做归一化后配合量化压缩存储成本可以显著下降。4. 向量数据库选型与索引配置4.1 主流向量数据库与场景匹配向量化之后的数据需要一个专门的地方来存储和检索。过去我们可能直接用 Elasticsearch 的 dense_vector 字段或者用关系型数据库的 pgvector 插件但这些方案各有优劣。我把几个主流选项放在一起对比数据库部署方式索引方式适用规模优点注意点QdrantDocker/分布式HNSW亿万级以下轻量、API 简洁、过滤能力强分布式需要单独部署MilvusK8s/分布式HNSW/IVF亿万级功能全、生态好架构较重运维成本高pgvectorPostgreSQL 插件HNSW/IVF千万级以下复用现有 PG 设施高并发检索性能受限Elasticsearch集群HNSW亿级全文检索向量混合配置复杂成本高FAISS嵌入式库HNSW/IVF/PQ内存级性能极致灵活无服务化能力适合研究选择建议很直接中小团队、希望上手快、要控制运维成本用 Qdrant数据量到了亿级、公司已经有 K8s 运维能力选 Milvus业务里已经在重度用 PostgreSQL、不想多维护一套存储系统那 pgvector 是合理的轻量选择如果要同时做关键词检索和向量检索并且预算充足Elasticsearch 可以一套搞定。我在实际项目里用得最多的是 Qdrant它的 metadata payload 支持很灵活检索时可以先按 payload 过滤再搜索返回结果的 score 默认就是余弦相似度方便判断质量。4.2 HNSW 索引参数配置经验分享向量数据库的检索性能很大程度上取决于索引参数的配置。HNSWHierarchical Navigable Small World是目前最常用的 ANNApproximate Nearest Neighbor索引算法它的基本思想是构建一个多层图结构检索时从顶层开始快速向下跳转找到近似最近邻。HNSW 有三个关键参数M每个节点的最大连接数。M 越大图越稠密召回率越高但内存占用和索引时间也增加。推荐范围 16~64。ef_construction建索引时动态候选列表大小。它控制索引质量值越大索引越精确但建库时间越长。推荐 100~200。ef_search查询时的搜索范围。这个参数直接影响查询召回率。实际生产中可以先设成 ef_search 100 左右观察召回质量再逐步加大。这三者的关系可以用一个生活例子帮助理解好比你要在一个大型商场里找人M 决定你最多能找多少位朋友帮你打听ef_construction 决定你打听到的候选人数ef_search 则是你真正愿意逐一询问的人数。三个值配合好才既能找到人又不用跑遍整个商场。从实践看我会推荐这样一组起点配置索引配置: M: 16 ef_construction: 128 ef_search: 128 distance: Cosine对于千万级数据量、单机内存 32G 以上的场景这组配置通常能保证召回率在 95% 以上同时单次查询延迟控制在几十毫秒。如果你的数据量更大可以考虑开启向量量化Scalar Quantization 或 Product Quantization但要注意量化会带来少量精度损失——我用过 PQ 后召回率下降大约 1~2 个百分点接受度取决于业务场景。5. 从零到一的完整实操建立第一个可检索的产品问答知识库5.1 搭建环境与准备样例数据前面铺垫了这么多现在进入实战环节。我们这次的目标是把一批 Markdown 格式的产品操作手册构建成可检索的知识库并实现一问一答的原型验证。技术栈选择如下Embedding 模型BAAI/bge-m3本地部署满足数据不出内网的要求向量数据库QdrantDocker 启动简单快速文本切块自研规则切块按标题和段落边界LLM 应答层调用内部大模型服务如果你本机还没有环境先把基础环境准备好# 创建项目目录 mkdir qa-system-demo cd qa-system-demo # 启动 Qdrant 容器 docker run -p 6333:6333 -p 6334:6334 -v $(pwd)/qdrant_storage:/qdrant/storage qdrant/qdrant # 验证服务运行 curl http://localhost:6333/collections # 预期返回 {result:{collections:[]}}然后准备样例数据。假设有一批 Markdown 文档例如product_manual.md内容是产品安装说明、故障排查等。我们要把它转成可供检索的文本块。5.2 文档解析与切块的完整代码先写一个通用的 Markdown 解析切块逻辑。核心思路按标题层级切出大纲结构保留标题信息在章节内部再按段落切块。import re import json def split_markdown_by_heading(md_text: str): 把 Markdown 按标题层级切块同时保留章节路径。 返回的每个 chunk 包含chunk_id, text, metadata. lines md_text.split(\n) chunks [] current_heading_path [] # 保存多级标题路径 current_lines [] chunk_index 0 heading_pattern re.compile(r^(#{1,4})\s(.*)$) def flush(): nonlocal current_lines, chunk_index if not current_lines: return content \n.join(current_lines).strip() if content: title / .join(current_heading_path) if current_heading_path else full_text f{title}\n{content} if title else content metadata { title: title, chunk_index: chunk_index, source: document_name, } chunks.append({ chunk_id: f{document_name}-{chunk_index}, text: full_text, metadata: metadata, }) chunk_index 1 current_lines [] for line in lines: match heading_pattern.match(line) if match: flush() level len(match.group(1)) heading_text match.group(2).strip() # 多级标题路径截断到当前层级 current_heading_path current_heading_path[: level - 1] [heading_text] else: current_lines.append(line) flush() return chunks这里有一个设计细节值得解释为什么在切块时把标题拼进正文因为很多操作手册里的正文段落经常出现“它”“该功能”这类代词如果没有标题信息单独看正文完全不知道在说哪个模块。把“产品安装指南 / 软件安装步骤”这样的标题拼在正文前能显著提升向量检索时命中的准确性。再看一个段落内切块的补充逻辑如果段落本身超过最大长度限制按句子边界截断并把截断点对齐到标点符号def split_long_paragraph(text: str, max_chars: int 250, overlap: int 50): 将一个过长的段落按句子边界切成多个短块块之间带 overlap。 sentences re.split(r(?[。.!?]), text) chunks [] current_chunk for sent in sentences: if not sent: continue if len(current_chunk) len(sent) max_chars: current_chunk sent else: if current_chunk: chunks.append(current_chunk) # 保留上一句末尾的部分字符作为 overlap if len(current_chunk) overlap: current_chunk current_chunk[-overlap:] sent else: current_chunk sent if current_chunk: chunks.append(current_chunk) return chunks这套切块逻辑在我的项目里迭代过很多次说结论对企业知识库常见的 Markdown 文档标题层级切分段落内按句子切分已经能覆盖 80% 场景。不要一开始就引入复杂的语义切分模型规则简单、结果可控这才是生产系统的正确做法。5.3 向量化入库与查询验证切块完成后就可以做向量化入库。下面的代码把上一步输出的 chunks 批量向量化并写入 Qdrant。先安装依赖pip install qdrant-client FlagEmbedding numpy然后写入库脚本from qdrant_client import QdrantClient from qdrant_client.models import Distance, VectorParams, PointStruct from FlagEmbedding import BGEM3FlagModel import numpy as np import json # 连接 Qdrant client QdrantClient(hostlocalhost, port6333) # 创建 collection维度必须和模型输出一致bge-m3 稠密向量为 1024 维 collection_name product_kb vectors_config VectorParams(size1024, distanceDistance.COSINE) client.recreate_collection( collection_namecollection_name, vectors_configvectors_config, ) # 加载 Embedding 模型 model BGEM3FlagModel(BAAI/bge-m3, use_fp16True) # 读取切块 with open(chunks.json, r, encodingutf-8) as f: chunks json.load(f) points [] batch_size 64 for start in range(0, len(chunks), batch_size): batch chunks[start : start batch_size] texts [c[text] for c in batch] embeddings model.encode(texts)[dense_vecs] for i, emb in enumerate(embeddings): # 显式做 L2 归一化 norm np.linalg.norm(emb) emb_normalized (emb / norm).tolist() point PointStruct( idstart i, vectoremb_normalized, payload{text: batch[i][text], **batch[i][metadata]}, ) points.append(point) # 批量写入 client.upsert( collection_namecollection_name, pointspoints, batch_size64, ) print(ftotal upserted: {len(points)})入库之后来做一次查询验证模拟线上问答环境test_query 产品的保修期是多久 query_vec model.encode([test_query])[dense_vecs][0] norm np.linalg.norm(query_vec) query_vec_normalized (query_vec / norm).tolist() results client.search( collection_namecollection_name, query_vectorquery_vec_normalized, limit5, ) for res in results: print(fscore{res.score:.4f}) print(res.payload[text][:150]) print(---)这一步如果走通你就拥有了一个最小可用的向量检索问答底层。它虽然还是一个原型但是架构上已经具备生产系统的雏形文档可增量更新、检索可实现 metadata 过滤、向量可版本管理。5.4 结合大模型的问答链路向量检索只是整个问答系统的前半段。要让用户得到自然的答案还需要把检索到的 top-k 文本块拼装成上下文交给大模型生成回答。在设计上下文拼装时有几点经验值得分享top-k 不要贪多。 一般取 3~5 个文本块就够了。取太多会把不相关的噪声引入上下文反而降低生成质量还会成倍增加 token 消耗和响应延迟。在上下文里显式标注来源。 比如“[来自文档产品操作指南章节故障排查-电源问题]”这样大模型回答时可以结合来源措辞用户也能追溯到答案出处。召回分数可以作为“置信度”参考。 如果最高分超过 0.7回答可信度较高如果最高分低于 0.5建议让模型直接说“抱歉没有找到足够相关的信息”而不是强行编造。下面是一个简化的组装 Prompt 的示例def build_prompt(query: str, retrieved_chunks: list) - str: context_parts [] for idx, chunk in enumerate(retrieved_chunks): source chunk.payload.get(title, 未知来源) context_parts.append(f[{idx 1}] 来源{source}\n{chunk.payload[text]}) context \n\n.join(context_parts) prompt f你是一个企业知识库问答助手。请基于提供的参考片段回答用户问题。 如果参考片段中不包含答案请直接说明。回答时尽量引用来源。 参考片段 {context} 用户问题{query} 请回答 return prompt到这一步一个“文档进来答案出去”的完整问答链路就搭好了。这段链路看似简单但在真实项目里每一个环节都值得打磨——现在你已经具备了一个可以不断优化的基线。6. 问答系统效果评估与调优6.1 离线评估构建测试集与指标计算问答系统搭完之后最重要的事情不是继续加功能而是建立评估体系。没有评估就没有优化方向。我建议所有项目都做一套离线检索评估集。做法是从知识库里抽取 100~200 个真实用户问题每个问题标记 1~3 个标准答案对应的文档块 ID。然后批量跑检索计算两个常见指标Hit Rate命中率标准答案块是否出现在召回的前 K 个结果中。这是最直观的指标。MRRMean Reciprocal Rank标准答案块在排序中越靠前得分越高。计算方法是 1/rank取所有问题的平均。举个例子假设一个问题有 3 个标准文档块召回 top-5 结果里命中了其中 1 个块排在第二位那这个问题的 MRR 贡献是 1/2 0.5如果完全没命中MRR 为 0。Hit Rate 则相对宽松只要命中就算成功。下面给一个简单的评估脚本骨架def evaluate_retrieval(qa_pairs, retrieved_fn, k5): hit_count 0 mrr_sum 0.0 for item in qa_pairs: query item[query] gold_ids set(item[gold_ids]) hits retrieved_fn(query, kk) hit_list [h.chunk_id for h in hits] if gold_ids set(hit_list): hit_count 1 # MRR 计算 for rank, h in enumerate(hit_list, start1): if h in gold_ids: mrr_sum 1.0 / rank break return hit_count / len(qa_pairs), mrr_sum / len(qa_pairs)我用这套方法在很多项目里做过调优最有价值的发现是在很多所谓“效果不好”的问题里不是模型能力不行而是测试者根本没有建立评估集全靠主观感受调 Prompt。有了离线评估指标你每次改动切块参数、换模型、调索引时都能立刻看到数字变化而不是玄学调参。6.2 常见问题排查与调优路径在大量问答项目的调试过程中我把高频问题和对应排查方向整理成了一个速查表问题现象可能原因排查方向召回结果完全不相关向量化模型与应用场景不匹配或者 query 与文档语言/风格差异过大换模型并在小样本上做召回对比召回结果相关但排序靠后chunk 切得太大信息被稀释或者 query 和文档表述方式差异大缩小 chunk 尺寸增加重叠引入 query 改写特定领域术语检索不到领域词汇在模型词表中语义覆盖不足引入同义词扩展或微调 Embedding 模型某些文档完全不被召回清洗时文档内容被误删或者 metadata 过滤条件错误检查入库日志验证向量库中该文档是否存在检索速度慢索引参数不合理、内存不够、未使用量化增大 ef_search 试试但更优先检查 M 和 ef_construction检索结果被长文本块占据归一化或距离度量配置出了问题检查向量是否做了 L2 归一化数据库距离函数是否为 Cosine逐一展开讲几个。第一个坑向量模型和场景不匹配。 在企业知识库里很多文档有极强的领域特性——比如医疗、法律、工业制造。通用 Embedding 模型可能在这些领域的语义理解上不够精准导致“相关文本召回率低”。这种情况下建议先搜集领域内几万条句子做微调如果量不够退而求其次在检索前对 query 做改写把口语化的用户问题转换成更贴近文档表述的书面语言。比如用户问“机器坏了找谁”可以检索前改写为“设备故障报修流程”。第二个坑query 与文档风格不一致。 这是企业场景里非常常见的问题。用户提问往往很简短口语化而知识库文档是正式书面语。比如用户问“退货怎么弄”文档里写的是“退换货申请流程”。语义上相关但向量相似度可能不高。解法之一是维护一个“同义表达扩展表”在 query 进入模型前做扩展更工程化的方案是用一个小的 rerank 模型比如 bge-reranker对召回结果做精排让第一轮粗召回的范围可以放宽比如 top-30再由 rerank 挑出真正的 top-5。这个方案在实践中效果明显成本只在线的 rerank 推理可以接受。第三个坑chunk 尺寸和重叠的经验值。 在 bge-m3 这类支持较长输入的模型上有的人喜欢把 chunk 加到 800 字觉得上下文丰富。但实测效果通常不是这样。检索阶段的目标是“定位到包含答案的精确位置”而不是“给模型完整的阅读资料”。太长的 chunk 会让向量落在多个主题的中心位置反而偏离任何一个精确主题。我的经验值是中文文档 200~300 字符重叠 50~80 字符技术文档可以适当加长到 400~500 字符因为单步操作说明往往需要完整上下文。7. 实战避坑指南与进阶扩展方向7.1 生产环境下最容易踩的五个坑这里再集中分享几个生产环境里容易踩的坑都是我自己花过时间总结出来的教训。第一批量向量化的时候batch size 调太大导致 GPU 显存溢出。 这不是单纯的显存问题——如果内存不足一部分进程会开始写 swap整批任务卡死甚至被系统 kill。稳妥做法是先按 16、32、64 三档做小测试观察显存占用率再定最终 batch size。一般 1024 维的模型生成任务8G 显存建议 batch 不超过 64。第二没有做向量维度校验就直接入库。 换模型之后新的输出维度是 1024但 collection 配置的还是 768Qdrant 直接报错。更隐蔽的是同一模型不同版本onnx、fp16、int8 导出输出特征维度可能相同但特征分布有差异混在一起用会拖低检索精度。所以入库之前务必校验维度、记录模型版本号。第三删文档之后没有更新向量库。 知识库是动态的文档更新之后旧版本向量还留在库里。用户检索时系统可能把两个版本的矛盾内容同时召回导致答案前后不一致。建议建立增量更新的调度任务检测文件 hash 变化对变更文档做重切分、重向量化、旧向量替换。这一步虽然不复杂但是能避免生产环境里很多隐蔽的 bug。第四忘了做权限和租户隔离。 在很多企业内部不同部门的知识库文档互相之间不允许访问。如果向量库的 payload 里没有 tenant_id 字段检索时不带过滤条件就会产生数据越权访问风险。哪怕你现在只有一个部门使用也建议从一开始就在 metadata 里带上权限维度字段避免后面数据量大了再改造的代价。第五不加日志和监控。 向量检索链路长任何一个环节出问题都可能导致线上问答异常。建议至少监控这几个指标入库文档量、向量化成功率、平均检索延迟、召回为空的比例、答案不满意率可参考用户反馈打标。这样接到线上客诉时才有数据支持快速定位。7.2 向量检索 Rerank 的进阶实战在 6.2 里提到过 rerank 方案这里展开讲一下因为它是对检索效果提升最显著的一招。Rerank 模型和 Embedding 模型的根本区别在于Embedding 模型需要把文本压缩成固定向量这一步会有信息损失而 rerank 模型直接计算“给定查询与候选文档的相关性得分”可以对整篇文本做精细匹配信息损失更少。所以把粗召回 精排分成两段几乎总能带来召回质量的提升。一个典型的 rerank 流程用户 query 向量化在向量库中召回 top-30 候选。用 rerank 模型例如 bge-reranker-base 或 bge-reranker-v2-m3对 30 个候选重新打分。取精排后 top-3~5 的文本块拼装 Prompt 调用大模型。代码层面最简单的用法from FlagEmbedding import FlagReranker reranker FlagReranker(BAAI/bge-reranker-v2-m3, use_fp16True) query 产品的保修期是多久 candidates [chunk.payload[text] for chunk in top30_results] pairs [[query, cand] for cand in candidates] scores reranker.compute_score(pairs, normalizeTrue) # 按分数降序排列 ranked sorted(zip(top30_results, scores), keylambda x: x[1], reverseTrue) top5 [r[0] for r in ranked[:5]]需要注意rerank 模型的计算量随候选数量线性增长如果召回 30 条一次查询就要做 30 次模型推理。生产环境建议限制粗召回上限在 50 条以内同时用独立的 GPU 部署 rerank 服务避免阻塞主链路。7.3 增量更新、多模态扩展与微调方向系统进入稳定运行期之后有三个方向值得继续投入。第一个方向是增量数据管道建设。 知识库不是一次性导入的每个月都有新文档、修订文档。我建议搭一个简单的轻量管道监控文件目录或者对接企业的文档管理系统文件变化后触发“解析 - 切块 - 向量化 - 入库”的流程。这个管道的核心是记录每个 chunk 的 source 信息和 hash这样更新时只需要处理变化的文件而不是全量重建。第二个方向是多模态扩展。 前面提到的 siglip2 这类模型可以作为多模态问答的技术基座。比如产品手册里大量使用截图说明操作步骤只靠 OCR 会把关键信息丢失引入多模态向量化之后可以直接把截图编码为向量入库。查询“这个报错画面是什么意思”时直接用图像向量做匹配效果提升明显。这个方向在客服工单、设备运维、质检场景都有很大的落地空间。第三个方向是 Embedding 模型的领域微调。 如果离线评估发现通用模型在领域术语和表达习惯上确实有不小的 gap且你积累了一定数量的领域语料可以考虑用领域数据微调 Embedding 模型。常用的训练思路是构造“问答-正例-负例”三元组用 Multiple Negatives Ranking LossMNRL或 InfoNCE 这类对比学习目标做微调。微调后的模型往往能在专业场景里带来几个百分点的召回提升。但是要提醒一点领域微调投入不小需要数据标注、算力和迭代周期。如果现有方案通过 query 改写和 rerank 已经能解决 80% 的问题建议先把这些轻量手段用足再考虑微调。根据我个人的经验Embedding 与向量化这个环节花再多时间都不算多。它和上层大模型之间的配合关系是模型负责“生成”向量库负责“找对”。找错了模型再强也答不对。把这套链路里的每个细节都踏踏实实做扎实你的智能问答系统才真正具备上线运营的底气。后续如果继续深入可以考虑把向量检索、rerank 和 LLM 生成三层做更紧密的联动和自动化调参但那是另一个话题了。