简介：面向希望借助大模型与向量检索技术构建企业知识管理系统的开发者，这份PDF以DeepSeek与向量数据库为主线，系统梳理了从基础原理到落地实现的完整链路。文档覆盖DeepSeek技术概述、向量数据库核心概念与Faiss/Milvus/Pinecone对比、企业知识大脑的总体架构设计、多源数据清洗与特征提取、向量数据库选型与配置、系统实现代码示例、性能优化与监控策略，并给出金融、科技、制造三类企业的应用案例，便于读者结合实际场景参考。资源为22页完整PDF，压缩包内共1个文件，大小仅1.68MB，内容排版清晰，目录、图表均显示正常，可直接查阅。已有360人浏览学习。通过学习，读者能够掌握企业多源数据向量化、相似度检索、知识推荐等关键方法，并借鉴现有架构与代码快速搭建原型系统。文档内容简洁但不乏深度，适合初中级开发者系统学习，也可作为企业技术选型时的快速参考。
1. 不建知识库，大模型在企业里就是“高学历实习生”
把 DeepSeek 接进企业微信或内部系统，问它“上季度华东区退货率最高的 SKU 是什么”，它答不上来——这不是模型笨，而是它没见过你的订单表、质检报告和售后工单。企业知识大脑的本质，是大模型负责“理解和表达”，向量数据库负责“记忆和召回”：先把你散落在 PDF、Word、表格、网页里的业务文档切成片段、转成向量存进向量库，用户提问时先检索出最相关的几段，再连同问题一起丢给 DeepSeek 生成答案。这样模型每次回答都有据可依，而且回答里能带出处。
这套方案适合谁？手里有私有文档、想搭内部问答/客服助手/合规审查工具，又不想把数据交给外部 SaaS 的团队。它解决的不只是“搜得到”，更是“答得准”——从关键词命中升级到语义匹配，员工用大白话提问也能命中专业内容。接下来我按自己落地的路径，从模型接入、向量库选型、文档入库讲到避坑和调优，全程给可复现代码。
2. 先把模型接进来：DeepSeek API 与本地部署的取舍
2.1 知识库的完整链路：为什么需要“模型 + 向量库”两件套
很多第一次做知识库的团队会问：DeepSeek 不是能聊天吗，直接把文档塞进上下文不就行了？在 20 份文档以内确实可以，但企业知识库动辄上千份文档、几千万字，你做不到每次提问都把全文塞给模型。更关键的是，大模型的上下文窗口有上限，塞进去的内容超过一定长度后，中间部分会被截断，回答质量直线下降。业界通行的做法是 RAG（检索增强生成），链路拆开看一共五步：文档解析、文本切片、向量化、相似度检索、生成回答。前四步的产出物是“给模型看的参考资料”，最后一步才是 DeepSeek 发挥推理能力的地方。
这里的核心认知是：DeepSeek 是生成模型，不是检索模型。它擅长根据给定的资料组织答案，但不擅长从海量文档里定位“哪一段和问题相关”。定位这件事交给向量数据库做——先把文档切成几百字的小块，每个块用 embedding 模型转成一个高维向量，用户提问时也转成向量，向量库算余弦相似度，返回最相近的几个块。这套架构里，embedding 模型和向量库的选型比大模型本身更影响最终效果。我的经验是：模型选型决定了回答的“上限”，检索质量决定了实际效果的“下限”。
2.2 用 OpenAI 兼容接口接入 DeepSeek：20 行代码把对话跑通
DeepSeek 提供了 OpenAI 兼容的 API，这意味着你不需要引入额外的 SDK，直接用openai库把base_url指过去就能调。先装依赖：
pip install openai==1.40.0接着写一个最简调用函数：
from openai import OpenAI client = OpenAI( api_key="sk-你的key", base_url="https://api.deepseek.com" ) def ask_deepseek(system_prompt: str, user_content: str) -> str: resp = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_content} ], temperature=0.1, max_tokens=2048, top_p=0.9 ) return resp.choices[0].message.content这段代码里值得关注的是temperature=0.1。知识库问答要求答案忠于检索到的资料，温度设得越低，模型越保守、越少自由发挥；如果做头脑风暴类的场景才调到 0.7 以上。max_tokens控制单次回答的最大长度，2000 左右对大多数业务问答够用，Legal/技术文档的详细解读场景可以放宽到 4096。system_prompt是引导模型行为的核心位置，我会在后面的章节给出一个生产级的提示词模板。
2.3 本地部署 DeepSeek：Ollama 与 vLLM 两种启动方式
API 调用适合数据可以出网的场景，但很多制造业、金融企业要求数据不出内网，那就得本地部署。最省事的方案是用 Ollama，一条命令拉起服务：
ollama pull deepseek-r1:14b ollama run deepseek-r1:14bOllama 启动后默认监听localhost:11434，它也提供 OpenAI 兼容的接口，代码里把base_url改成http://localhost:11434/v1即可。14b是参数量，对应 14B 模型；显存 16GB 以下的机器建议用 7b，32GB 以上可以跑 14b 或 32b。注意 Ollama 适合开发和单机验证，它不提供多机分布式推理，QPS 上来后会排队。
对吞吐有要求的团队，我会推荐 vLLM。它做连续批处理和显存管理，单张 A100 上跑 DeepSeek 的推理吞吐比原生实现高 3 到 5 倍。启动方式：
vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-14B \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --port 8000--tensor-parallel-size是张量并行度，一张卡设 1，多卡按卡数往上加；--max-model-len控制最大上下文长度。vLLM 启动后同样提供 OpenAI 兼容接口。这里我给一条血泪经验：本地部署请预留至少 20% 的显存余量，否则并发一上来就 OOM，服务直接挂掉。
2.4 Embedding 模型不能省：为什么不用 DeepSeek 自己出向量
有人会问：能不能让 DeepSeek 直接生成文档向量，省掉一个模型？从技术角度说不行——DeepSeek 这类大模型输出的 token 是概率分布，不是为语义相似度设计的定长向量；即便强行取最后一层隐藏状态，维度过高、计算成本巨大，而且没有经过对比学习训练，检索效果远不如专门的 embedding 模型。目前社区里检索效果经过验证的中文 embedding 模型是BAAI/bge-m3，它有 1024 维、支持 8192 token 的输入，对中文长文档尤其友好。
from sentence_transformers import SentenceTransformer model = SentenceTransformer("BAAI/bge-m3") emb = model.encode("退货率最高的SKU是哪个", normalize_embeddings=True) print(emb.shape) # (1024,)代码里normalize_embeddings=True这个参数很容易被忽略，但影响很大——向量归一化之后，余弦相似度和内积等价，有些向量库默认用内积计算，不归一化会导致检索结果错乱。bge-m3 模型约 2GB，纯 CPU 也能跑，但 embed 一批文档时 GPU 会快 10 倍以上。如果没有 GPU 资源，也可以调用硅基流动等平台的 embedding API，代码里换个 client 即可。
3. 向量数据库选型与落地：Chroma、Milvus、Qdrant 怎么挑
3.1 三种主流向量数据库的对比：从 demo 到生产的距离
向量数据库是知识库的“记忆容器”，选型错了后面全得返工。我按自己评估过的三个维度（数据规模、部署复杂度、运维成本）对比一下市面上最常用的三个项目。
| 维度 | Chroma | Qdrant | Milvus |
|---|---|---|---|
| 适合规模 | 百万级向量以内 | 千万级向量 | 亿级向量 |
| 部署方式 | 嵌入式/单机 | Docker 单机/集群 | Docker 集群/K8s |
| 客户端语言 | Python/JS | 多语言 | 多语言 |
| 持久化 | SQLite 文件 | RocksDB | 分布式存储 |
| 运维成本 | 几乎为零 | 低 | 高 |
| 典型场景 | 原型验证、小团队内部工具 | 中等规模生产 | 大规模生产、高并发 |
Chroma 最打动我的是零运维，启动就是一个 Python 进程，数据存在本地文件夹，适合 20 人以下的团队内部知识库。Qdrant 用 Rust 写的，性能强、索引结构清晰，单机支撑千万级没问题。Milvus 是真正的分布式架构，但也意味着要部署 etcd、MinIO、Pulsar 一堆依赖组件——如果你的向量数量没到千万级，上 Milvus 属于给自己找事。我的建议是：先 Chroma 跑通业务，向量超过 200 万或并发超过 50 QPS 再迁 Qdrant，Milvus 留给数据规模真的撑不住的那天。
3.2 用 Chroma 最快跑通原型：15 分钟完成建库和检索
Chroma 的 API 对新手极其友好，进到代码层面只有一个核心概念——collection，类比成关系型数据库里的表。首次使用要安装，然后创建 collection、写入向量、检索，三个步骤。
pip install chromadb sentence-transformersimport chromadb from sentence_transformers import SentenceTransformer # 1. 初始化客户端，数据持久化到本地目录 client = chromadb.PersistentClient(path="./knowledge_base") collection = client.get_or_create_collection( name="enterprise_kb", metadata={"hnsw:space": "cosine"} ) # 2. 加载 embedding 模型，把文档转成向量 embedder = SentenceTransformer("BAAI/bge-m3") docs = ["退货流程：客户提交申请后，仓库在48小时内完成审核", "华东区Q3退货率环比上升2.3%，主因是物流破损"] vecs = embedder.encode(docs, normalize_embeddings=True).tolist() # 3. 写入，id 必须唯一 collection.add( documents=docs, embeddings=vecs, ids=["doc_001", "doc_002"], metadatas=[{"source": "售后手册"}, {"source": "月度报告"}] ) # 4. 检索 query_vec = embedder.encode(["退货率高怎么办"], normalize_embeddings=True).tolist() results = collection.query( query_embeddings=query_vec, n_results=2, where={"source": "售后手册"} ) print(results["documents"])这里metadata={"hnsw:space": "cosine"}指定了向量距离算法是余弦距离，对文本语义检索是默认正确选择；n_results控制返回条数，建议 5 到 10 条，取太少可能漏掉相关段落，取太多会把不相关的内容喂给大模型。where参数是元数据过滤，比如限定来源、限定时间范围，这在企业场景非常实用。注意.add时我同时传了documents和embeddings，Chroma 允许只传 documents 并让它内部自动调 embedding 模型，但那样每次检索都要重新加载模型，性能差很多，所以手动编码再写入是正解。
3.3 Milvus 上生产：集合设计、HNSW 索引参数与检索
当数据量上来，Chroma 的 SQLite 存储会成为瓶颈，这时候迁 Milvus。Milvus 的核心概念是 collection + index + partition，和 Elasticsearch 的 index + mapping 逻辑类似。先在 Docker 里把服务跑起来：
docker run -d --name milvus \ -p 19530:19530 \ -p 9091:9091 \ milvusdb/milvus:v2.4.0然后用 pymilvus 建集合和索引：
from pymilvus import MilvusClient, DataType client = MilvusClient(uri="http://localhost:19530") schema = MilvusClient.create_schema(auto_id=False) schema.add_field("id", DataType.VARCHAR, max_length=64, is_primary=True) schema.add_field("embedding", DataType.FLOAT_VECTOR, dim=1024) schema.add_field("source", DataType.VARCHAR, max_length=256) index_params = client.prepare_index_params() index_params.add_index( field_name="embedding", index_type="HNSW", metric_type="COSINE", params={"M": 16, "efConstruction": 200} ) client.create_collection("enterprise_kb", schema=schema, index_params=index_params)字段设计上注意三点：一是dim必须和 embedding 模型输出维度一致，bge-m3 是 1024 维，写错直接报错；二是必须显式指定metric_type="COSINE"，和训练 embedding 时用的距离度量保持一致；三是所有源文档的元数据（来源、页码、上传时间）都要建字段，方便后续按条件过滤。M=16是 HNSW 图每个节点的最大连接数，数值越大召回越全但内存占用越高；efConstruction=200是建索引时的搜索宽度，越大索引质量越好但建库时间越长。生产环境我的经验值：M 取 16 到 32，efConstruction 取 200 到 400。
检索时生成 query 向量，然后用search接口：
query_vec = embedder.encode(["退货率高怎么办"], normalize_embeddings=True) res = client.search( collection_name="enterprise_kb", data=[query_vec.tolist()], limit=10, output_fields=["source"], search_params={"metric_type": "COSINE", "params": {"ef": 64}} )ef是检索时的动态搜索宽度，值越大召回越全但延迟越高。线上调优我会把 ef 设为 M 的 4 倍左右，比如 M=16 时 ef=64，这是一个性价比平衡点。
4. 从 PDF 到可检索切片：企业知识库的入库流水线
4.1 文档解析：PDF、Word、Markdown 各自用什么库
文档解析是整个知识库最“脏”的一步，因为 PDF 有两种——文本型 PDF 直接抽出文字，扫描型 PDF 得先做 OCR。文本型 PDF 用pymupdf提取效果最好，速度快、对样式保留好。Word 文档用python-docx，Markdown 直接读文本。我这个章节给出一个能覆盖三类文档的解析函数：
import fitz # pymupdf from docx import Document from pathlib import Path def extract_text(file_path: str) -> str: suffix = Path(file_path).suffix.lower() if suffix == ".pdf": doc = fitz.open(file_path) return "\n".join(page.get_text("text") for page in doc) elif suffix == ".docx": doc = Document(file_path) return "\n".join(p.text for p in doc.paragraphs if p.text.strip()) elif suffix == ".md": return Path(file_path).read_text(encoding="utf-8") else: raise ValueError(f"不支持的文件类型: {suffix}")PDF 解析这里有个坑：page.get_text("text")拿到的是按物理布局排列的文本块，遇到多栏文档（比如论文、宣传册），左右两栏的文字会交错在一起，切出来的语义是碎的。遇到多栏 PDF，我会改用page.get_text("blocks")按坐标块提取，再按横坐标排序拼回单栏顺序。扫描型 PDF 需要先 OCR，推荐 PaddleOCR，但那是另一个工作量级——如果知识库里大量是扫描件，先在项目规划里预留 30% 的额外工期。
4.2 切片策略：按标题切还是固定窗口？决定检索上限
文档解析完就是切片（chunking），这一步直接决定检索效果。切太大，向量包含太多无关信息，相似度被稀释；切太小，语义不完整，模型拿到片段也看不懂。我一般按文档结构走：先按标题层级切出章节块，章节过长再按固定窗口二次切分。常见的做法是这样的顺序——优先 Markdown 标题 / Word 标题样式 / PDF 的目录结构，Fallback 到纯文本按段落切，最后才是固定字符窗口。实际代码：
import re def split_by_headings(text: str, max_chunk_size: int = 800): # 以 Markdown 标题或中文序号标题作为切割点 pattern = r"(?m)^(#+\s.*|第[一二三四五六七八九十百千]+[章节].*)$" matches = list(re.finditer(pattern, text)) if not matches: return [text[i:i+max_chunk_size] for i in range(0, len(text), max_chunk_size)] chunks = [] for idx, m in enumerate(matches): start = m.start() end = matches[idx + 1].start() if idx + 1 < len(matches) else len(text) segment = text[start:end].strip() if len(segment) > max_chunk_size: # 超长段落二次切分，保留 50 字 overlap step = max_chunk_size - 50 for i in range(0, len(segment), step): chunks.append(segment[i:i+max_chunk_size]) else: chunks.append(segment) return chunks注意overlap=50的设计——两个相邻切片保留 50 个字符的重叠，防止句子被从中间截断。切片长度用字符数衡量，中文场景一个字符约等于 0.7 个 token，800 字符大约对应 560 token，放在 bge-m3 的 8192 token 上下文里毫无压力。切片太短的缺陷是检索到了但上下文不够，模型回答没有细节；切片太长则多个话题混在一起，相似度被稀释。我会建议大模型生成的文档切片 600 到 1000 字符，表格类数据单行一个切片，代码类文档按函数块切。
4.3 完整入库流水线：解析 → 切片 → 向量化 → 写入一个函数搞定
前三步准备好之后，把它们串成一条流水线。这个函数直接可用，输入文件路径，输出写入 Chroma 的切片数和耗时，方便你在批量入库时观察进度。
import hashlib import time from pathlib import Path def ingest_document(file_path: str, collection, embedder, source_tag: str = None): t0 = time.time() text = extract_text(file_path) chunks = split_by_headings(text) # 生成每个切片的唯一 ID：文件路径哈希 + 序号 file_hash = hashlib.md5(Path(file_path).name.encode()).hexdigest()[:8] ids = [f"{file_hash}_{i}" for i in range(len(chunks))] # 向量化 vecs = embedder.encode(chunks, normalize_embeddings=True).tolist() # 写入向量库，附带元数据 metadatas = [{ "source": source_tag or Path(file_path).name, "chunk_index": i, "chunk_size": len(chunks[i]) } for i in range(len(chunks))] collection.add( ids=ids, documents=chunks, embeddings=vecs, metadatas=metadatas ) print(f"入库完成: {file_path}, 切片数 {len(chunks)}, 耗时 {time.time()-t0:.2f}s")设计上每个切片的 ID 由“文件名哈希 + 序号”组成，这在做增量更新时是关键。很多团队踩的坑是每次重新入库都重新生成随机 ID，导致知识库里同一个文档出现几十个副本，检索结果里同一段话反复出现。用确定性 ID 之后，同文档再次入库时 ID 一致，可以配合 Chroma 的 upsert 语义覆盖旧数据。
4.4 元数据设计：来源、页码、更新时间一个都不能少
向量数据库里的元数据（metadata）是很容易被忽略的设计点，但它是企业知识库里“可管理性”的根基。每一条向量至少要挂四个字段：来源文件、章节路径、页码、入库时间。来源文件用于回答时标注出处，章节路径用于追溯上下文，页码用于定位原始 PDF，入库时间用于判断数据的新鲜度。在 Chroma 里元数据是以 dict 形式挂在每条记录上的，查询时可以按任意字段过滤。举个例子，业务侧想看“仅近一个月的制度文件相关回答”，检索请求里带上where={"ingest_time": {"$gte": "2024-11-01"}}就能实现，没有这个字段就得全量检索再过滤，准确率大打折扣。
元数据的第二个用途是做权限隔离。不同部门对知识库的访问范围不同，把department字段写入元数据，检索时强制拼接过滤条件，比在业务代码里做 if 判断要可靠得多。我在生产项目里见过只给前端传检索结果、忘记过滤导致的越权事故，不要重蹈覆辙。
5. 避坑指南：企业知识库最常见的 5 个翻车现场
5.1 检索结果答非所问：切片把语义切碎了
现象：用户问“退货率怎么计算”，回答里混入了“质检标准”的内容，看起来有关联但完全不是一回事。
原因：文档在固定窗口切片时，切点落在两个话题的边界中间，一个向量里装了半个话题 A 和半个话题 B，相似度被两个话题平摊，检索时命中的内容是“四不像”。
解决：换用按标题/段落语义切片的策略，并加上 50 到 100 字符的 overlap。另外，切片前先用正则把表格、引用块、代码块单独摘出来，不要混在正文里切。
5.2 型号、料号等精确关键词检不到：向量检索的盲区
现象：问“FPGA-2024-017 的库存”，检索结果完全跑偏；改成在全文里搜这个型号，明明能搜到。
原因：向量检索适合语义匹配，但对短代码、缩写、混合字符的精确匹配不敏感。embedding 模型会把“FPGA-2024-017”整个当成语义单元，而用户输入时可能拆成“FPGA 2024 017”，两者向量距离很远。
解决：引入关键词检索兜底——用 SQLite FTS5 或 Elasticsearch 对原文建倒排索引，检索时先向量召回 top50，再关键词精确匹配补 top10，两批结果合并去重后交给大模型。这类“混合检索”是生产环境的标配，不能省。
5.3 文档更新后新旧内容“打架”：缺少幂等更新机制
现象：制度文件 V2 发布后入库，员工问最新规定，模型回答里同时出现旧版和新版内容，给出的结论自相矛盾。
原因：入库流水线直接collection.add，没有按文档维度先删旧版本。旧切片的 ID 基于旧文件名生成，新文档来了只会追加，不会覆盖。
解决：入库前先按元数据source字段删除旧文档的所有切片，再插入新切片。代码就是在 Chroma 里先collection.delete(where={"source": "制度文件V1.pdf"})，再走正常入库流程。这个操作要写进流水线，别手动执行。
5.4 本地部署 OOM 导致服务频繁重启：模型吃满了显存
现象：部署 DeepSeek 之后，前几分钟响应正常，半小时后接口超时，查看日志发现进程被系统 kill。
原因：大模型和 embedding 模型同时常驻 GPU 显存，并发请求上来后显存激增，触发 OOM。更隐蔽的是，vLLM 默认会给每个请求预留完整的 KV cache，上下文窗口设得越大会话占越多显存。
解决：显存不够时让 embedding 模型跑 CPU，大模型独占 GPU。修改启动参数——vLLM 用--gpu-memory-utilization 0.85限制显存占用比例，预留内存给 embedding 推理；并发线程数控制在 8 以下。如果还不行，就换更小的量化版模型。
5.5 检索到了但回答空洞：没有把“上下文窗口”用好
现象：检索回来的片段确实相关，但 DeepSeek 回答只有一句总结，像在复述片段标题，完全没有细节。
原因：我把n_results设成了 3，而业务问题涉及多个子话题，3 个片段不足以覆盖。
解决：把检索数量提升到 5 到 10，同时把每个片段连同其所属的章节标题一起拼进 prompt，让模型知道上下文边界。检索返回结果里按chunk_index排序，把属于同一章节的相邻切片合并成一个长上下文块，再交给模型。这个做法的提升非常直观。
6. 让知识库更“懂”业务：query 改写与重排的两层增强
6.1 Query 改写：让检索词先“说人话”一次
用户问“那个退货的东西什么时候能弄完”，这个口语化表达直接拿去向量检索，效果很差。更有效的做法是让 DeepSeek 先对用户问题做一次改写，提炼出检索友好的关键词组合，然后再去查向量库。改写 prompt 长这样：
def rewrite_query(user_question: str) -> str: system_prompt = """你是检索query优化器。将用户的口语化提问改写为适合向量检索的查询语句。 要求：1. 保留核心实体和业务术语；2. 补充同义词；3. 不要编造原文没有的信息。 示例：问“退货什么时候能好” -> 改写为“退货处理时长 退货流程 审核周期”""" resp = ask_deepseek(system_prompt, user_question) return resp.strip()改写后的 query 是一组关键词短语，embedding 后检索的命中率会比原句高不少，尤其是长尾口语问题。代价是每次检索多一次大模型调用，延迟增加约 300 到 500 毫秒——企业内部知识库这个成本值得付。
6.2 重排：从 Top20 里选出真正相关的 Top5
向量检索的 top5 不一定比 top20 里的某些结果更相关，这是由 HNSW 索引的近似搜索特性决定的。要让结果更精确，再加一个 rerank 环节：先用向量检索拿回 20 条候选，再用交叉编码器模型逐条计算“问题和片段的匹配分”，按分数重新排序取前 5。交叉编码器比双塔 embedding 更准，因为它在计算时让问题和片段做了完整的 attention 交互。
from sentence_transformers import CrossEncoder reranker = CrossEncoder("BAAI/bge-reranker-base") def rerank_results(query: str, docs: list[str], top_k: int = 5): pairs = [[query, doc] for doc in docs] scores = reranker.predict(pairs) ranked = sorted(zip(docs, scores), key=lambda x: x[1], reverse=True) return [doc for doc, score in ranked[:top_k]]bge-reranker 模型单条打分耗时约 50 到 100 毫秒，20 条候选就是 2 秒，这个延迟可以通过降候选数到 10 来平衡。重排阶段对算力要求不高，完全可以用 CPU 跑，不需要 GPU。
6.3 混合检索与 RRF 融合：兼顾语义和关键词的两手方案
最后把前面提到的各路检索结果融合起来。我采用的方法叫 RRF（Reciprocal Rank Fusion）：对同一批文档在向量检索、关键词检索、重排后的排名分别取倒数，加总得分再排序。这个算法看似简单，却是信息检索里验证过非常鲁棒的融合策略——它不需要调权重，对分数尺度不敏感，两个检索结果谁给的分高都不会主导最终排序。核心逻辑示意如下：
from collections import defaultdict def rrf_fusion(lists_of_results: list[list[str]], k: int = 60): scores = defaultdict(float) for ranked_list in lists_of_results: for rank, doc_id in enumerate(ranked_list): scores[doc_id] += 1.0 / (k + rank + 1) return sorted(scores, key=scores.get, reverse=True)k的默认值 60 是学术界验证过的经验值，不需要改。融合后的结果前 5 条作为最终上下文喂给 DeepSeek。我在多个知识库项目里对比过：只用向量检索的正确率大约 70%，加 BM25 混合到 82%，再加 rerank 之后能到 90% 以上。这三层增强做下来，知识库才真正敢给业务部门用。我自己的习惯是把“改写+召回+重排”封装成一个检索服务，单独部署，这样后面替换向量库或者换 embedding 模型，业务层不用改一行代码。这个知识的沉淀比任何一个具体工具都值钱，希望帮到你。
本文还有配套的精品资源，点击获取
