Marico's space
从业这些年，我见过太多团队在生产环境中部署 LLM（大型语言模型）时被"随机性"折磨得苦不堪言——同一个问题问两遍，模型给出两个完全不同的答案；让它从文档里提取信息，结果里掺进了它自己"编"的知识。这种不稳定性让很多开发者对 LLM 在生产环境的使用心存顾虑。但其实，LLM 本身并不是什么洪水猛兽，问题在于我们有没有为它设计好合适的使用方式。
这篇文章讲的就是如何提升 LLM 的确定性——不是让它变得"完美"，而是让它在生产环境下足够可靠。我会从 Prompt 工程、模型选择、上下文管理、以及工具调用四个维度展开，这些都是我们在实际项目中验证过的经验。
原文链接：
大语言模型确实很强，但它不会自动变得"确定性"。
同一个问题问两遍，答案可能略有不同；没有足够上下文就让它回答事实性问题，模型可能会自己"脑补"；让它用自然语言直接做复杂匹配或计算，出来的答案听起来很自信，但在生产环境里根本不可靠。
这不代表 LLM 天然就不可靠。这意味着我们需要在使用方式上做一些设计。
构建 AI 应用时，提升确定性通常可以从四个实用方法入手：
目标不是让 LLM 神奇地变得完美，而是减少歧义、提升准确率、防止模型在信息不足时"编造"答案。
Prompt 工程是提升 LLM 可靠性最简单的方式之一。模糊的 Prompt 给模型太多自由度，明确的 Prompt 则给它划定了边界。
不要这样问：
比较这些记录，找出哪些是匹配的。而应该给模型一个清晰的处理流程：
逐步比较这些记录：
第一步：规范公司名称
第二步：比较地址
第三步：比较电话号码
第四步：给出置信度评分
如果证据不足以判断匹配关系，返回 `unknown`（未知）。好的 Prompt 工程通常包含这些要素：
最后一点很重要。
LLM 通常被优化成"有帮助"的样子，这有时候会导致它在不该回答的时候也硬着头皮答。
允许模型说"我不知道"，可以减少幻觉（hallucination，即模型编造内容）。
比如这样：
如果无法从提供的上下文中确定答案，请回复：
"根据提供的信息，我无法确定答案。"
不要猜测。
不要使用外部知识。这类指令帮助模型在任务边界内工作。Prompt 优化本身不能保证完美结果，但通常是第一层控制手段。
不是所有 LLM 在每个任务上都一样优秀。
有些模型擅长推理，有些在代码方面更强，有些针对速度和成本做了优化，还有一些专门用于图像生成、文档理解或多模态工作流。
举例来说，Claude Opus 4.7 这样的模型常用于复杂的推理和代码密集型任务。而有些模型则专为高质量图像生成和编辑设计，包括需要在图像中准确渲染文字的场景。
关键点很简单：
根据任务选模型，而不是只看品牌名。
如果你的任务是代码生成，就用代码基准测试和实际项目中的代码例子来评估模型。如果任务是医疗文档摘要、法律审查、财务数据提取或数据匹配，就用该领域的实际样本来评估模型。如果任务是图像生成，就用专门为图像生成设计的模型。
模型参数设置也很重要。
Temperature（温度参数）是影响确定性的最重要设置之一。温度越低，响应越稳定、越聚焦；温度越高，创造性和多样性越强。
对于准确率优先的任务，比如结构化提取、分类、JSON 输出或数据处理，我通常倾向于用低温度（往往接近 0）。反过来，对于创意写作、脑暴、营销文案这类场景，较高的温度可能更合适。
另一个实用模式是智能模型路由。
不要把所有 Prompt 都发给同一个模型，可以根据意图把任务路由到不同的模型：
如果用户要求生成代码，使用代码模型。
如果用户要求生成图像，使用图像模型。
如果用户要求摘要，使用快速摘要模型。
如果用户要求复杂推理，使用推理模型。这种路由可以是基于规则的，也可以用 LLM 来分类任务并选择最合适的模型。任务越专业化，模型选择就越关键。
上下文是提升 LLM 准确率最大的因素之一。
没有上下文的 LLM 只能基于通用知识回答。这有时候有用，但在你需要基于特定文档、公司政策、用户数据、合同、代码库或领域内容的答案时，风险就很大了。
上下文给了模型边界。
比如：
仅使用提供的上下文进行回答。
如果上下文不包含答案，请告知。这就是 RAG 变得极其有用的地方。
RAG 的全称是 Retrieval-Augmented Generation（检索增强生成）。在 RAG 系统中，文档通常会被分块、向量化并存入向量数据库。当用户提问时，系统执行语义搜索找到相关内容，然后把这段内容作为上下文传给 LLM。
这样就不是让模型只依赖自己已知的知识，而是给它提供了应该使用的源材料。
一个简化版的 RAG 流程是这样的：
用户提问
↓
搜索相关文档
↓
获取最佳匹配片段
↓
将片段传给 LLM
↓
基于检索到的上下文生成答案这提升了确定性，因为模型不再是开放式的漫谈，而是有了明确的依据来源。
RAG 特别适合这些场景：
不过 RAG 不是万能药。你仍然需要好的分块策略、好的检索、好的元数据、好的 Prompt。如果检索到的上下文不对，模型仍然可能给出错误答案。
一个健壮的 RAG Prompt 建立在严格的边界之上。生产环境的 Prompt 会详细得多，但核心指令简化一下大概是这样：
只使用提供的上下文。
标注使用的来源段落。
不要基于通用知识回答。
如果答案不在上下文中，明确说明。这有助于减少幻觉，也让答案更容易验证。
工具是提升可靠性的最佳方式之一。
很多任务，如果需要稳定可靠的生产级结果，LLM 不应该直接处理。
比如：
LLM 可以推理这些任务，但不应该是执行它们的执行者。
如果需要比较成千上万条记录，不要依赖 LLM 在 Prompt 里手动检查所有记录，而是创建一个工具。
比如，一个模糊匹配工具可以用 Python 写出来，然后暴露给 LLM 调用：
def fuzzy_match_records(source_records, target_records, threshold=0.85):
"""
确定性比较两个数据集并返回可能的匹配项。
"""
matches = []
for source in source_records:
for target in target_records:
score = calculate_similarity(source, target)
if score >= threshold:
matchesappend({
"source_id": source["id"],
"target_id": target["id"],
"score": score
})
return matches
LLM 可以决定何时调用工具、解释结果、帮助用户理解输出。但匹配本身发生在代码中，可靠性要高得多。
计算也是同样的道理。如果需要精确的数学运算，用计算器工具或 Python 函数。如果需要数据库里的数据，用查询工具。如果需要实时信息，用 API 调用。
核心原则是：
用 LLM 做推理、语言、编排和解释。
用工具做确定性执行。
在 Agent 工作流中这点尤其重要。
给 AI Agent 的自主权越大，工具边界就越关键。工具应该有明确的作用范围、经过验证、有日志记录并受限。工具应该清晰、安全地做一件事。
工具让 LLM 系统更可靠，因为它们把关键操作从自然语言转移到了确定性代码中。
一个重要澄清：工具并不能因为它是"工具"就保证结果正确。它保证的是相同的代码始终如一地运行（假设实现和输入都是正确的）。但相对于让 LLM 在纯文本里现场发挥计算或匹配逻辑，这仍然是巨大的改进。
提升 LLM 的确定性没有什么神奇一招，而是分层叠加的方法。
这几种方法结合使用，能显著提升 LLM 应用的可靠性。
一个实用的架构大概是这样的：
用户 Prompt
↓
Prompt 分类
↓
模型路由
↓
RAG 检索上下文
↓
LLM 推理
↓
工具调用处理确定性任务
↓
验证后的响应这种设计让你兼得两全：既有 LLM 的灵活性和推理能力，又有结构化 Prompt、接地气的上下文、专业化模型和确定性工具带来的可靠性。
这就是 LLM 应用走向生产级成熟度的方向。
LLM 很强大，但它们需要护栏。如果你想获得更好的准确率、更少的幻觉、更可重复的结果，先问自己四个问题：
越是有意识地去回答这些问题，你的 AI 系统就越具有确定性。LLM 已经不只是聊天机器人了，它们是推理引擎、编排器和工具接口。
但在生产系统中，最好的结果来自于不再期望模型独自完成一切，而是设计出将 LLM 智能与确定性软件工程结合起来的系统。