DeepSeek R1 在首次发布时就展现出了强大的推理能力。在这篇博客文章中，我们详细分享了使用 DeepSeek R1 构建检索增强生成（Retrieval-Augmented Generation，RAG）系统的经验，专门针对法律文档领域。

我们选择法律文档是因为法律专业人士通常面临一项艰巨的任务：在大量案例、法规和法律评论中进行检索。即使是最用心的研究，也可能因为难以找到正确的文档而受到阻碍，更不用说准确地总结内容了。这正是 RAG 能大显身手的领域（另请参见 Harvey AI）。

我们基于庞大的法律文档数据集构建了 RAG，采用了 DeepSeek R1 和 Qwen2 作为嵌入模型。我们开源了整个 RAG 构建流程（由 vLLM 和 SkyPilot 提供支持），并分享了一些宝贵的经验——哪些方法有效，哪些无效。

想要亲自体验 🔥？ 试试我们的在线演示：点击这里。

我们已开源该 RAG 构建流程 点击这里查看。欢迎探索我们如何结合 vLLM + SkyPilot 以实现快速、稳定且可扩展的性能。

为什么要在法律文档上构建 RAG？

在法律等对准确性和可追溯性要求极高的领域，检索增强生成（RAG）至关重要。通过将专门的检索器与强大的大语言模型（LLM）生成器相结合，我们可以获得最佳效果：

1. 高相关性文档的检索
2. 具有推理能力的文本生成
3. 通过直接引用减少幻觉

为构建此 RAG，我们使用了：

• pile-of-law/pile-of-law 数据集的一个子集（专注于法律建议）；
• ChromaDB 作为向量存储库，用于存储和查询嵌入；
• Qwen2 作为检索嵌入模型；
• DeepSeek R1 作为最终答案生成模型。

整个系统运行在 vLLM 之上，并可通过 SkyPilot 无缝部署到任何云端，以确保最佳 GPU 可用性和成本效益。开源的完整 RAG 构建流程可在此处获取。

宝贵经验：注意事项与禁忌

1. 不要使用 DeepSeek R1 进行检索

尽管 DeepSeek R1 具有卓越的推理能力，但它不适合用于生成嵌入——至少目前不适合。

我们发现，与专门的嵌入模型 Alibaba-NLP/gte-Qwen2-7B-instruct（目前在 MTEB 排行榜 上排名最高的嵌入模型）相比，DeepSeek R1 生成的嵌入效果较差。

我们使用这两个模型分别为数据集生成嵌入，并构建两个向量数据库。然后，对这两个模型使用相同的查询，并检索各自向量数据库中最相似的前 5 个嵌入。

查询： 我收到了一张关于债务纠纷的小额索赔法庭传票，我应该如何准备？

为什么会有差异？

在上表中，DeepSeek R1 的检索结果明显较差。这是为什么呢？

我们认为，根本问题在于 DeepSeek R1 的训练方式。DeepSeek R1 的架构主要侧重于推理，强调顺序思维和逻辑连接。这意味着 DeepSeek R1 并不会将文档映射到一个语义空间中。

相比之下，Qwen2 变体 (gte-Qwen2-7B-instruct) 专门针对语义相似性任务进行训练，能够创建一个高维空间，使概念上相似的文档紧密聚类在一起，而不受具体措辞的影响。

这种训练方式的差异意味着 Qwen2 在捕捉查询意图方面表现出色，而 DeepSeek R1 有时会遵循推理路径，导致检索到的结果在主题上相关但实际上无关紧要。

除非对 DeepSeek R1 进行嵌入微调，否则不应将其用作 RAG 的检索嵌入模型。

2. 使用 R1 进行生成：推理能力令人印象深刻

尽管 R1 在嵌入方面存在一定困难，但我们发现它的 生成 能力非常出色。通过利用 R1 的链式思维（chain-of-thought）方法，我们观察到：

• 更强的连贯性： 该模型能够综合多个文档的信息，并清晰地引用相关段落。
• 减少幻觉： R1 在内部“自言自语”进行推理，通过你的数据验证每一个结论。

让我们来看几个示例：

示例 1：解除租约

问题： 我想解除租约，但房东不允许我这样做。

示例 2: 小额索赔法院

问题: 我收到了一张关于争议债务的小额索赔法院传票。我应该如何准备？

从这些示例中，我们观察到 DeepSeek R1 具有卓越的推理能力。其思维过程清晰地展示了如何从源法律文件中得出结论：

• R1 首先构建了一个 连贯的模型 来理解法律问题，这体现在其详细的推理过程中：首先，我记得关于提前终止罚款的内容……文档 1 提到…… 这种“先推理后检索”的方法使模型能够在检索之前系统地连接多个来源的概念。
• 在处理租赁终止或小额诉讼法院等复杂情境时，我们观察到 R1 不会产生幻觉 ，而是明确地梳理其对每个文档的理解（综合来看……）。
• 最后，生成器会使用精确的引用来解释其推理过程，将结论与来源联系起来。这确保了从问题到推理再到答案的清晰链条，保证了严谨性和可访问性。

我们尝试了各种法律查询，发现模型不仅能够从源文件中提取信息，还能学习并推理其内容。

结论： 在问答和摘要任务中，R1 是逐步法律推理的“金矿”。将其用于生成阶段，几乎不会让你失望。

3. 工程仍然重要

提示词设计

高级推理能力并不会消除对精心设计的提示词的需求。我们发现，在提示词中明确指引对于以下方面至关重要：

• 促使 文档引用 贯穿整个生成答案。
• 防止幻觉 ，采用“引用来源或说明不知道”的方式。
• 将最终答案结构化，使其更易读 。

在实验过程中，我们构建了以下提示词：

你是一个帮助分析法律文件及相关内容的 AI 助手。在回复时，请遵循以下准则：
- 在提供的搜索结果中，每个文档的格式为 [Document X begin]...[Document X end]，其中 X 表示文档的编号。
- 使用 [citation:X] 形式的引用格式，其中 X 是文档编号，并将引用放在相关信息之后。
- 在整个回答中加入引用，而不仅仅是结尾处。
- 如果信息来自多个文档，请使用多个引用，例如 [citation:1][citation:2]。
- 不是所有搜索结果都相关——请评估并仅使用相关信息。
- 对于较长的回答，请将内容结构化，以段落或部分的形式呈现，以提高可读性。
- 如果在提供的文档中找不到答案，请直接说明，而不要编造信息。
- 一些文档可能是非正式讨论或 Reddit 帖子——请根据内容调整解读方式。
- 让回答尽可能多地包含引用。
首先，在 <think> 标签中解释你的思维过程。
然后，在思维过程之后提供最终答案。

文档分块

此外，我们发现 有效的文档分块对于准确的文档检索至关重要。对文档进行分块有助于使每个嵌入更精确地表示特定主题，并减少每次嵌入生成所需的 Token 数量。

我们使用基于句子的分割（通过 NLTK）来对文档进行分块。同时，每个分块的开头和结尾都会包含与相邻分块重叠的内容。这有助于模型更好地理解部分引用，而不会丢失整体语境。以下是用于文档分块的代码：

def chunk_document(document, chunk_size=2048, overlap=512):
"""使用基于句子的分割方法将文档拆分为重叠的块。"""
text = document['text']
chunks = []
# 先按句子分割
sentences = nltk.sent_tokenize(text)
current_chunk = []
current_length = 0
for sentence in sentences:
sentence_len = len(sentence)
# 如果加入此句子后会超出块大小，则保存当前块
if current_length + sentence_len > chunk_size and current_chunk:
chunk_text = ' '.join(current_chunk)
chunks.append({
'id': document['id'],
'name': document['name'],
'content': document['text'],
'chunk_start': len(' '.join(current_chunk[:-(2 if overlap > 0 else 0)])) if overlap > 0 else 0,
# 其他元数据字段...
})
# 保留最后几句话作为重叠部分
overlap_text = ' '.join(current_chunk[-2:])  # 保留最后 2 句
current_chunk = [overlap_text] if overlap > 0 else []
current_length = len(overlap_text) if overlap > 0 else 0
current_chunk.append(sentence)
current_length += sentence_len + 1  # +1 代表空格

要点总结：

1. 使用 NLTK 进行基于句子的 Token 分割，而非基于字符的分割。
2. 通过在块之间保留重叠句子来保持文档上下文。

4. vLLM 高效且快速

由于法律文档数据量庞大，为 RAG 生成嵌入可能需要较长时间。

最初，我们使用了 HuggingFace 的 sentence_transformer。我们先在 Nvidia L4 GPU 上运行，但遇到了常见的“CUDA 内存不足”错误。之后，我们尝试了 Nvidia A100，发现 sentence_transformer 需要 57GB DRAM 来加载完整的 Alibaba-NLP/gte-Qwen2-7B-instruct 模型。

我们改用 vLLM，这是一种高吞吐量、节省内存的 LLM 推理与服务引擎。

使用 vLLM 后，我们可以在标准 Nvidia L4 GPU（约 24GB DRAM）上运行模型。相比之下，L4 的价格远低于 A100：在 GCP 上，Nvidia L4 约 $0.7/小时，而 Nvidia A100 至少 $2.9/小时。

在 Nvidia A100（80GB DRAM）上比较 vLLM 和 sentence transformer，我们发现 vLLM 生成 Qwen2 嵌入的速度提高了 5.5 倍。

在处理 10,000 份法律文档（共 15,000 个分块）时：

• 标准 sentence transformer 处理时间：约 5.5 小时
• vLLM 处理时间：约 1 小时

以下是用于在 vLLM 上运行 Alibaba-NLP/gte-Qwen2-7B-instruct 以生成嵌入的 SkyPilot YAML 配置：

name: compute-legal-embeddings
resources:
# vLLM 需要 ~24GB DRAM GPU，SentenceTransformer 需要 57GB
accelerators: {L4:1, A100:1} 
envs:
START_IDX: ${START_IDX}
END_IDX: ${END_IDX}
file_mounts:
/output:
name: my-bucket-for-embedding-output
mode: MOUNT
setup: |
pip install torch==2.5.1 vllm==0.6.6.post
...
envs: 
MODEL_NAME: "Alibaba-NLP/gte-Qwen2-7B-instruct"
run: |
python -m vllm.entrypoints.openai.api_server \
--host 0.0.0.0 \
--model $MODEL_NAME \
--max-model-len 3072 \
--task embed &
python scripts/compute_embeddings.py \
--start-idx $START_IDX \
--end-idx $END_IDX \
--chunk-size 2048 \
--chunk-overlap 512 \
--vllm-endpoint http://localhost:8000

5. 不要让嵌入生成耗时 100+ 小时 —— 使用 SkyPilot 并行处理

在单个 L4 GPU 上生成法律文档的嵌入需要 100 小时。我们可以利用 Spot 实例大幅降低时间和成本：

结果： 我们不再需要等待数天来生成嵌入。我们的任务可以动态扩展，从原型迅速转向生产，即使面对庞大数据集。

结论

构建 DeepSeek R1 RAG 让我们学到了几个关键点：

1. 利用专门的嵌入模型（如 Qwen2）提升检索能力。
2. 在生成阶段利用 R1 的推理能力处理复杂法律查询。
3. （提示词）工程仍然是控制引用和结构化内容的关键。
4. 使用 vLLM 提升推理效率，实现显著加速。
5. 在云端和自有基础设施上扩展 AI 计算，缩短计算时间并降低成本。

想了解更多？

• RAG 构建指南：GitHub Repo
• 使用 SkyPilot 扩展 AI 任务：SkyPilot Docs

注意： 该 RAG 系统是法律研究和分析的强大工具，但不能替代合格的法律专业人士。其输出不应被视为法律建议。