使用 LLM 提高确定性：Prompting、模型选择、上下文和工具

Source: Dev.to

请提供您希望翻译的完整文本内容，我将按照要求保留源链接、格式和代码块，仅翻译正文部分。谢谢！

大型语言模型中的确定性

大型语言模型功能强大，但它们 并非自动确定。

• 同一个问题问两次可能会得到略有不同的答案。
• 在缺乏足够上下文的情况下询问事实，模型可能会自行填补空白。
• 用自然语言表达的复杂匹配或计算可能听起来很自信，却在生产环境中不可靠。

这并 不 意味着 LLM 本身默认不可靠——而是说明我们需要 围绕它们的工作方式进行设计。

提高确定性的四种实用方法

1. Prompt engineering
2. Choosing the right model
3. Providing the right context (including RAG)
4. Using tools for deterministic work

目标不是让 LLM 神奇地完美，而是 减少歧义、提升准确性，并在模型信息不足时防止幻觉。

1. 提示工程

模糊的提示会给模型太多自由度。具体的提示则为其设定明确的边界。

Bad Prompt

Compare these records and tell me which ones match.

Improved Prompt

Compare the records step by step.
1. Normalize company names.  
2. Compare addresses.  
3. Compare phone numbers.  
4. Assign a confidence score.  

If there is not enough evidence to determine a match, return `unknown`.

Good Prompt Engineering Usually Includes

• 步骤式指令
• 具体示例
• 示例输出
• 明确的格式要求
• 对模型可使用来源的约束
• 允许模型说“我不知道”

Why “I don’t know” matters
LLM 通常被优化为有帮助，这可能导致它们在不该回答时仍给出答案。明确允许拒绝可以减少幻觉。

Example instruction

If the answer cannot be determined from the provided context, respond with:
"I don't know based on the provided information."
Do not guess. Do not use outside knowledge.

仅靠提示并不能保证完美结果，但它通常是 第一层控制。

2. 选择合适的模型

并非所有 LLM 都在每个任务上表现出色。

关键点： 根据任务选择模型，而不是仅凭品牌名称。

• 代码生成： 对照编码基准和自己的代码库进行评估。
• 医疗/法律摘要： 使用领域特定的示例进行测试。
• 图像生成： 选用专为此目的构建的模型。

确定性模型设置

• Temperature 是最重要的参数。
  • 低温度（≈0） → 确定性、聚焦的响应；适用于结构化抽取、分类、JSON 输出、数据处理。
  • 较高温度 → 更具创意、多样的输出；适合头脑风暴、营销文案、创意写作。

智能模型路由

不要把每个提示都发送到同一个模型，而是 根据意图路由任务：

路由可以基于规则实现，也可以让 LLM 首先对请求进行分类后决定使用哪个模型。

3. 提供正确的上下文 (RAG)

没有上下文的 LLM 可能只依赖其通用知识——这在很多情况下有用，但当答案必须基于特定文档、政策、合同、代码库或其他领域专属内容时，就会有风险。

简单上下文提示

仅使用提供的上下文作答。
如果上下文中不包含答案，请说明你不知道。

检索增强生成 (RAG)

RAG = Retrieval‑Augmented Generation（检索增强生成）。在 RAG 系统中：

1. 对文档进行切块。
2. 对切块进行向量化并存入向量数据库。
3. 当用户提出问题时，执行语义搜索以检索最相关的切块。
4. 将这些切块作为上下文传递给 LLM。
5. LLM 基于检索到的材料生成答案。

简化的 RAG 流程

User asks a question
        ↓
Search relevant documents
        ↓
Retrieve best‑matching chunks
        ↓
Pass chunks to the LLM
        ↓
Generate answer grounded in retrieved context

**RAG 提升确定性的原因：**模型不再以开放式方式运行，而是拥有明确的真相来源。

RAG 发光发热的使用场景

• 内部文档
• 政策类问题
• 知识库
• 技术文档
• 客户支持
• 合同审查
• 医疗或法律文档审查
• 代码库问答
• 研究助理

**注意事项：**RAG 并非万能钥匙。仍需：

• 良好的切块策略
• 有效的检索（高质量向量、合适的元数据）
• 强有力的提示，告诉模型如何使用检索到的上下文

---

4. 使用工具实现确定性工作

超越提示和模型，您可以整合 外部工具（例如计算器、验证器、确定性 API）来处理需要精确性的工作流部分。通过将算术、日期处理或模式验证等任务委托给专门的服务，您可以让 LLM 专注于推理和语言生成，同时确保最终输出可靠。

TL;DR

• 提示工程：具体明确，提供逐步指令，允许 “我不知道”。
• 模型选择：根据任务匹配模型；调节 temperature 以实现确定性。
• 上下文（RAG）：检索相关文档并输入 LLM，以为答案提供依据。
• 确定性工具：将精确计算或验证工作转移到外部服务。

将这四种方法结合使用，可显著降低歧义，提高准确性，使基于 LLM 的应用能够安全投入生产。

使用上下文约束提示减少幻觉

核心提示指令（简化版）：

1. 仅使用提供的上下文。
2. 引用所使用的来源章节。
3. 不要依据一般知识作答。
4. 如果上下文中没有相关答案，请说明。

这些规则有助于减少幻觉并使验证更容易。

为什么工具对可靠性很重要

许多任务更适合由确定性的代码来处理，而不是直接由 LLM 完成：

• 复杂计算
• 在大型数据集上的模糊匹配
• 排序和过滤
• 数据库查询
• API 查询
• 文件解析
• 数据校验
• 日期计算
• 业务规则执行

LLM 可以推理这些任务，但不应该成为执行它们的引擎。

示例：模糊匹配工具

def fuzzy_match_records(source_records, target_records, threshold=0.85):
    """
    Deterministically compare two datasets and return likely matches.
    """
    matches = []

    for source in source_records:
        for target in target_records:
            score = calculate_similarity(source, target)

            if score >= threshold:
                matches.append({
                    "source_id": source["id"],
                    "target_id": target["id"],
                    "score": score
                })

    return matches

• LLM 角色： 决定何时调用工具，解释输出，帮助用户解读结果。
• 工具角色： 可靠地执行实际的匹配工作。

同样的模式同样适用于计算、数据库查询、实时 API 调用等。

工具中心模式

1. 使用 LLM 进行推理、语言、编排和解释。
2. 将工具范围限定得很窄： 每个工具只提供一个明确、安全的功能。
3. 验证、记录并限制 工具的使用。

注意： 工具并不能自动保证结果正确；它保证在实现和输入正确的前提下，同一段代码能够一致运行——这种确定性行为相较于临时的 LLM 逻辑是一个重大改进。

确定性分层方法

这些层级显著提升了基于 LLM 的应用的可靠性。

实用架构

User Prompt
   ↓
Prompt Classification
   ↓
Model Routing
   ↓
Retrieve Context with RAG
   ↓
LLM Reasoning
   ↓
Tool Calls for Deterministic Work
   ↓
Validated Response

此设计为您提供：

• LLM 的灵活性和推理能力。
• 结构化提示、可靠的上下文、模型专精以及确定性工具的可靠性。

---

生产就绪的 LLM 的四个问题

1. 我的提示足够具体吗？
2. 我是否为此任务使用了正确的模型？
3. 我是否提供了正确的上下文？
4. 这个任务是否应该由工具而不是 LLM 处理？

有意地回答这些问题可以使你的 AI 系统更具确定性。

---

要点

LLMs 不再只是聊天机器人；它们是推理引擎、编排器以及工具的接口。对于生产系统，最佳结果来自 将 LLM 智能与确定性软件工程相结合，而不是期望模型独自完成所有工作。