Marico's space

提升 LLM 确定性：Prompting、模型选择、Context 与 Tools

前端技术 2026-05-02 22:46:08 3

做过实际 AI 产品的朋友大概都有过这种经历：你满怀期待地把一个「智能」功能交给用户，结果测试下来，同一个问题问了两次，模型给出了两个不同的答案；让它从合同里提取关键条款，它自信满满地编了一个条款编号；让它对比两三千条客户记录，它算出来的匹配率忽高忽低。这种不确定性在实际生产环境中简直是噩梦。

但这其实不是模型的问题。LLM（大型语言模型）本质上就是个「能说会道的推理引擎」，它本身就不是设计来保证输出完全一致的。我们真正需要做的，是围绕它的工作方式来设计系统，而不是指望它自己变确定。

经过这段时间的实践，我觉得提升 LLM 确定性主要靠四个手段：Prompt 工程、选对模型、提供充分的上下文、以及用工具来处理确定性的工作。听起来是老生常谈，但真正落地的时候，每个环节都有不少坑要踩。这篇文章就把这些经验整理一下，希望能对正在做 AI 应用开发的朋友有点帮助。

1. Prompt 工程

Prompt 工程是最直接、成本最低的改进方式。模糊的 Prompt 给了模型太大的发挥空间，而具体的 Prompt 则是给它划定边界。

比如，你想让模型对比两组客户记录，判断哪些是同一个人。与其简单地说：

Compare these records and tell me which ones match.

不如把任务拆解成清晰的步骤：

Compare the records step by step.
First, normalize company names.
Second, compare addresses.
Third, compare phone numbers.
Fourth, assign a confidence score.
If there is not enough evidence to determine a match, return `unknown`.

好的 Prompt 通常会包含这些要素：

逐步执行的指令
具体的示例
期望的输出格式
明确的格式要求
对数据来源的约束
允许模型说「我不知道」

最后一点特别重要。很多模型的训练目标都是「尽量给出有帮助的回答」，这有时候会让它在没把握的时候也硬着头皮回答。

明确告诉模型可以拒绝回答，反而能减少它瞎编答案的情况。

比如可以这样写：

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.

这种指令帮助模型在任务边界内工作。Prompt 工程本身不能保证完美结果，但它是第一层控制，也是最容易上手的一步。

2. 选择合适的模型

不是所有 LLM 都擅长同样的事情。有的模型推理能力强，有的在编程方面表现更好，有的针对速度和成本做了优化，还有些专门用于图像生成或者多模态任务。

比如做复杂的代码推理和编程任务，可能会选择 Claude Opus 这样的模型；如果需要生成图片并且要求图片里的文字准确无误，可能就需要专门优化过的图像生成模型。

关键在于：

根据任务选模型，而不是看品牌下单。

做代码生成就拿编程基准测试和实际项目代码来评估；做医疗文档摘要、法律审查、财务数据提取这类垂直领域任务，就拿对应领域的真实样本测试；做图像生成就用专门的图像模型。

模型的参数设置也很关键。Temperature（温度）参数是影响确定性的重要因素之一。温度设得低，模型的输出会更稳定、更聚焦；温度设得高，创造性和多样性会增加，但变数也更大。

对于准确性优先的任务——比如结构化数据提取、分类、输出 JSON、处理数据——我通常会把温度设到接近 0。反过来，写营销文案、做创意头脑风暴这类场景，高温度可能更合适。

另一个实用的思路是「智能路由」。不用所有请求都丢给同一个模型，而是根据任务类型分流：

If the user asks for code generation, use the coding model.
If the user asks for image generation, use the image model.
If the user asks for summarization, use the fast summarization model.
If the user asks for complex reasoning, use the reasoning model.

路由逻辑可以是规则驱动，也可以用 LLM 来判断任务类型然后选择最合适的模型。任务越专业，模型选择的重要性就越突出。

3. 提供合适的上下文（RAG）

上下文是提升准确性的关键因素之一。

没有上下文的 LLM 只能靠它的训练知识来回答。这种方式有时候有用，但如果你的答案需要基于特定文档、公司制度、用户资料、合同条款、代码库或者领域知识，那光靠内部知识就危险了。

上下文本质上是在给模型划定工作范围。

比如可以这样约束：

Answer only using the provided context.
If the context does not contain the answer, say you do not know.

而在实际落地中，RAG（检索增强生成）是最常用的上下文增强方案。

RAG 的流程大概是：先把你的文档切分成小块，进行向量化处理，存入向量数据库；当用户提问时，系统做语义搜索找到相关内容，把这些内容作为上下文传给 LLM。这样模型就不是凭记忆回答，而是基于检索到的真实材料来生成答案。

一个简化版的 RAG 流程是这样的：

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

这样做之所以能提升确定性，是因为模型不再「开放性发挥」，而是有了明确的参考答案。

RAG 特别适合这些场景：

内部文档问答
制度查询
知识库检索
技术支持文档
客服对话
合同审查
医疗或法律文档处理
代码库问答
研究助手

不过 RAG 不是银弹。分块策略、检索质量、元数据管理、Prompt 设计，这些环节没做好，检索出来的上下文不对，模型还是会给出错误答案。

一个强约束的 RAG Prompt 通常长这样（实际生产环境会更复杂，但核心思路是相通的）：

Use only the provided context.
Cite the source sections used.
Do not answer from general knowledge.
If the answer is not present in the context, say so.

这种约束既能减少模型瞎编，又能方便后续验证答案的来源。

4. 使用工具处理确定性工作

引入工具是提升可靠性的最有效手段之一。

有些任务，如果要求稳定、可复现的生产级表现，LLM 最好别直接上手做，比如：

复杂计算
大规模模糊匹配
排序和筛选
数据库查询
API 调用
文件解析
数据校验
日期计算
业务规则执行

LLM 能理解这些任务，但处理它们不应该全靠自然语言推理。

比如要对比几千条客户记录，别让 LLM 在 Prompt 里逐条检查，创建一个专门的匹配工具会更好。用 Python 写一个模糊匹配函数，然后暴露给 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 负责判断什么时候调用工具、解释结果、帮助用户理解输出，但匹配逻辑本身是在代码里执行的，这要可靠得多。

同样的逻辑也适用于计算：需要精确数学运算就调用计算器工具或 Python 函数；需要查数据库就用查询工具；需要实时信息就调 API。

LLM 负责推理、语言表达、流程编排和结果解释；工具负责确定性执行。

这一点在智能体（Agent）工作流中尤为重要。你给 AI 智能体的自主权越大，工具边界就越关键。工具必须有明确的作用范围、经过验证的实现、完整的日志记录和严格的权限控制。一个工具只做一件事，而且要做好、做安全。

工具让 LLM 系统更可靠，因为它们把关键操作从自然语言推理转移到了确定性的代码执行层面。

有一点需要澄清：工具不能保证结果一定正确，它保证的是「相同的代码在相同输入下始终执行一致」。这比让 LLM 在纯文本里临时推导计算或匹配逻辑，已经是巨大的改进。

总结

提升 LLM 确定性没有一招鲜的秘诀，它是一个层层设防的系统工程：

Prompt 工程让模型获得清晰指令
模型选择确保用对的工具做对的事
上下文和 RAG 让模型基于真实材料作答
工具把关键逻辑锁定在确定性代码里

这四者配合使用，能让 LLM 应用的生产稳定性大幅提升。

一个典型的生产架构可能是这样的：

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

这种设计兼顾了两方面：既保留了 LLM 的灵活性和推理能力，又拥有了结构化 Prompt、锚定上下文、专业模型分流和确定性工具的可靠性。这才是让 LLM 应用真正达到生产级别的路径。

最后

LLM 确实强大，但它需要边界。如果你想让 AI 系统更准确、减少瞎编、输出更稳定，先问自己四个问题：

我的 Prompt 足够具体吗？
这个任务选对模型了吗？
我提供了充分的上下文吗？
这项工作是不是应该交给工具而不是 LLM？

这四个问题回答得越用心，你的 AI 系统就越确定。LLM 现在已经不只是聊天机器人了，它是推理引擎、流程编排器、工具调用的入口。但在生产系统里，最好的结果来自我们不再期待模型独自搞定一切，而是把 LLM 的智能和确定性软件工程结合起来设计系统。

原文链接：https://www.example.com/improving-determinism-with-llms