AI幻觉治理 | 提示词更稳

title: " AI幻觉治理 | 提示词更稳" category: 人工智能 tags:

• 大模型API中转站
• AI幻觉
• Prompt Engineering
• RAG
• 4SAPI
• OpenAI-Compatible description: "用开发者能看懂的方式解释大模型为什么会幻觉，并给出基于4SAPI的联网搜索、知识库、低温度、引用校验和日志复盘方案，让AI应用回答更稳。"

这篇不讲某个新工具。

我们讲一个所有 AI 应用都会撞上的问题：

为什么 AI 有时候很聪明，有时候又会一本正经地胡说？

很多人第一次接入大模型 API，最容易误判两件事。

第一，把模型当数据库。

第二，把“看起来很像答案”的文本当事实。

这两个误判一叠加，就会出现很典型的事故：模型编一个不存在的函数、引用一篇搜不到的论文、给出过期价格、把接口参数名写错，还说得特别自信。

这就是我们常说的 AI 幻觉。

本文目标很简单：

用不懂算法也能懂的方式讲清楚大模型为什么会幻觉。
再把它落到工程实践：提示词、联网搜索、RAG、温度、日志和4SAPI路由怎么配。

1. 先记住一句话

大模型不是先查数据库，再把答案读给你听。

它更像一个超级补全文本的系统：

看到前文 -> 预测下一个Token -> 接上去 -> 再预测下一个Token

你输入：

天空是

模型会根据训练中见过的大量文本，判断后面接“蓝色的”的概率很高。

然后它接上“蓝色的”，再继续预测后面该出现什么。

聊天回答、代码补全、摘要生成，本质上都是这个过程。

所以它不是在“确认事实”，而是在“生成最像答案的下文”。

这句话听起来有点扫兴，但非常重要。

因为你一旦理解这个机制，就会明白：

提示词越清楚，预测空间越小，答案越稳。
上下文越含糊，预测空间越大，幻觉越容易出现。

2. Token 是什么

模型并不直接看懂中文、英文或代码。

真正送进模型里的，是一段段数字。

大致流程是：

原始文本 -> 分词(Tokenization) -> Token ID -> 向量(Embedding) -> 模型计算

Token 可以理解成模型处理文本的基本颗粒。

它可能是一个汉字，也可能是一个词，也可能是英文单词的一部分。不同模型的分词器不同，所以 Token 数不等于字数，也不等于单词数。

这件事对开发者很现实。

因为大模型 API 通常按输入 Token 和输出 Token 计费。

一次请求里会被计费的内容包括：

很多应用贵，不是用户问得长，而是每次都把一大坨历史消息、无关文档、调试日志塞进去。

上下文越长，成本越高；信息越乱，模型越容易抓错重点。

所以治理幻觉的第一步，不是疯狂加上下文，而是把上下文喂干净。

3. Transformer 到底解决了什么

现代大模型基本都建立在 Transformer 这类结构之上。

Transformer 的关键能力是注意力机制。

你可以把它理解成：

模型看到一句话时，会判断每个Token应该重点关注哪些其他Token。

比如这句话：

小张把接口文档发给小李，他说下午会改完。

这里“他”到底指谁？

人会根据上下文猜。

模型也会通过注意力去计算“他”和“小张”“小李”“接口文档”等 Token 的关系。

注意力机制让模型不再只能机械地从左往右死记，而是能在上下文中建立关联。

这也是它能写代码、改文案、总结文档、解释报错的基础。

但注意力不是事实校验器。

它只能帮模型更好地利用上下文，不能保证上下文之外的事实一定正确。

所以当你问它一个新版本 API 的参数，它如果上下文里没有官方文档，就很可能拿旧知识或相似接口来补。

这就是很多“编程幻觉”的来源。

4. 幻觉为什么会发生

AI 幻觉不是单一原因，而是几个因素叠在一起。

4.1 它的知识有截止时间

模型训练完成以后，参数里的知识不会自动更新。

新框架、新价格、新政策、新模型、新接口文档，都可能不在它的训练数据里。

所以凡是带这些词的问题，都不要让模型凭记忆答：

最新
今天
最近
当前版本
官方文档
价格
政策
榜单

更稳的做法是先检索，再回答。

4.2 它会补全，而不是核验

模型最擅长生成“看起来合理”的文本。

当它不知道某个函数名时，可能会参考常见命名规律补一个。

比如：

client.chat.completions.stream()

如果某个 SDK 没有这个方法，它也可能照着其他 SDK 的命名风格写出来。

这类回答读起来很顺，但运行会炸。

4.3 上下文太长会丢重点

长上下文不是万能药。

研究里有一个常见现象叫 lost in the middle，可以粗略理解成：

模型对开头和结尾的信息更敏感，中间信息更容易被忽略。

所以把 10 万字资料直接塞进去，不一定比给 5 段关键摘录更稳。

尤其是代码调试时，建议给：

最小复现代码
完整报错栈
相关配置
你已经尝试过的方法
期望结果和实际结果

而不是把整个项目无差别丢给模型。

4.4 随机性会放大不确定性

大模型生成时通常会有 temperature 这类参数。

可以粗略理解为：

temperature 越低，回答越保守稳定。
temperature 越高，回答越发散有创意。

写小说、起标题、做创意 Brainstorm，可以适当提高。

写代码、查事实、生成 SQL、回答客服问题，建议降低。

5. 幻觉治理的工程方案

理解原理之后，工程方案就很清楚了。

不要指望一个提示词让模型永不犯错。

要用链路把错误概率压下去。

一个更稳的 AI 应用链路可以这样设计：

用户问题
  -> 判断是否需要检索
  -> 拉取可信资料
  -> 清洗和压缩上下文
  -> 调用模型生成
  -> 校验引用、格式和关键字段
  -> 记录日志，方便复盘

5.1 让模型先判断是否需要联网

不是每个问题都要联网。

可以加一个轻量判断：

需要联网：
- 用户问最新、今天、最近、当前
- 涉及价格、政策、版本、榜单
- 涉及具体论文、新闻、公司动态
- 用户要求给来源

不需要联网：
- 概念解释
- 通用写作
- 已提供上下文内的问题
- 常见语法和工程经验

这一步能省钱，也能减少搜索噪音。

5.2 用 RAG 把事实放进上下文

RAG 的思路很朴素：

先从知识库或网页里找资料，再让模型基于资料回答。

它不是让模型“记住更多”，而是让模型“带着证据回答”。

一个最小 RAG 链路：

用户问题
  -> Embedding 检索相关片段
  -> 片段重排和去重
  -> 拼进 prompt
  -> 要求模型只基于资料回答

提示词可以这样写：

你只能基于【参考资料】回答。
如果资料中没有答案，请说“资料不足，无法确认”。
不要编造函数、链接、参数或版本号。
回答最后列出你使用的资料编号。

这类约束非常适合客服、知识库问答、企业内部文档助手。

5.3 把代码任务拆成可验证步骤

AI 编程不要只说：

帮我修一下这个Bug。

更好的输入是：

目标：修复登录后跳回首页的问题。
现象：输入正确密码后，接口返回200，但前端没有跳转。
相关文件：auth.ts、login.vue、router.ts。
报错：控制台没有报错。
约束：不要改后端接口，不要引入新库。
验收：登录成功后进入/dashboard，刷新仍保持登录态。

模型越知道边界，越不容易乱改。

如果是 Agent 类工具，还可以要求它每一步落日志：

先定位原因，再给修改方案。
修改前列出会改哪些文件。
修改后运行现有测试。
不确定的地方先标记，不要自行假设。

5.4 输出后做结构化校验

如果你的业务需要 JSON、SQL、正则、配置文件，别只靠模型自觉。

要加校验器。

例如：

模型输出JSON -> JSON Schema校验 -> 失败则带错误信息重试
模型输出SQL -> 只读检查 -> EXPLAIN -> 限制表和字段
模型输出API参数 -> 白名单校验 -> 再发请求

模型擅长生成，但系统要负责验收。

5.5 保留调用日志

很多团队排查 AI 问题时只看最终答案，这是不够的。

至少要记录：

4SAPI 这类大模型API中转站的价值就在这里。

它不只是换一个 Base URL，而是把多模型调用、Key、日志、分组和成本放到一个地方管理。

6. 4SAPI 接入示例

如果你的应用已经使用 OpenAI SDK，接入 OpenAI-compatible 中转通常只要改三处：

Base URL
API Key
Model Name

示例：

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.FOURSAPI_API_KEY,
  baseURL: "https://4sapi.com/v1",
});

const completion = await client.chat.completions.create({
  model: "从4SAPI模型列表复制完整模型名",
  temperature: 0.2,
  messages: [
    {
      role: "system",
      content:
        "你是一个严谨的技术助手。没有依据时说不知道，不编造函数、版本、链接和参数。",
    },
    {
      role: "user",
      content: "根据下面的官方文档片段，解释这个API应该怎么调用：...",
    },
  ],
});

console.log(completion.choices[0]?.message?.content);

生产环境建议拆成三个模型策略：

这样比所有请求都打到最贵模型更可控。

7. 一份可直接复用的提示词

下面这段适合知识库问答和技术客服：

你是一个严谨的技术支持助手。

回答规则：
1. 只能基于我提供的【上下文】回答。
2. 如果上下文没有答案，请直接说“资料不足，无法确认”。
3. 不要编造函数名、参数名、价格、版本号、链接。
4. 如果答案依赖某段资料，请标注资料编号。
5. 如果用户问题含糊，先指出缺少什么信息，再给出可执行的下一步。

输出格式：
- 结论
- 依据
- 操作步骤
- 风险或限制

注意，这不是魔法咒语。

它真正起作用的前提是：你给了干净、可信、相关的上下文。

8. 避坑清单

最后给一份压缩版清单。

一句话总结：

AI幻觉不是靠骂模型解决的，而是靠上下文、检索、参数、校验和日志一起治理。

当你把大模型当“会生成文本的推理组件”，而不是“永远正确的数据库”，整个应用设计都会稳很多。

下一篇我们继续往下讲：参数、Token、MoE、推理模型、多模态这些概念，最终都会落到一个问题上：

每个任务到底该选哪个模型，怎么少花钱还少翻车？

参考资料：

• Attention Is All You Need
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Lost in the Middle: How Language Models Use Long Contexts
• OpenAI Prompt Engineering Guide
• OpenAI API Reference