简介：本资源围绕基于 DeepSeek 构建本地知识库展开，既讲技术原理，也覆盖落地方案选型，适合希望搭建个人或企业级 RAG 知识库的AI应用开发者、技术决策者以及大模型爱好者。内容从 RAG 的检索增强工作原理讲起，对比上下文窗口竞争下的技术价值，并结合实际演示 Cherry Studio 轻量方案与 Dify 企业级方案的配置路径。通过学习可以理解向量检索、提示词增强等核心环节，并掌握私有知识库建设的一般流程。包体为 1 个 PDF 文档，整体大小 2.28MB，便于随时翻阅。资源当前已有 260 人学习下载，适合作为入门到进阶的参考材料。文档不局限于工具罗列，还强调了 RAG 在医疗、政务等对准确性要求较高场景中的必要性，能帮助读者避开“只堆窗口长度”的误区，建立起更务实的技术选型判断力。

1. 本地知识库不是“把文档喂给DeepSeek”：先看清它在解决什么问题

很多人听到“基于DeepSeek构建个人与企业大模型本地知识库”，第一反应是做一个能聊天的窗口，把PPT、Word、PDF全塞进去，以为模型自己会读书。真实落地时你会发现，你要解决的是“私域知识怎么被找到，又怎么被可信地写进回答里”这两件事，而不是聊天本身。

这个方案的价值在三个场景里特别明显：个人博主把几百篇文章变成能引用原文的问答助手；中小企业把制度、产品手册、售后记录做成内部知识库；对数据敏感的企业要求模型推理和文档检索都在内网完成，不让内容流向云端。

适合的读者是做开发、做运维，或正在负责企业内部智能化改造的工程师。下面每一步都按“能照抄”的标准来写，同时讲清楚参数为什么这么设，踩过的坑也一并标出来。

2. 原理拆解：RAG如何让DeepSeek“读过你的资料”后再回答

2.1 为什么要用RAG而不是微调：三句话讲清楚边界

本地知识库的主流实现不是微调，而是RAG（检索增强生成）。每次用户提问时，系统先从你的文档库里检索出相关片段，再把片段和问题一起交给DeepSeek生成答案。DeepSeek没有“记住”你的文档，但它在回答时“读到了”相关的那几段，这从根本上决定了两件事：知识可更新，答案可追溯。

第一，知识更新不一样。RAG改文档、重建索引，索引替换完就生效；微调要整理数据集、跑训练、做评估，一个新的内部规范从梳理到上线往往要一两周。第二，幻觉控制不一样。RAG的答案至少能追溯到检索片段，员工质疑时你可以把引用的原文亮出来；微调模型是参数里的记忆，出错了你查不到依据。第三，算力门槛不一样。微调一个70B级别的模型需要多卡GPU，而RAG在一个带独显的台式机上就能跑起来，个人项目用纯CPU也能勉强演示。

那有没有必须上微调的场景？有。比如你希望DeepSeek模仿公司固定的回复风格、内部术语缩写、特定格式输出，这时候单靠Prompt不够稳定，微调能把“表达习惯”压进权重里。我一般建议先跑RAG，把检索和问答链路验证完，再评估要不要微调，顺序别反了。现实中很多团队被“微调包治百病”的营销带偏，花几周调完模型，结果回答时照样对内部文档一无所知，就是因为知识没有进到参数里。

还要说清RAG的边界：它本质上是一个“开卷考试”系统，答案上限取决于检索质量。如果文档里根本没有对应内容，或内容被切得七零八落，模型再强也只能靠上下文里的碎片脑补。所以原理章节的重心放在“怎么让检索不丢、不偏、不漏”，这比选哪个大模型更重要。

2.2 一条查询的完整旅程：切块、向量化、召回、重排与生成

一次完整的查询会走五步。第一步，把原始文档清洗和切块。清洗指去掉页眉页脚、目录、水印，切块不是按页切，而是按语义边界切，一般用换行、句号、问号作为分隔符。第二步，把每个文本块做embedding，变成高维向量。这里要用中文效果更稳的模型，比如BGE-M3，而不是直接拿英文通用模型凑合。第三步，把“用户问题”也向量化，在向量库里做相似度检索，取top-k个候选块。第四步是重排，对候选块再做一次打分，把真正靠前的片段顶上。第五步，把排序后的片段连同问题拼成提示词，交给DeepSeek生成答案。

这里最关键的是切块参数。切块太小，比如100字，会导致一个完整流程被截断，检索到的意思不全；切块太大，比如2万字，向量检索的粒度太粗，混入大量无关句子。我常用的起点是chunk_size=500字符（中文），chunk_overlap=80字符，overlap的作用是给跨块上下文留一个“重叠区”，防止一个完整句子的后半句被丢到下一个块里。这个参数是后面实操可以直接套的，但别迷信默认值，文档体例不同，数值要跟着动。

另一个关键参数是retriever里的k值。k值太小，比如只取2个块，就会漏掉多个来源的答案；k值太大，比如取10个，又会把噪声塞进Prompt，DeepSeek容易被不相关内容带偏。个人项目我建议k=4起步，企业内部文档多，k=6到8，但最终要通过评估集验证，不是拍脑袋定的。

重排这步很多人会跳过，但它对中文命中的提升非常明显。向量检索是按语义相似度排序的，比如“退货运费谁承担”和真实文档里的“退货邮费处理规则”向量距离很近，可后面跟着的几个块却未必相关。重排器会把候选块重新精排一次，通常能提高5到10个百分点的命中率。如果你买不起重排模型的计算资源，至少可以做一个规则：优先保留包含专有名词和数字的片段。

2.3 本地知识库的系统组件清单：最少需要哪几块

一个完整可用的本地知识库，至少由六块组件组成：文档解析器、切分器、embedding模型、向量库、大模型、编排框架。文档解析器负责把PDF、Word、扫描件转成可处理的文本；切分器把文本按语义边界切成块；embedding模型把文本块和查询变成向量；向量库负责存储并检索这些向量；大模型负责最终生成；编排框架把前面的环节串成一个接口。

企业私有化部署还要加两块：权限控制和审计日志。权限控制决定谁能查到哪些文档，审计日志记录谁在什么时候问了什么、模型引用过哪些片段。这两块在个人版可以不接，但放到企业内网时会成为合规的硬要求，最好在架构设计阶段就留出接口，不然后面从个人项目演进时会非常痛苦。

我结合个人和企业两种场景，把组件选型整理成一张表，后续章节会展开讲选型逻辑：

这张表提醒一个容易忽略的事：embedding模型和大模型是两个单独的开销。很多人只盯着DeepSeek的大模型参数量，却忘了embedding模型也占内存，而且它对中文检索质量的影响不亚于大模型。下一章开始选型，先解决“用哪些组件”，再进实操。

3. 方案选型：个人桌面与企业私有化是完全不同的两种架构

3.1 模型层选型：API、Ollama、vLLM三种路线怎么选

模型层选型本质是“部署成本、数据隐私、并发能力”三者之间的权衡。DeepSeek官方API延迟低、效果好，适合快速验证，但你的文档和查询内容会经过外部服务。Ollama是本地单机工具，一条命令就能把DeepSeek的蒸馏模型拉下来跑，适合个人电脑和隔离内网的小型团队。vLLM是高性能推理服务，支持连续批处理，适合企业把DeepSeek私有化部署之后做统一模型入口。

三种路线的边界可以给得很直白：追求两天内跑通、数据不敏感、单人使用，直接选API；机器只有一个GPU或纯CPU、文档量在几百份以内、并发不超过两三个人，选Ollama；买了服务器、期待多部门同时使用、每天上千次查询，选vLLM。需要提醒的是，Ollama和vLLM都提供OpenAI兼容接口，你完全可以在个人阶段用Ollama，企业阶段换vLLM，只改一个base_url，前面的RAG代码不用推倒重写。

模型参数量怎么选也经常让人纠结。我的建议是：16GB内存的笔记本跑DeepSeek-R1的7B量化版，能演示、能学习；32GB内存加24GB显存可以上32B量化版，开始具备可用性；如果追求企业级稳定回答，要么部署70B级别模型，要么保留API混合路由。别一上来就追求满血671B，那个规模在大多数中小型企业的运维能力下是灾难。

还要强调：标题里的“本地知识库”不等于“本地大模型”。文档、向量库在你自己服务器上，模型则可以走API。很多企业第一次落地时先用DeepSeek API把业务跑通，再把模型层逐步替换成本地部署，这个路径最稳。我见过不少团队一上来就买双路GPU服务器，结果最耗时间的反而是驱动、镜像和模型切分，业务需求反而没先想清楚。

3.2 向量库与检索框架：FAISS、Milvus、Dify/RAGFlow的取舍

向量库和检索框架是方案选型里最容易过度设计的地方。FAISS是向量索引库，适合单机存储几十万条向量，索引文件保存到本地磁盘，重新加载很快。Milvus是分布式向量数据库，支持集合、分区、标量过滤、滚动升级，适合多个知识库共用一套基础设施。如果你只有几千个文档块，用FAISS够了，上Milvus就是大炮打蚊子。

检索框架的选择更看团队画像。LangChain和LlamaIndex是开发库，能嵌入你自己的业务代码，可控性强，但你要写代码、维护依赖、踩API迁移的坑。RAGFlow和Dify是开箱即用的RAG应用平台，自带文档解析、切分、知识库管理和对话UI，企业内部非开发人员也能维护。从一线落地经验看：个人项目用LangChain；企业想快速给业务部门看到成果，用RAGFlow或Dify搭一个原型，两三天就能交付，之后再决定要不要把核心链路抽出来自研。

另一个常被忽视的选型点是文档解析。RAGFlow和Dify对PDF、Word、扫描件的处理覆盖比较全，尤其是表格和图片，它们内置了版面分析和OCR。自研路线里，pypdf和pdfplumber只能处理文本型PDF，遇到扫描件就必须额外接OCR。选型前先拿你们最典型的100份真实文档做测试，别用干净整洁的公开PDF测试，否则上线后会发现一半文档解析不出来。

向量库层面的关键参数是相似度度量。FAISS默认用L2距离，Milvus常用COSINE。如果用L2，要让embedding向量归一化；用COSINE则直接比较角度。我建议统一用COSINE，并设一个相似度阈值0.6到0.8，低于阈值的片段宁可不要，也不能把无关内容塞给DeepSeek。阈值设太紧会漏召，设太松会污染，这个值要拿真实问题跑几遍才能定下来。

3.3 硬件预算与性能估算：一张表说清各档位的可行配置

硬件这块最容易翻车，因为大模型推理吃显存，embedding和向量检索吃内存，两者要同时算。下面的表是我按常见配置整理的参考档位，不是官方数据，但符合多数项目实际表现：

这条经验很重要：并发和显存的关系不是线性的。vLLM能连续批处理，多用户同时请求时吞吐高很多；Ollama默认单模型串行，一个人占着GPU，另一个人只能排队。所以如果确定要服务超过5个内部用户，别在Ollama上做二次开发，尽早切vLLM。

预算上容易被忽略的有两块：一块是向量检索的内存，百万级向量加HNSW索引大概占1到2GB，不算大；另一块是知识库更新频率。如果文档每周都改，需要预留重建索引的时间和增量同步机制，这部分往往是运维成本隐性大头。我见过一个项目，模型部署好后，运维每周花一整天重建向量库，这就是没做增量同步的设计。

最后聊一个选型技巧：先定向量库和embedding，再定LLM。因为LLM可以随时换API或本地版本，但向量库一旦选错，后面清洗和迁移成本很高。我倾向先走FAISS加BGE-M3，在代码层把检索接口抽象好，等数据量上升后平滑迁到Milvus。另外，如果预算有限，embedding可以继续跑CPU，GPU专门留给DeepSeek推理，别让两个模型抢显存。

4. 实操：用Ollama+DeepSeek搭一个最小可用的本地知识库

4.1 环境准备：安装Ollama并拉取DeepSeek模型

先说我用的组合：Ollama负责跑DeepSeek，LangChain负责编排，FAISS做向量库，BGE-M3做embedding。这套组合在Windows、macOS、Linux上都能跑，下面的命令以Linux/macOS为例，Windows用户安装后命令行操作完全一致。

安装Ollama一般用官方脚本，它会自动注册本机服务：

# 安装Ollama curl -fsSL https://ollama.com/install.sh | sh # 确认服务在跑 ollama serve & # 拉取DeepSeek R1 7B蒸馏版，默认Q4量化 ollama pull deepseek-r1:7b # 跑一个测试对话，验证本地模型能正常生成 ollama run deepseek-r1:7b "用一句话解释什么是RAG"

这里有几个参数值得说明。deepseek-r1:7b是R1系列里参数量较小的蒸馏版本，Q4量化后模型文件约4到5GB，纯CPU跑需要约8GB可用内存，16GB内存的电脑就能起来。如果机器只有8GB内存，换成deepseek-r1:1.5b，牺牲回答质量换可用速度。如果机器有24GB显存，建议换deepseek-r1:32b，回答质量明显提升一个台阶。

Ollama第一次运行模型会预热，后面如果卡顿，先看日志里有没有连续读盘的提示，那说明内存不够，模型在被换页。另外，Ollama默认监听11434端口，个人电脑无所谓，但企业环境要关闭外网暴露，否则等于把模型服务裸奔在公网上。这个端口还能在装好Docker后用容器跑，能力差不多，但运维体验更干净。

装好模型后，我们装Python依赖：

# 创建虚拟环境，避免污染系统Python python3 -m venv kb_env source kb_env/bin/activate # 安装RAG链路所需依赖 pip install langchain langchain-community langchain-ollama faiss-cpu sentence-transformers

langchain是主线框架，langchain-ollama提供Ollama大模型接口，langchain-community里带了FAISS和HuggingFaceEmbeddings的适配器，faiss-cpu是CPU版向量索引库，sentence-transformers用于加载embedding模型。如果你的机器有GPU，把faiss-cpu换成faiss-gpu，并把sentence-transformers配置为cuda模式，检索速度会快一个量级，个人项目CPU版完全够用。

4.2 编写本地RAG脚本：切块、embedding、检索与问答

环境准备完成后，写一个最小脚本把整条链路串起来。下面的代码假设你有一份knowledge.txt，是准备让DeepSeek“阅读”的企业资料。真实项目可以先用一两份文档验证逻辑，再批量处理。

from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS from langchain_ollama import ChatOllama from langchain.chains import RetrievalQA # 1. 读取本地知识文档 with open("knowledge.txt", "r", encoding="utf-8") as f: raw_text = f.read() # 2. 按语义边界切块，chunk_size=500，overlap=80 text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=80, separators=["\n\n", "\n", "。", "！", "？", "；", " ", ""], keep_separator=True, ) chunks = text_splitter.split_text(raw_text) print(f"切分完成，共 {len(chunks)} 个文本块") # 3. 使用BGE-M3做embedding，中文场景更稳 embedder = HuggingFaceEmbeddings( model_name="BAAI/bge-m3", model_kwargs={"device": "cpu"}, encode_kwargs={"normalize_embeddings": True}, ) # 4. 构建FAISS向量库并保存到本地 vectorstore = FAISS.from_texts(chunks, embedder) vectorstore.save_local("kb_index") # 5. 加载DeepSeek本地模型，temperature调低减少发散 llm = ChatOllama(model="deepseek-r1:7b", temperature=0.2) # 6. 组装检索问答链路，k=4表示取4个相关片段 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=vectorstore.as_retriever(search_kwargs={"k": 4}), return_source_documents=True, ) # 7. 提问并输出答案与引用片段 question = "离职交接流程里必须完成哪些审批步骤？" result = qa_chain.invoke({"query": question}) print("答案：", result["result"]) print("\n引用片段：") for doc in result["source_documents"]: print("-", doc.page_content[:100])

这段代码有几个参数值得专门说明。切分器的separators顺序很重要，它从列表第一个分隔符尝试，不行再往后退，所以把段落换行放在最前面，句号和分号放后面，能保证切块尽量落在语义边界上。chunk_size=500是常见中文起点，如果你的文档里规范条文很多，可以调到600到800；overlap=80能保住跨块句子的完整性。

normalize_embeddings=True表示向量归一化，FAISS默认用L2距离时，归一化后等价于余弦相似度，检索结果更稳定，也方便统一用余弦距离判断阈值。temperature=0.2是为知识问答场景调低，因为这类问题需要事实稳定而不是发散，如果发现模型话痨，降到0.1。

chain_type="stuff"是最稳妥的组装方式，它把所有检索片段一次性拼进Prompt，适合k在10以内时使用；如果k很大导致超出上下文窗口，就要换map_reduce或refine，但那些会带来额外模型调用成本，个人项目不必急着用。

首次运行HuggingFaceEmbeddings会自动从模型库下载BGE-M3，大概需要几百MB空间，网络受限时可以先把模型下载好，再通过环境变量HF_ENDPOINT指定镜像源。建立向量库后在kb_index目录下会生成.faiss和.pkl两个文件，后者保存原文映射关系，两者要放一起，别只拷贝一个到别的机器。

4.3 把脚本扩展成企业服务：API封装与权限控制要点

脚本验证通过后，扩展成企业服务主要做三件事：全局加载资源、暴露接口、加访问控制。关键教训是不要把QA链在每次请求里重复初始化，一次加载，全局复用，用FastAPI管理生命周期。

from fastapi import FastAPI, HTTPException, Depends from pydantic import BaseModel from typing import Optional import os app = FastAPI() _qa_chain = None class QueryRequest(BaseModel): query: str top_k: Optional[int] = 4 def get_qa_chain(): global _qa_chain if _qa_chain is None: # 从本地加载向量库，避免每次请求重建索引 from langchain_community.vectorstores import FAISS from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_ollama import ChatOllama from langchain.chains import RetrievalQA embedder = HuggingFaceEmbeddings(model_name="BAAI/bge-m3") vectorstore = FAISS.load_local( "kb_index", embedder, allow_dangerous_deserialization=True ) llm = ChatOllama(model="deepseek-r1:7b", temperature=0.2) _qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=vectorstore.as_retriever( search_kwargs={"k": 4} ), return_source_documents=True, ) return _qa_chain def check_token(x_token: str = Depends(lambda: "")): # 生产环境换成JWT或内网SSO if x_token != os.getenv("KB_API_TOKEN", ""): raise HTTPException(status_code=401, detail="invalid token") @app.post("/kb/ask") async def ask(req: QueryRequest, token: str = Depends(check_token)): chain = get_qa_chain() result = chain.invoke({"query": req.query}) return { "answer": result["result"], "sources": [d.page_content for d in result["source_documents"]], }

这里load_local要传allow_dangerous_deserialization=True，因为FAISS的.pkl文件反序列化存在安全风险。在内网可接受，但如果服务暴露在不可信网络，建议换成Milvus这类服务端向量库，不依赖本地反序列化。

权限控制这里只做了Token头校验，真正的企业落地通常要接企业微信、钉钉或内部SSO，并在网关层鉴权。还有一个容易忽略的点：审计日志。公司审计要求能回溯“谁问了什么问题、模型引用了哪几段”，所以在接口里把每一轮问答的原始输入、输出、引用片段和时间戳写进日志表，这比代码健壮性更优先。

并发方面，FastAPI的异步特性对RetrievalQA.invoke这种同步调用并不能缓解阻塞，多用户来请求时线程池会变大，模型上下文缓冲叠加很容易OOM。常见做法是给Ollama加一个请求队列，或直接换vLLM推理后端，向量检索单独部署。如果只是给一个部门十几个人用，限制每个用户每秒最多一次请求就够，小范围使用不用急着上消息队列。

5. 常见问题与排坑：本地知识库最容易翻车的5处细节

下面的每一条都是实际工程里见过的坑，不是泛泛而谈。它们有些在测试环境根本测不出来，要等数据量和并发上来之后才爆发。每条按“现象、原因、解决”三步写，方便你直接定位。

5.1 现象：CPU跑DeepSeek慢到无法用，原因不是算力而是量化

我在一台16GB内存的笔记本上用Ollama跑deepseek-r1:7b，第一次对话生成速度只有每秒四五个token，一个两百字的答案要等半分钟，根本没法做交互。原因看起来是CPU算力弱，但真正问题有三个叠加：Ollama下载的Q4量化版在CPU上仍要逐token解码；内存带宽是CPU推理的硬瓶颈，DDR4带宽远低于显卡显存；如果CPU指令集老旧，还会触发AVX回退路径，速度进一步掉一半。

解决方式要分级。如果只是验证流程，直接换deepseek-r1:1.5b，生成速度能回到每秒20个token以上；想保留7B模型，就把上下文长度缩短到2048，减少KV缓存占用，并在Ollama环境变量里限制并发为1；只要手头有独显，哪怕显存只有6GB，也能通过OLLAMA_GPU_LAYERS把更多层放到GPU上，速度立刻翻几倍。别在CPU上硬撑大模型，那是浪费时间，也是初学时最容易钻的死胡同。

5.2 现象：检索出来的片段驴唇不对马嘴，多半是embedding与切块的问题

现象是用户问“发票多久能寄出”，系统返回的是“发票抬头填写规范”那段，答案自然不对。原因有两个方向：一是embedding模型对中文业务语义不敏感，通用英文模型会把“寄送”和“填写”当作相似概念；二是切块时把“发票寄送时间”和“填写抬头”混在同一个500字符的块里，向量平均后两头都抓不住。

解决要从两头一起改。embedding换成BGE-M3或m3e这类中文优化模型，几乎所有人第一次踩坑都是因为沿用默认的all-MiniLM-L6-v2，它在英文场景好用，中文差一大截。切块上把文档先按章节做预处理，再用500到800字符切块，同时把separators里加上“；”和“：”。如果这两步做完还偏，加一个重排器，比如bge-reranker，它对候选片段的排序比向量相似度稳定得多。

还可以在检索后加一个相似度阈值过滤。在as_retriever返回的结果里过滤掉分数低于0.6的片段，宁可返回“没有找到相关资料”，也不要硬凑一段让DeepSeek编。很多人不敢设阈值，怕拒答，但拒答至少是可控的，编造的答案才是真正事故。

5.3 现象：回答越来越短甚至重复，警惕上下文窗口被“垃圾”占满

我在一个演示项目里发现，连续聊五六轮之后，DeepSeek开始回答“抱歉，我无法从提供的资料中找到答案”，但同一个内容单独问又能答出来。原因是对话历史被原样塞进下一次请求，检索片段也在每轮重复拼接，长对话把上下文窗口的可用空间占满，早期关键内容被系统截断。

解决的办法有三条：第一，只保留最近两轮对话历史，不要无限累积；第二，每一轮传给模型的片段要做去重，去掉与当前问题无关的候选块；第三，在Prompt里明确要求“只根据最新提供的资料片段回答，不要依据对话历史推测”。如果你用LangChain，可以把RetrievalQA的memory关掉，改用外置会话存储，只在追问时携带上一轮摘要，而不是原文。

补充一个容易踩的细节：DeepSeek对话过程里带出来的“思考过程”也会占上下文。有些版本会在回答前输出大段推理内容，如果直接把它拼进下一轮，上下文会被成倍消耗。所以在服务端最好把输出里的推理部分截掉，只保留最终答案。

5.4 现象：多用户同时问，服务直接OOM，问题出在并发策略

团队把脚本封成FastAPI接口后，三个人同时点“生成”，服务内存从3GB飙到12GB，最后被系统杀掉。原因是每个请求都触发了QA链里的资源加载，虽然是同一个模型进程，但Ollama为每个请求分配独立上下文缓冲区，多个请求叠加后显存和内存一起爆。另一个常见原因是FAISS的load_local在每次请求时都重新执行，向量索引加载多次。

解决方法是全局单例加请求队列。把QA链、向量库、embedding模型都放在一个全局对象里，用asyncio.Lock排队；同时给Ollama设置环境变量OLLAMA_NUM_PARALLEL=1，让它串行处理请求。更重要的是提前量：只要确认并发超过5人，就放弃在Ollama层硬扛，换vLLM并用连续批处理能力。OOM的根因不是内存不够，是架构没按并发设计。

另一个经验是给接口设置超时和重试。DeepSeek本地模型生成长答案时，一个请求可能占几十秒，如果在网关层没有超时，客户端会重复提交，雪上加霜。可以在FastAPI里设置httpx.Timeout(60)，并做幂等请求key，防止重复提问被多次执行。

5.5 现象：文档里的表格和图表检索后全乱，解析链路要单独处理

企业知识库最不缺的就是制度和报表PDF，里面全是表格、流程图、带框的文字。直接丢给pypdf解析后，表格变成一行行“单元格文本流”，检索出来经常是“审批部门：后勤部审批流程：…”这样缺列错行的碎片，DeepSeek再聪明也还原不回去。

解决这类问题得把解析链路拆开。文本型PDF可以用pdfplumber提取表格结构，转成HTML或Markdown表格再入库；扫描型PDF要先OCR，中文扫描件建议用PaddleOCR，输出带坐标，配合版面分析恢复阅读顺序；图片里的图表则先用视觉大模型生成一段文字描述再入库。这一步没有捷径，但可以在选型阶段直接选RAGFlow这类平台，它内置了版面模型和OCR，能省掉大量自研解析的打磨时间。

最后提醒一个运维细节：解析后的文本要保留“来源文件、页码、章节标题”等元数据，而不是只存一个干巴巴的字符串。后面做审计、做引用、做问题排查都靠这些字段。没有元数据的知识库，出了问题连“这条内容从哪来的”都说不清，那就不是技术债，是合规债了。

6. 进阶技巧：用评估集把知识库从“能跑”调到“好用”

6.1 构造你的问题集：给检索召回率和答案准确率打分

跳过这个环节会让知识库卡在“演示很酷、上线没人用”。我现在的习惯是每个知识库至少准备30条真实业务问题，每条标注两个字段：一是期望命中的文档片段关键词，二是标准答案要点。然后写脚本跑一遍全量问答，统计检索命中率、答案准确率和延迟。

打分时我一般用三个指标：召回率（top-k里是否包含标注片段）、答案正确性（0/1/2人工打分）、响应延迟。这三项足够暴露绝大多数问题。比如召回率低于70%，就别调大模型了，回去改切块和重排；召回率不错但答案分低，再检查Prompt模板和上下文内容是否冲突。

6.2 三个性价比最高的干预点：重排、提示词模板与混合检索

第一个干预点是加一个Reranker。在向量库返回top20候选后，用bge-reranker重排取前4，召回稳定性和答案精度同时改善。第二个干预点是重写提示词模板，强制模型“只能引用提供的片段，片段没有就明确说不知道”，并在每段引用末尾标注片段编号。第三个干预点是混合检索：把BM25的精确匹配结果和向量语义结果合并，专有名词、合同编号这类内容靠BM25能救回很多。

具体Prompt模板可以写成：“你是企业内部知识助手。请只根据以下资料回答问题。如果资料没提到，直接回答不知道。引用时用[1][2]标注来源。”这个简单模板通常能把“胡说八道”的比率降到个位数。如果回答里出现“根据我的知识”这类字眼，说明模型跳出了资料范围，要回查模板或输入。

这三个干预点改完后，再重跑一遍评估集，你会发现之前60分的知识库能到85分上下。如果还不够，才考虑微调或换更大的DeepSeek模型。我现在每个项目上线前都会先扛一遍评估集，这个习惯帮我避开过不止一次“演示效果好、上线被打脸”的翻车。希望帮到你。

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