DeepSeek R1 初次发布时展现了出色的推理能力。在这篇博客文章中，我们将详细介绍我们使用 DeepSeek R1 构建检索增强生成 (RAG) 系统的经验，该系统专为法律文件量身定制。

我们选择法律文件是因为法律专业人士经常面临一项艰巨的任务：在大量的案例、法规和非正式法律评论库中查找信息。即使是最有条理的研究也可能陷入检索正确文档的困境，更不用说准确地总结它们了。这对于 RAG 来说是一个极好的应用领域（另请参阅 Harvey AI）！

我们基于大量的法律文档数据集构建了 RAG 系统，使用了 DeepSeek R1 和 Qwen2 嵌入。我们开源了整个构建 RAG 的流程（由 vLLM 和 SkyPilot 提供支持），并分享了一些来之不易的经验——哪些方法有效，哪些无效。

想看看实际效果 🔥？ 请此处尝试我们的托管演示。

我们已在此处开源了构建此 RAG 的流程。来探索我们如何结合 vLLM + SkyPilot 实现快速、弹性且可扩展的性能。

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

检索增强生成对于准确性和可追溯性至关重要的领域（如法律）至关重要。通过将专门的检索器与强大的 LLM 生成器相结合，我们可以兼得两者的优势：

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

为了构建这个 RAG，我们使用了

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

整个设置在 vLLM 上运行，并通过 SkyPilot 无缝部署到任何云端，以获得最佳的 GPU 可用性和成本。请在此处查找我们的开源流程。

来之不易的经验：建议与禁忌

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

尽管 DeepSeek R1 具有出色的推理能力，但它不擅长生成嵌入——至少目前是这样。

我们发现了一些示例，展示了 DeepSeek R1 生成的嵌入与专门的嵌入模型 Alibaba-NLP/gte-Qwen2-7B-instruct（当前 MTEB 排行榜 上最好的嵌入模型）相比有多糟糕。

我们使用这两个模型为数据集生成嵌入，并构建了两个向量数据库。然后，我们对这两个模型使用相同的查询，并在各自模型生成的向量数据库中找到相似度最高的 5 个嵌入。

为什么会有这种差异？

在上面的表格中，DeepSeek R1 的检索结果明显更差。为什么？

我们认为根本问题在于 DeepSeek-R1 的训练方式。DeepSeek-R1 主要被设计为一个推理引擎，专注于顺序思考和逻辑连接。这意味着 DeepSeek-R1 不会将文档映射到语义空间中。

相比之下，Qwen2 模型变体（gte-Qwen2-7B-instruct）专门针对语义相似性任务进行训练，创建了一个高维空间，在该空间中，概念上相似的文档会紧密地聚集在一起，无论具体措辞如何。

这种训练过程的差异意味着 Qwen 擅长捕捉查询背后的意图，而 DeepSeek-R1 有时会沿着导致主题相关但实际无关结果的推理路径前进。

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

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

虽然 R1 在嵌入方面表现不佳，但我们发现其生成能力非常出色。通过利用 R1 的思维链方法，我们看到

• 更强的连贯性：模型综合了多份文档中的见解，清晰地引用了相关段落。
• 减少幻觉：R1 在内部“大声思考”，通过您提供的数据验证每个结论。

让我们看几个例子

示例 1：终止租约

问题： 我想终止租约。我的房东不允许。

示例 2：小额索赔法庭

问题： 我收到了小额索赔法庭关于有争议债务的传票。我该如何准备？

从这些例子中，我们观察到 DeepSeek R1 出色的推理能力。其思考过程清楚地展示了结论是如何从源法律文件中推导出来的。

• R1 首先构建了一个法律问题的连贯模型，这在其详细的思考过程中得到了体现：首先，我记得读到过关于提前终止的罚款... 文档 1 提到... 这种推理优先的方法使得模型能够在检索之前系统地连接多个来源的概念。
• 在处理诸如终止租约或小额索赔法庭问题等复杂场景时，我们观察到 R1 明确地通过其对每份文档的理解（综合以上所有信息...）进行推理，没有产生幻觉。
• 最后，生成器以精确的引用解释其推理过程，将结论与来源联系起来。这在问题、推理和答案之间建立了清晰的联系，确保了严谨性和可访问性。

我们使用不同的法律查询尝试了该模型，模型始终展示出不仅能从源文档中提取信息，还能从中学习并进行推理的能力。

要点：对于问答和摘要，R1 是循序渐进法律逻辑的宝库。将其用于生成阶段，您几乎不会后悔。

3. 工程仍然很重要

提示词设计

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

• 在生成的答案中鼓励文档引用。
• 采用“引用或声明不知道”的方法防止幻觉。
• 以用户友好的方式组织最终答案.

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

You are a helpful AI assistant analyzing legal documents and related content. When responding, please follow these guidelines:
- In the search results provided, each document is formatted as [Document X begin]...[Document X end], where X represents the numerical index of each document.
- Cite your documents using [citation:X] format where X is the document number, placing citations immediately after the relevant information.
- Include citations throughout your response, not just at the end.
- If information comes from multiple documents, use multiple citations like [citation:1][citation:2].
- Not all search results may be relevant - evaluate and use only pertinent information.
- Structure longer responses into clear paragraphs or sections for readability.
- If you cannot find the answer in the provided documents, say so - do not make up information.
- Some documents may be informal discussions or reddit posts - adjust your interpretation accordingly.
- Put citation as much as possible in your response. 

First, explain your thinking process between <think> tags.
Then provide your final answer after the thinking process.

文档切块

此外，我们发现有效的文档切块对于准确的文档检索非常重要。对文档进行切块有助于使每个嵌入更简洁地代表一个特定主题，并减少生成每个嵌入所需的处理 token 数量。

我们使用了句子感知分割（通过 NLTK）来对文档进行切块。我们还让每个块的开头和结尾包含与相邻块重叠的内容。这有助于模型在不丢失大局的情况下更好地解释部分引用。文档切块的代码：

def chunk_document(document, chunk_size=2048, overlap=512):
    """Split document into overlapping chunks using sentence-aware splitting."""
    text = document['text']
    chunks = []
    
    # Split into sentences first
    sentences = nltk.sent_tokenize(text)

    current_chunk = []
    current_length = 0

    for sentence in sentences:
        sentence_len = len(sentence)

        # If adding this sentence would exceed chunk size, save current chunk
        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,
                # Additional metadata fields...
            })

            # Keep last few sentences for overlap
            overlap_text = ' '.join(current_chunk[-2:])  # Keep last 2 sentences
            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 for space

要点

1. 使用 NLTK 进行句子感知分词而非基于字符的切块
2. 通过块之间重叠的句子保留文档上下文

4. vLLM 高效且快速

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

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

我们切换到 vLLM，这是一个用于 LLM 的高吞吐量、内存高效的推理和服务引擎。

使用 vLLM，我们可以使用标准的 Nvidia L4 GPU 运行模型，vLLM 需要大约 24G GPU 显存。L4 也比 A100 便宜得多：在 GCP 上，Nvidia L4 每小时花费超过 0.7 美元，而 Nvidia A100 至少每小时 2.9 美元。

在配备 80GB 显存的 Nvidia A100 上比较 vllm 和 sentence transformer 时，我们发现使用 vLLM 为 Qwen2 模型生成嵌入的速度比 sentence transformer 快高达 5.5 倍。

对于包含 10,000 份法律文档和 15,000 个块的语料库，处理时间如下：

• 标准 sentence transformers：约 5.5 小时
• vLLM 实现：约 1 小时

以下是我们使用 vLLM 为 Alibaba-NLP/gte-Qwen2-7B-instruct 模型生成嵌入的 SkyPilot YAML 文件：

使用 vLLM 生成嵌入的 SkyPilot YAML

name: compute-legal-embeddings

resources:
    # this needs ~ 24G DRAM GPU for vllm, 57G with SentenceTransformer
    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 实例，这可以显著减少嵌入生成的时间和成本。

因此，我们使用支持以下功能的 SkyPilot 托管作业（Managed Jobs）扩展了嵌入生成：

1. 大规模并行作业：我们将数据分成多个分区，并在多个云上启动了多个嵌入生成作业。
2. 使用带自动恢复的 Spot 实例：如果 Spot 实例或节点出现故障，SkyPilot 会自动重试，从中断的地方继续。
3. 统一存储：所有嵌入数据直接流式传输到云存储桶中（采用 Apache Parquet 格式）。不再丢失工作或处理部分输出。

下图显示了并行运行 10 多个 Spot 作业进行嵌入生成，并且 SkyPilot 跨不同区域寻找最佳的 GPU 可用性：

结果：我们不再需要等待数天来生成嵌入。我们的作业可以动态扩展，让我们即使处理大型数据集也能快速从原型阶段进入生产阶段。

结论

为法律文档构建一个 DeepSeek R1 RAG 教会了我们几个关键的经验：

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

想了解更多？

• 构建 RAG 的流程和说明：GitHub 代码库链接
• 使用 SkyPilot 扩展 AI 工作负载：SkyPilot 文档

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