在信息爆炸的时代，自动生成文档摘要和从文档中提取问题答案变得尤为重要。现代企业每天产生大量报告、日志和知识库，完全依赖人工阅读几乎不可能。

基于大语言模型（LLM）的文档摘要，可以把海量信息压缩成简洁、可执行的要点；而基于 LLM 的问答（QA）能力，则让用户可以用对话方式查询长文档中的关键信息。

例如，2025 年初的一次 Enterprise RAG Challenge，就要求 AI 使用检索增强生成（RAG）技术，从 60 多页的公司年报中回答企业特定问题，凸显了在长文档上做问答的现实需求。

DeepSeek 系列模型在 2025 年已经非常适合这类场景。DeepSeek 是一套开源的前沿大模型家族，以长上下文处理能力和强推理能力著称。

其模型支持最高 128K token 的上下文窗口（远超常见模型的几千 token），可以一次性“吃下”非常长的文本。同时，它们采用链式思维（Chain-of-Thought）推理方式，能够把复杂问题拆解成多步推理。

其中的推理模型 DeepSeek-R1 在 FRAMES 等长上下文 QA 基准测试中表现突出，展现了强大的文档分析能力。无论是快速生成论文摘要，还是搭建基于知识库的智能问答助手，DeepSeek 都能提供可靠的技术基础。

本文将围绕“文档摘要”和“文档问答”两个核心场景，介绍如何使用 DeepSeek：先简要梳理适合这些任务的模型，再说明如何通过 Hugging Face、官方 API 或本地部署来使用它们；随后给出一个摘要示例和一个基于 RAG 的 QA 示例，最后分享一些性能与效果优化技巧，包括提示词设计和模型局限处理等。

DeepSeek 模型概览

DeepSeek 提供了多种针对不同任务优化的模型，适合做摘要和 QA 的主要有：

  • DeepSeek-V3.1 – 通用 MoE 大模型（671B 参数）
    V3.1 是 DeepSeek 的旗舰 Mixture-of-Experts（MoE）模型，于 2025 年 8 月发布，总参数量 671B（每个 token 实际激活约 37B），支持 128K 上下文。它是一个“混合模式”模型：既可以直接给出简洁回答，也可以进入逐步推理模式。通过不同提示格式，你可以让它表现得像简洁的 DeepSeek-V3（适合直接摘要），也可以像 DeepSeek-R1 那样展开详细推理（适合复杂 QA）。MoE 架构让它在保持巨大容量的同时，推理成本相对可控。

  • DeepSeek-R1 – 强推理模型（671B）
    DeepSeek-R1 基于 V3 进行强化学习训练，专门针对逻辑推理、复杂问答和问题求解进行了优化。它会在内部先生成一段链式思维，再给出最终答案，因此在需要多步推理或跨段信息综合的 QA 任务上表现尤为突出。R1 在长上下文 QA 和指令跟随基准上普遍优于基础 V3。代价是输出更长、速度略慢，但换来更高的准确率和可解释性。

  • DeepSeek-Coder – 代码与技术场景模型
    DeepSeek-Coder 系列专注于编程相关任务，如代码生成、代码摘要和技术问答。最新的 DeepSeek-Coder v2 拥有 236B 参数，训练数据覆盖 80+ 种编程语言、6 万亿 token。如果你的“文档”是代码仓库或技术手册，可以用 Coder 来做代码文件摘要或软件文档 QA，它在代码和数学推理上有明显优势。

  • 蒸馏版 DeepSeek 模型 – 更小但保留推理能力
    671B 级别模型对硬件要求极高，因此 DeepSeek 团队提供了多种蒸馏版模型，参数规模从 1.5B 到 70B 不等。它们通过把 R1 产生的 80 万条高质量推理样本蒸馏到更小的开源模型（如 Llama 3、Qwen）中，保留了相当一部分链式思维能力。比如 DeepSeek-R1-Distill-Qwen-7B/14B，在单卡 GPU 上就能跑出不错的推理和 QA 效果，非常适合资源有限的场景。

整体来说：

  • 需要兼顾长文档摘要和 QA，且硬件充足：优先考虑 DeepSeek-V3.1。
  • 需要最高推理能力和可解释性：选择 DeepSeek-R1。
  • 文档是代码或技术资料：使用 DeepSeek-Coder。
  • 硬件有限或需要大规模部署：使用各类 蒸馏版 DeepSeek 模型。

这些模型均为开源，可自由集成到你的数据处理与应用流水线中。

部署与访问方式

根据资源和需求不同，你可以通过多种方式使用 DeepSeek：Hugging Face、官方 API，或本地自建推理服务。

通过 Hugging Face 与官方 API 使用

最快体验 DeepSeek 的方式是使用 Hugging Face Hub。DeepSeek 团队在 Hugging Face 上的 deepseek-ai 组织下发布了各类模型权重，包括基础模型和对话模型（V3、V3.1、R1 等）。

你可以用 Transformers 库几行代码加载模型和 tokenizer，也可以使用 Hugging Face 的 Inference API 直接通过 HTTP 调用。

在生产环境或大规模使用时，可以考虑 DeepSeek 官方 API。其接口风格与 OpenAI 类似，例如聊天补全端点：

https://api.deepseek.com/v1/chat/completions

你只需指定模型名称（如 "deepseek-chat"）、输入消息，并携带 API Key 即可获得回复。API 支持温度、最大生成长度等常见参数，适合不想自建推理服务的团队。

如何选择？

  • 没有大 GPU、处于原型阶段：优先使用 官方 API 或 Hugging Face Inference API。
  • 需要完全自托管、控制成本或做深度集成：从 Hugging Face 下载权重，结合本地推理框架部署。

很多开发者会先在 Notebook 中用 Hugging Face 模型快速试验，然后再根据需求切换到官方 API 或本地部署方案。

本地推理：vLLM、LMDeploy 与 Transformers

如果选择自托管 DeepSeek 模型，建议使用高效的推理框架，而不是直接用最朴素的 Transformers 循环生成。

常见选项包括：

  • Transformers（Hugging Face）
    直接用 AutoModelForCausalLM.from_pretrained("deepseek-ai/DeepSeek-V3.1-Chat") 即可加载模型，再用 generate 或 pipeline 生成文本。优点是简单、生态成熟，适合开发和小规模使用。但在超大模型和高并发场景下，性能可能不如专门的推理引擎。

  • vLLM
    vLLM 是专为大模型推理优化的引擎，擅长处理超长上下文和多并发请求。它通过连续批处理和 PagedAttention 等技术，大幅提升吞吐和显存利用率。如果你打算充分利用 DeepSeek 的 128K 上下文能力，或要服务大量请求，vLLM 是非常合适的选择。

  • LMDeploy
    LMDeploy 是另一款开源大模型部署工具，更偏向高吞吐优化。在一些基准中，它在 QPS 上可比 vLLM 高出约 1.8 倍，适合多用户 QA 服务或聊天机器人场景。它支持多卡推理、量化等多种优化手段。

  • 其他方案
    还可以使用 Hugging Face Text Generation Inference（TGI）、DeepSpeed Inference，或像 Ollama 这样的封装工具（在 macOS/Linux 上一条命令即可运行模型）。DeepSeek 社区也有不少基于 Ollama + LangChain 的示例。

开发阶段用 Transformers 足够；上线后可根据需求迁移到 vLLM、LMDeploy 或 TGI 等更高效的方案。

硬件需求概览

运行最前沿的 DeepSeek 大模型，对硬件要求不低，尤其是 671B 级别的 V3.1 和 R1。

  • 671B MoE 模型在实际部署时，通常需要多张大显存 GPU。官方参考配置大约是 8 张 NVIDIA H200（141GB 显存） 才能比较从容地加载和服务完整模型。
  • 这远超普通消费级显卡能力，因此不适合在单卡家用 GPU 上直接跑完整 V3.1。

好消息是，蒸馏版模型（1.5B–70B）对硬件友好得多：

  • 7B / 13B 模型：单张现代消费级 GPU 即可运行（甚至可以在 CPU 上跑，只是较慢）。
  • 70B 模型：规模类似 Llama2-70B，经过优化后可在单张 80GB GPU 上运行，或拆分到两张 48GB GPU 上。
  • 通过 4bit 量化（如 QLoRA、GPTQ），还能进一步压缩显存占用，损失有限的效果换来更低成本。

如果要使用 128K 上下文，还需注意：

  • 显存消耗不仅来自模型权重，还来自注意力的 KV 缓存，输入越长占用越高。
  • vLLM 等框架可以通过分页和卸载策略缓解，但超长输入仍然会带来明显的延迟和资源消耗。

总之，要根据硬件选择合适的模型：本地开发或大规模部署时优先用小模型；如果追求极致效果且有 GPU 集群，则可以考虑完整的 V3.1 / R1；否则可以使用官方 API 或结合量化与高效推理框架来降低门槛。

文档摘要场景

下面以一个示例演示如何用 DeepSeek 对长文档进行摘要。典型需求包括：

  • 压缩论文或技术报告为简明要点；
  • 为管理层生成报告的执行摘要；
  • 为长文章生成 TL;DR。

难点在于：

  • 文档长度可能超过模型上下文；
  • 希望尽量不遗漏关键信息。

常用解决方案是 “分块 + 汇总（chunk-and-merge）”：

  1. 把长文档切分成若干段落（chunk）；
  2. 分别对每个 chunk 做局部摘要；
  3. 再对所有局部摘要做一次总摘要，得到最终结果。

示例：使用 DeepSeek 对长文档做分块摘要

下面是一个基于 Hugging Face Transformers 的 Python 伪代码示例，演示如何对长文档进行分块摘要：

from transformers import AutoTokenizer, AutoModelForCausalLM

# 1. 加载 DeepSeek 模型与 tokenizer（示例使用 14B 蒸馏模型）
model_name = "deepseek-ai/DeepSeek-R1-Distill-Qwen-14B"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    device_map="auto",
    torch_dtype="auto",
)

# 2. 读取长文档并按 ~4096 token 分块
text = open("long_document.txt", "r").read()
tokens = tokenizer(text, return_tensors="pt").input_ids[0]
chunk_size = 4096
chunks = [tokens[i:i+chunk_size] for i in range(0, len(tokens), chunk_size)]

partial_summaries = []
for chunk_tokens in chunks:
    chunk_text = tokenizer.decode(chunk_tokens)
    prompt = f"Summarize the following document section:\n{chunk_text}\n\nSummary:"
    inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
    outputs = model.generate(**inputs, max_new_tokens=200, temperature=0.3)
    summary = tokenizer.decode(outputs[0], skip_special_tokens=True)
    partial_summaries.append(summary.strip())

# 3. 对所有局部摘要再做一次汇总
combined_text = " ".join(partial_summaries)
final_prompt = (
    "Combine these section summaries into a coherent overall summary:\n"
    f"{combined_text}\n\nFull Summary:"
)
inputs = tokenizer(final_prompt, return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_new_tokens=300, temperature=0.3)
final_summary = tokenizer.decode(outputs[0], skip_special_tokens=True)
print("Final Summary:\n", final_summary)

这个流程的关键点：

  • 使用蒸馏版 14B 模型，单卡即可运行；有更强硬件时可以替换为 V3.1 等更大模型；
  • 先把整篇文档编码成 token，再按 4096 token 分块，保证每块都能放进模型上下文；
  • 对每个分块使用明确的提示词，如“Summarize the following document section: … Summary:”，并设置较低温度（0.3）以提高稳定性和事实性；
  • 最后把所有局部摘要拼接，再让模型做一次“摘要的摘要”，得到整体摘要。

这种分层摘要方式可以：

  • 避免因上下文过长导致模型“遗忘”前文；
  • 让模型在每次推理时专注于局部内容，提高细节覆盖率；
  • 通过最终汇总保证整体结构连贯。

提升摘要质量的实用技巧

  1. 调整分块大小与重叠

    • 可以在分块时设置一定重叠（如 500 token），避免关键信息刚好落在块边界被忽略；
    • 分块过小会丢失上下文，过大又会让模型难以兼顾细节，需要在两者间平衡。

  2. 明确摘要风格与长度

    • 想要偏“摘录式”（尽量保留原文表述）时，可以提示“提取关键要点”；
    • 想要更自然的“改写式”摘要，则可以提示“用通俗语言重写并概括”；
    • 可以直接指定格式和长度，如“用 5 个要点总结”“不超过 100 字”等。

  3. 优化提示词

    • 在提示中明确说明关注重点，例如“重点说明研究结论和实验结果”；
    • 使用类似“Summary:”这样的标记，引导模型从该位置开始输出摘要；
    • 如果第一次结果不理想，可以迭代调整提示词，往往能显著改善效果。

  4. 迭代精炼

    • 先生成略长的“详细摘要”，再让模型在此基础上压缩为更短版本，通常能兼顾信息完整性与简洁性；
    • 如果发现遗漏某些关键信息，可以追加提示“在摘要中补充关于 X 的细节”。

  5. 进行质量校验

    • 对重要文档，建议人工抽查或复核关键数字、时间、人名等；
    • 可以先让模型从原文中抽取关键实体和数值，再检查摘要是否与之吻合；
    • 若有参考摘要，可用 ROUGE、BERTScore 等指标做自动评估。

通过这些方法，结合 DeepSeek 的长上下文能力和分块汇总策略，可以对几乎任意长度的文本生成高质量摘要。

文档问答（QA）场景

接下来看看如何用 DeepSeek 搭建基于文档的问答系统。目标是：

用户提出问题，AI 从指定文档或文档集合中找到答案并用自然语言作答。

常见两种方式：

  1. 直接提示（Direct Prompting）：把文档（或其中一部分）和问题一起喂给模型；
  2. 检索增强生成（RAG）：先用向量检索找到与问题最相关的文档片段，再把这些片段和问题一起交给模型回答。

对于短文档，方式 1 足够。但在长文档或文档集合场景下，每次都把全文塞进上下文既低效又容易超出长度限制，因此 RAG 几乎是必选方案。

RAG 的典型流程是：

文本向量化 → 存入向量库 → 用户提问 → 对问题向量化 → 检索最相关的 K 个片段 → 把这些片段 + 问题一起交给 LLM → 生成答案。

下面用 LangChain + DeepSeek 搭建一个简化版 RAG QA 示例。

示例：基于 LangChain 的 DeepSeek RAG 问答

"""
RAG (检索增强生成) 示例：
- LangChain (社区组件)
- FAISS 向量库
- Hugging Face Embeddings + 生成管线
- DeepSeek 模型 (通过 Transformers)

安装示例：
pip install -U langchain langchain-community langchain-huggingface faiss-cpu transformers accelerate sentence-transformers
"""

from __future__ import annotations

from pathlib import Path
from typing import List

from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import FAISS
from langchain_huggingface import HuggingFaceEmbeddings, HuggingFacePipeline
from langchain.chains import RetrievalQA

from transformers import AutoTokenizer, AutoModelForCausalLM, pipeline


def load_text_file(path: str) -> str:
    p = Path(path)
    if not p.exists():
        raise FileNotFoundError(f"File not found: {p.resolve()}")
    return p.read_text(encoding="utf-8", errors="ignore")


def split_document_into_chunks(
    file_path: str,
    chunk_size: int = 1000,
    chunk_overlap: int = 150,
) -> List[str]:
    """使用 LangChain 官方文本切分器进行分块。"""
    doc_text = load_text_file(file_path)

    splitter = RecursiveCharacterTextSplitter(
        chunk_size=chunk_size,
        chunk_overlap=chunk_overlap,
        separators=["\n\n", "\n", " ", ""],
    )

    chunks = splitter.split_text(doc_text)
    return [c.strip() for c in chunks if len(c.strip()) > 50]


def build_vector_store(texts: List[str]) -> FAISS:
    """使用 SBERT 向量模型构建 FAISS 向量索引。"""
    embedder = HuggingFaceEmbeddings(
        model_name="sentence-transformers/all-MiniLM-L6-v2",
    )

    return FAISS.from_texts(texts, embedding=embedder)


def build_deepseek_llm(
    model_name: str,
    max_new_tokens: int = 512,
    temperature: float = 0.2,
):
    """加载 DeepSeek 模型并封装为 LangChain LLM。"""
    tokenizer = AutoTokenizer.from_pretrained(model_name, use_fast=True)

    model = AutoModelForCausalLM.from_pretrained(
        model_name,
        device_map="auto",
        torch_dtype="auto",
    )

    gen_pipe = pipeline(
        task="text-generation",
        model=model,
        tokenizer=tokenizer,
        max_new_tokens=max_new_tokens,
        do_sample=(temperature > 0),
        temperature=temperature,
    )

    return HuggingFacePipeline(pipeline=gen_pipe)


def main():
    # 1) 加载并分块文档
    texts = split_document_into_chunks("my_document.txt")

    # 2) 构建向量库与检索器
    vector_store = build_vector_store(texts)

    retriever = vector_store.as_retriever(
        search_kwargs={
            "k": 3,  # 每次检索返回最相关的 3 个片段
        }
    )

    # 3) 加载 DeepSeek 模型
    MODEL_NAME = "deepseek-ai/DeepSeek-R1-Distill-Qwen-7B"
    llm = build_deepseek_llm(MODEL_NAME)

    # 4) 构建 RetrievalQA 链
    qa_chain = RetrievalQA.from_chain_type(
        llm=llm,
        retriever=retriever,
        chain_type="stuff",
        return_source_documents=True,
    )

    # 5) 提问
    query = "What are the main findings in the document?"
    out = qa_chain.invoke({"query": query})

    print("Q:", query)
    print("A:", out["result"])

    print("\n--- Retrieved Chunks ---")
    for i, d in enumerate(out["source_documents"], start=1):
        snippet = d.page_content[:350].replace("\n", " ")
        print(f"[{i}] {snippet}...")


if __name__ == "__main__":
    main()

这个 RAG 示例的核心步骤：

  • 文档分块：类似摘要场景，把长文档切成若干自洽的小段，便于后续检索和作为上下文提供给模型；
  • 向量化与向量库：使用 HuggingFaceEmbeddings（MiniLM）把每个文本块编码为向量，并存入 FAISS 索引，实现语义级相似度检索；
  • 加载 DeepSeek 模型：通过 Transformers 加载蒸馏版 DeepSeek 模型，并用 HuggingFacePipeline 封装为 LangChain 可用的 LLM；
  • RetrievalQA 链：LangChain 的 RetrievalQA 会在内部完成“检索 + 拼接上下文 + 调用 LLM”这一整套流程；
  • 问答：用户输入问题后，系统检索出最相关的若干文本块，把它们与问题一起交给 DeepSeek 生成答案，并可返回检索到的原文片段以便溯源和调试。

通过这种方式，模型每次只看到与问题高度相关的少量片段，而不是整本“书”，既提高了准确率，也避免了上下文溢出。

DeepSeek 在 QA 中的优势与注意点

  • 强推理与可解释性
    使用 DeepSeek-R1 或 V3.1 的“思考模式”时，模型会先在内部进行链式推理，再给出答案。若提示中使用 标记，它甚至会把推理过程显式输出，便于你理解“答案从何而来”。在实际产品中，可以在后处理阶段把 部分隐藏，仅展示最终答案。

  • 减少幻觉的关键：检索质量 + 提示约束
    RAG 的准确性高度依赖检索是否找到了正确片段。如果检索不到关键信息，模型再强也难以给出正确答案。可以通过：

    • 调整分块策略（块大小、重叠）；
    • 选择更适合领域的向量模型（如代码、法律、医学等专用 embedding）；
    • 在提示中明确要求“只根据给定上下文回答，如无法从中得到答案，请回答不知道”。

  • 模型选择

    • 问题需要跨段、多步推理：优先用 DeepSeek-R1 或 V3.1 的推理模式；
    • 问题多为简单事实查找：可以用更快的 V3 风格模型或蒸馏版模型，节省资源。

提升 DeepSeek 摘要与 QA 效果的实用建议

1. 精心设计提示词与角色

  • 摘要任务中，明确说明：摘要长度、关注重点、输出格式（段落/要点列表等）；

  • QA 任务中，可以在系统提示中设定角色：

    “你是一个只根据给定上下文回答问题的助手，如果上下文中没有答案，请明确说明不知道。”

  • 对于 DeepSeek-V3.1，可以通过特定模板触发“思考模式”；对 R1，则通常通过在用户问题后加入 \n 来引导其展开推理；

  • 若只需要简洁答案，不希望输出推理过程，则不要使用 `` 标记，或选择非推理版模型。

2. 充分利用 MoE 架构

DeepSeek 的 MoE 架构对用户来说大多是“透明”的，但在部署时要注意：

  • 确保推理框架正确加载所有专家分片（多卡部署时尤为重要）；
  • 尽量启用批处理（batching），让多个请求并行处理，以更好发挥 MoE 的吞吐优势。

3. 监控 token 使用与成本

长上下文和链式思维会显著增加 token 消耗：

  • 使用 API 时要关注 token 计费，避免无谓地把整篇文档塞进上下文；
  • 合理设置 max_tokens，防止模型输出过长；
  • 对 R1 的思考阶段，可以在提示中要求“简要推理”，或在系统层面限制 `` 部分长度。

4. 处理模型局限与幻觉

即便有 RAG 和良好提示，LLM 仍可能出现幻觉。建议：

  • 在关键场景中增加“自检”步骤，让模型在第二轮检查自己的回答是否被上下文支持；
  • 强调“如果不确定就说不知道”的指令；
  • 对敏感或高风险领域（医疗、金融决策等），保留人工审核环节。

如果发现模型频繁拒答或给出安全性提示，可能是触发了模型的安全策略，需要在提示设计或业务逻辑上做相应调整。

5. 逐步优化与扩展

  • 从小模型或官方 API 开始快速验证流程与提示设计；
  • 确认效果后，再迁移到更大模型或自建推理服务；
  • 对批量摘要任务，可结合 vLLM/LMDeploy 做高效并行处理，并使用 FP16/BF16 等混合精度加速推理；
  • 关注 DeepSeek 新版本（如引入稀疏注意力的 DeepSeek-V3.2-Exp 等），可能在同等硬件下获得更长上下文或更高性能。

6. 在你的领域内做真实评测

不同领域文档（法律、金融、医学、代码等）差异很大，建议：

  • 用真实业务文档和典型问题做小规模评测；
  • 对比不同模型、不同提示和不同检索策略的效果；
  • 若有条件，可在领域数据上做轻量微调或指令微调，以进一步提升表现。

总结

在 2025 年，文档摘要和基于文档的问答已经成为数据密集型工作流中的关键能力。DeepSeek 通过开源的大规模长上下文模型，让这些能力变得更易获取和定制。

  • 在摘要方面，DeepSeek-V3.1 及其蒸馏版可以对几十页甚至上百页的文档进行分块与分层摘要，输出结构清晰、重点突出的总结；
  • 在问答方面，结合 RAG 流水线，DeepSeek 能够在企业内部文档、年报、技术手册等私有数据上构建高质量 QA 助手，大幅减少幻觉，提升答案可追溯性。

本文从模型选择、部署方式讲起，给出了一个分块摘要示例和一个基于 LangChain 的 RAG QA 示例，并分享了提示词设计、推理模式选择、token 成本控制和幻觉防控等实战经验。

DeepSeek 在这些任务上的核心优势包括：

  • 灵活性：可在“直接回答”和“链式推理”之间自由切换；
  • 长上下文：最高 128K token，上下文极长；
  • 开源可控：可自托管、可微调，不被单一闭源 API 锁定。

下一步，你可以：

  1. 选取几篇典型文档，用 DeepSeek 做摘要，观察效果与可读性；
  2. 按文中 RAG 示例，搭建一个小型 QA Demo，接入你自己的文档；
  3. 在真实业务问题上迭代提示词和检索策略，逐步优化系统表现。

通过合理的工程实践和持续调优，DeepSeek 可以成为你处理长文档、构建智能搜索与问答系统的核心引擎，让“读文档”和“找答案”这两件耗时的工作变得高效而轻松。