DeepSeek搭建内部文档智能检索系统指南

许多技术团队在评估DeepSeek时，会直接打开其网页版进行测试，并得出结论：它似乎不适合用于构建企业内部的文档智能检索系统。这个观察本身是正确的，但其背后的原因需要进一步澄清。

问题的核心在于，内部文档检索本质上是一个RAG（检索增强生成）闭环。这个闭环的关键在于本地数据的接入、向量化处理和语义召回能力，而不仅仅是调用一个问答接口。网页版作为一个纯对话界面，恰恰没有开放这些底层的文档索引与处理能力。

为何不能直接使用DeepSeek网页版构建企业知识库

简而言之，deepseek.com网页版的设计初衷是通用对话。它并未提供构建RAG系统所必需的完整环节：文档上传与管理、文本切片、向量化以及向量存储。你无法找到类似KnowledgeBase.add_documents()这样的方法。所有上传的文件仅被当作单次对话的上下文处理，无法建立持久化的索引。这意味着，本次上传的PDF文档内容，在下次提问时模型将无法“回忆”起来。

这直接导致了一些典型的错误现象：

• 在网页版上传一份PDF后，提问“这份文档里提到的验收标准是什么？”，返回结果往往是“未找到相关信息”。
• 试图用“请基于我上传的《采购流程V3.2》回答……”来引导，模型只会复述其训练数据中的通用流程，而非你文档中的具体内容。
• 误以为开启“联网搜索”功能就能搜索内部文件——该功能仅用于查询公网信息，与你服务器上的内部文档毫无关联。

必须自行搭建的三个核心组件：加载器、嵌入模型与向量数据库

要突破上述限制，必须自行搭建核心处理链路，其中三个组件缺一不可。

文档加载器（Loader）：负责将Word、PDF、Confluence页面等各种格式的文件，转换为结构化的文本块。

嵌入模型（Embedding Model）：负责将这些文本块转化为计算机能够理解的向量（一组数字）。

向量数据库（Vectorstore）：负责存储这些向量，并支持高效的相似度查询。

在具体技术选型上，可以参考以下建议：

• 加载器根据格式选择：处理PDF，简单的场景可使用PyPDF2，需要保留表格或标题结构的可以考虑unstructured；抓取Confluence内容，则应使用其最新的REST API配合requests库获取HTML后再进行清洗。
• 嵌入模型不必拘泥：不必非要使用OpenAI的text-embedding-ada-002，它需要联网且成本较高。完全可以改用开源的bert-base-chinese或m3e-base模型，通过pip install sentence-transformers即可轻松加载，支持离线运行。
• 向量数据库分阶段选用：初期数据量不大时，可使用Chroma，它轻量、单机即可运行且与Python生态结合紧密；当文档数量超过十万级，再考虑切换到Milvus这类支持分布式的向量数据库（需要Docker环境）。

如何使用LangChain与DeepSeek构建最小可行链路

搭建系统并非简单地安装一个DeepSeek包，而是需要使用LangChain作为“胶水”，将各个模块组合起来。在此架构中，DeepSeek扮演大语言模型（LLM）的角色，其他模块各司其职。整个链路的关键在于正确初始化retrieval_qa_chain。

实践中，有几个典型的配置错误需要避免：

• 直接传递本地模型路径model_path="./models/deepseek-7b-q4.bin"给LLM，却忘记配置device="cuda"，导致显存溢出（OOM）。
• 使用Chroma.from_documents()时没有设置persist_directory参数，导致Python进程重启后，辛苦构建的索引全部丢失。
• 查询时没有设置return_source_documents=True参数，导致虽然获得了答案，却完全无法追溯答案来源于哪份文档的哪一页，可追溯性为零。

以下是一个精简的可运行代码示例（省略了异常处理，专注于核心逻辑）：

from langchain.llms import DeepSeek
from langchain.chains import RetrievalQA
from langchain.embeddings import HuggingFaceEmbeddings
from langchain.vectorstores import Chroma
from langchain.document_loaders import DirectoryLoader

# 1. 加载文档（假设所有 PDF 存放在 ./docs/）
loader = DirectoryLoader("./docs/", glob="*/*.pdf")
docs = loader.load()

# 2. 初始化嵌入模型（支持离线运行）
embeddings = HuggingFaceEmbeddings(model_name="m3e-base")

# 3. 构建向量库（自动持久化到 ./chroma_db/）
vectorstore = Chroma.from_documents(docs, embeddings, persist_directory="./chroma_db/")
vectorstore.persist()  # 显式保存

# 4. 初始化 DeepSeek LLM（注意 device 和 model_path 配置）
llm = DeepSeek(model_path="./models/deepseek-7b-q4.bin", device="cuda")

# 5. 绑定检索器与 LLM
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=vectorstore.as_retriever(search_kwargs={"k": 3}),
    return_source_documents=True
)

# 6. 执行查询
result = qa_chain({"query": "采购合同审批需要几个部门会签？"})
print(result["result"])
for doc in result["source_documents"]:
    print(f"来源: {doc.metadata['source']}, 页码: {doc.metadata.get('page', '')}")

处理OCR文档（扫描件/图片）必须单独使用DeepSeek-OCR-2

对于扫描版PDF或图片格式（如PNG、JPG）的文档，普通的文本加载器是完全无效的。因为这些文件本质上是像素阵列，而非文本容器。强行使用PyPDF2读取，得到的只会是空字符串或乱码。

正确的处理路径分为两步：

• 首先，使用专门的DeepSeek-OCR-2模型，将图像转换成带有结构信息（如标题层级、表格、代码块）的Markdown文本。
• 然后，将这些生成的Markdown文件，再送入上述的DirectoryLoader流程进行处理。

这里有一个关键点：不要试图将OCR识别和向量化嵌入（embedding）放在同一个进程里串行运行。DeepSeek-OCR-2是重度的GPU计算任务，而embedding推理可能涉及CPU或GPU。混在一起运行极易导致显存溢出或进程卡死。

在部署时需要注意：

• DeepSeek-OCR-2必须通过Docker启动（其最新镜像已预装好CUDA驱动和FlashAttention等依赖），直接在裸Python环境中通常无法运行。
• OCR的输出目录需要与后续加载器（Loader）的输入目录对齐。例如，设定OCR结果输出到./ocr_output/，那么加载器就去读取./ocr_output/下的文件。
• 当扫描件质量较差（模糊、倾斜、有阴影）时，务必将DeepSeek-OCR-2的layout_analysis参数设为True，否则表格的识别准确率会大幅下降。

最后，也是最容易被忽略的一点：元数据（metadata）打标是必须的，而非可选的。仅有向量是不够的，必须清楚地记录每一段向量对应的原始文档、页码以及所属业务部门等信息。否则，检索系统即使找到了相似内容，你也无法定位到原始文件，整个系统的实用性将大打折扣。在生产环境中，完备的元数据是保证检索结果可追溯、可管理的强制要求。