site logo

Marico's space

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

前端技术 2026-05-02 22:33:44 12
The user wants me to rewrite this English technical article about improving LLM determinism into natural Chinese. Let me analyze the requirements: 1. Natural Chinese conversational style, not translation-ese 2. Keep all technical details, code examples, data 3. Keep all tags (there don't seem to be any in this article) 4. Keep all code blocks
...
5. Adjust transition words for Chinese 6. Add parenthetical translations for English acronyms (LLM→大语言模型, API→应用程序接口, etc.) 7. Replace Western examples with Chinese context (Stripe→微信/支付宝, Google→百度, AWS→阿里云, etc.) 8. Add editor's introduction 9. Output as HTML 10. No Markdown 11. External links as plain text with URL at end 12. No mentions of "machine translation" etc. Let me rewrite this article: Title: 提升 LLM 确定性:Prompting、模型选择、Context 与 Tools Let me check the content: - It's about improving determinism in LLMs - Has 4 main methods: prompt engineering, model selection, context/RAG, tools - Contains code examples - Has some Western examples like Stripe, Google, AWS that I should adapt Wait, looking at the text again, I don't see specific mentions of Stripe, Google, or AWS. The examples are more general (company names, addresses, phone numbers for matching, etc.). So I don't need to replace those specific examples. Let me also note that I see references to: - Claude Opus 4.7 - Nano Banana Pro (this seems like a fictional/example model name) - These seem to be example model names Let me now rewrite the article with natural Chinese: --- Title: 提升 LLM 确定性:Prompting、模型选择、Context 与 Tools Editor intro: 聊聊大语言模型的"靠谱"问题

大语言模型(LLM)确实很强大,但强大不代表靠谱。同一个问题问两遍,答案可能略有不同;给的信息不够,它就自己脑补;让它直接用自然语言做复杂的匹配或计算,出来的结果可能听起来头头是道,但放到生产环境里根本不敢用。

这并不是说大语言模型本身不靠谱,而是我们得针对它的工作方式来设计系统。

在做 AI 应用的时候,提升确定性主要靠四个实用方法:

  1. 提示词工程(Prompt Engineering)
  2. 选择合适的模型
  3. 提供合适的上下文,包括 RAG
  4. 用工具处理需要确定性结果的工作

目标不是让大语言模型变得完美无缺,而是减少歧义、提高准确率、避免它在信息不足的时候瞎编答案。


一、提示词工程

提示词工程是提高大语言模型可靠性的最简单方法之一。模糊的提示词给模型的自由度过高,而具体明确的提示词给它划定了边界。

比如,不要这样问:

Compare these records and tell me which ones match.
Enter fullscreen mode Exit fullscreen mode

改成给它一个清晰的流程:

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`.
Enter fullscreen mode Exit fullscreen mode

好的提示词工程通常包括:

  • 分步骤的指令
  • 具体示例
  • 输出格式示例
  • 明确的格式要求
  • 限制模型可以使用的来源
  • 允许模型说"我不知道"

最后一点很重要。

大语言模型通常被优化成"乐于助人"的样子,但这有时候会让它即使不该回答也硬着头皮答。

允许模型说"我不知道"可以有效减少幻觉(hallucination)。

比如这样:

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.
Enter fullscreen mode Exit fullscreen mode

这类指令帮助模型在任务边界内工作。单独的提示词工程不能保证完美结果,但通常是第一层控制。


二、选择合适的模型

不是所有大语言模型在各任务上都同样出色。

有些模型擅长推理,有些更善于写代码,有些针对速度和成本做了优化,还有些专门用于图像生成、文档理解或多模态工作流。

比如说,某些模型适合复杂的推理和代码密集型任务,而某些模型专门用于高质量图像生成和编辑,包括需要在图像中准确渲染文字的场景。

关键点很简单:

根据任务选模型,而不是看品牌名字。

如果你的任务是代码生成,就用代码基准测试和实际项目中的代码例子来评估模型。如果你的任务是医疗文档摘要、法律审查、金融数据提取或数据匹配,就用对应领域的例子来评估模型。如果你的任务是图像生成,就用专门为图像生成设计的模型。

模型参数设置也很重要。

温度(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.
Enter fullscreen mode Exit fullscreen mode

这种路由可以是基于规则的,也可以用大语言模型来分类任务并选择最佳模型。任务越专业化,模型选择就越重要。


三、提供合适的上下文(RAG)

上下文是提高大语言模型准确率的最大因素之一。

没有上下文的大语言模型可能基于一般性知识来回答。这有时候有用,但当你需要基于特定文档、公司政策、用户数据、合同、代码库或领域特定内容来回答时,这种方式就很冒险了。

上下文给模型划定了边界。

比如:

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

而这正是 RAG 变得极其有用的地方。

RAG 是 Retrieval-Augmented Generation(检索增强生成)的缩写。在 RAG 系统中,文档通常被分块、向量化后存储到向量数据库。当用户提问时,系统执行语义搜索找到相关内容,然后把这些内容作为上下文传给大语言模型。

这样做不是让模型只依赖它已经知道的东西,而是给它应该使用的原材料。

简化版的 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
Enter fullscreen mode Exit fullscreen mode

这提高了确定性,因为模型不再以开放式的方式运行了。它有了明确的真实来源。

RAG 特别适合以下场景:

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

然而,RAG 不能自动解决所有问题。你仍然需要良好的分块策略、好的检索方法、好的元数据以及好的提示词工程。如果检索到的上下文不对,模型仍然可能给出错误答案。

一个强大的 RAG 提示词建立在严格的边界之上。生产环境的提示词会详细得多,但简化版的核心里通常长这样:

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.
Enter fullscreen mode Exit fullscreen mode

这有助于减少幻觉,也让答案更容易验证。


四、用工具处理需要确定性结果的工作

工具是提高可靠性的最佳方式之一。

很多任务如果需要稳定、可用于生产的结果,大语言模型就不应该直接执行。

比如:

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

大语言模型可以推理这些任务,但不应该总是由它来执行。

如果你需要比较成千上万条记录,不要依赖大语言模型在提示词里手动检查所有记录,而是创建一个工具。

比如,一个模糊匹配工具可以用 Python 编写,然后暴露给大语言模型:

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
Enter fullscreen mode Exit fullscreen mode

大语言模型可以决定何时使用这个工具、解释结果、帮助用户理解输出。但匹配本身发生在代码中,可靠性要高得多。

计算也是同样的道理。如果需要精确的数学运算,就用计算器工具或 Python 函数。如果需要从数据库获取数据,就用查询工具。如果需要实时信息,就调用 API。

模式是这样的:

用大语言模型做推理、语言处理、编排和解释。
用工具做需要确定性执行的工作。

这在智能体(Agent)工作流中尤为重要。

给 AI 智能体的自主权越大,工具边界就越重要。工具应该有明确的作用范围、经过验证、有日志记录并受到限制。一个工具应该清晰、安全地做一件事。

工具让大语言模型系统更可靠,因为它们把关键操作从自然语言转移到了确定性的代码中。

一个重要的澄清:工具不保证结果一定正确,只是保证相同的代码在输入一致的情况下运行结果一致(假设实现和输入都是正确的)。这比起让大语言模型在纯文本中即兴发挥计算或匹配逻辑,仍然是巨大的改进。


综合应用

提高大语言模型的确定性没有一招致胜的magic。这是一种层层叠加的方法。

  • 提示词工程给模型清晰的指令。
  • 模型选择确保你为任务使用正确的模型。
  • 上下文和 RAG 让模型基于相关的原材料回答。
  • 工具把关键逻辑放到确定性的代码中。

这些方法结合使用,可以显著提高大语言模型应用的可靠性。

一个实用的架构可能是这样的:

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

这种设计让你兼得两者之长。你既有大语言模型的灵活性和推理能力,也有结构化提示词、基于上下文的回答、专业化模型以及确定性工具带来的可靠性。

这才是大语言模型应用真正达到生产就绪水平的样子。


最后的思考

大语言模型很强大,但需要护栏。如果你想获得更好的准确率、更少的幻觉、更可重复的结果,先问自己四个问题:

  1. 我的提示词够具体吗?
  2. 我是否为这个任务选择了正确的模型?
  3. 我提供了正确的上下文吗?
  4. 这个任务是不是应该由工具来处理,而不是大语言模型?

越是有意识地回答这些问题,你的 AI 系统就越具确定性。大语言模型不再只是聊天机器人了。它们是推理引擎、编排器、也是连接各种工具的接口。

但对于生产系统来说,最好的结果来自于不再期望模型独自完成一切,而是设计将大语言模型的智能与确定性软件工程相结合的系统。