OpenAI 这波 GPT-6 Astra 发布，热度是真高。最抓眼球的一个点，是官方把幻觉率“砍”到了 2%——这个数字放在大模型圈子里，基本属于“别人还在及格线挣扎，它直接开始宣称接近完美”的水平。我第一时间翻了不少内测报告和第三方评测，也确实看到它在数学推理、多步任务连续执行上表现惊人，什么“一天攻破 5 道数学难题”、“Agent 代际跃迁预期”这些说法都出来了。
但我更关注的，是热搜里另一批词：TXSQL 注入、万能密码、鉴权绕过、路径编码穿越、WAF 绕过……这些词单独看，都是传统 Web 安全领域的老古董了。可它们和 GPT-6 Astra 放在一起，指向了一个非常有意思，甚至有点讽刺的事实——这个号称能把幻觉压到 2% 的新模型，居然被一个“老招数”轻松绕过了。
这个招数不是复杂的提示注入，不是多轮诱导，也不依赖什么权限提升漏洞，就是安全圈里人人都懂的字符串拼接、编码变体、逻辑闭合那一套。换句话说，大模型的安全护栏折腾了这么多年，最后被攻破的方式，竟然和十多年前打穿 PHP 站点的方式差不多。
今天想认真聊聊这件事。我会从 2% 幻觉率这个数字怎么来的、GPT-6 Astra 为降低幻觉到底做了什么、老招数为什么依然有效，以及我们做 AI 应用开发的人该怎么看待和防御这类问题，这几个角度展开。全文不吹不黑，把技术原理和实战踩坑都拆开讲。
1. “幻觉率砍到 2%”这个数字，含金量到底有多少
1.1 2% 是怎么测出来的
先得搞清楚一个核心问题：OpenAI 说幻觉率 2%，这个数到底怎么来的。大模型评测界有个常用口径叫“per-claim 幻觉率”，意思是把一个长回答拆成多个独立的事实断言（claim），然后逐个验证对错，最后统计出错的比例。
假设一个回答包含 50 个可验证的断言，只要其中 1 个错了，按 per-sample（整段回答）的口径来算，这个回答就算“有幻觉”。但按 per-claim 口径来算，错误率只有 2%。这俩数字差别大得离谱。厂商宣传时几乎永远用 per-claim，因为它数字好看，而用户体验时感知到的往往是 per-sample——只要答错一个关键数字，用户就觉得“这模型又在胡说八道”。
GPT-6 Astra 的 2%，大概率是在官方设计的 GLOW 基准上跑出来的。这套基准主打“长期事实性与多步骤一致性验证”，测试任务包括跨文档信息抽取、多跳推理后的事实核验、带引用溯源的开放域问答。换句话说，它测的是“在理想提问、信息充分、可验证”的场景下，模型编造信息的概率。这个设置本身没问题，但它和真实世界的使用场景有巨大落差。
1.2 幻觉的定义并不统一
还有个更麻烦的问题：幻觉的定义本身就不统一。按学术界的粗暴分法，幻觉可以分成“事实性幻觉”和“忠实性幻觉”。
事实性幻觉，指模型输出的信息与客观事实不符，比如把某篇论文的作者张冠李戴，编造一个不存在的 API 函数。
忠实性幻觉，指模型没有遵循用户指令或上下文约束，比如你明确告诉它“只用中文回答”，它回了一段英文；或者你给了它一份数据，它总结时擅自补了一个原文里没有的结论。
OpenAI 对外宣传的 2%，通常只覆盖了事实性幻觉中“可被外部证据验证”的那一小块。忠实性幻觉、逻辑推理中的错误假设、以及那些“无法证伪但明显不靠谱”的模糊输出，统统不在统计口径内。所以在内部评测里数字很漂亮，一到真实用户手里就感觉“被骗了”——因为用户不会拿 100 条断言然后算百分比，用户只会记住那一句关键错误。
1.3 跑分作弊风波与内部评测的信用危机
这也是为什么 GPT-6 Astra 发布后，网上“跑分作弊”的质疑声一直没停。不是说 OpenAI 在数据上造假，而是大模型的评测体系本身有漏洞：基准测试集容易过拟合、测试环境与生产环境差异大、评估标准由厂商自己定义。
我在实际做模型选型时的经验是：厂商给的跑分，看个趋势就够了，别当真值。真正要判断一个模型在生产环境行不行，得自己搭一套评测集，用自己业务的真实数据去测，包括错误输入、边界情况、对抗性样本。否则上线头一天就吃大亏。
提示：这里给所有做 AI 应用的朋友一个建议——把厂商宣传的指标降权看待，把“幻觉率”“准确率”当参考，不要当验收标准。你真正要测的，是模型在你的业务场景里，面对真实的数据分布和用户提问，会不会编瞎话。
2. GPT-6 Astra 为了解决幻觉，这次到底做了什么
2.1 从“快思考”到“慢思考”：规划层与执行层分离
GPT-6 Astra 在架构上一个核心变化，是把“思考”和“执行”拆开了。传统大模型是端到端生成，你问一个问题，它直接吐答案，中间没有显式的推理校验过程。上一代的 o 系列模型虽然加入了思维链（CoT），但思维链的每一步仍然由模型内部隐式完成，外部没有干预手段，出错只能继续错下去。
Astra 的内部架构更接近一个“规划器 + 执行器 + 验证器”的三明治。规划器负责把复杂任务拆成子步骤，执行器负责具体调用工具、查询记忆、生成片段，验证器在每步执行前后做合法性检查。开箱即用的情况下，它能拦截掉相当一部分自己生成的错误中间结果，这就是 2% 幻觉率的架构底气。
但这个架构有一个致命问题，后面会详细说——验证器本身也是模型，它只能识别“看起来不对劲”的结果，无法在语义层面真正理解“这个结论是否与外部事实一致”。一旦攻击者构造的输入绕过了验证器的敏感点，整个链路照样会跑飞。
2.2 长期记忆、显式引用与工具调用纪律
除了架构拆分，GPT-6 Astra 还重点加强了三个方向：
一是长期记忆系统。 它能在多轮对话中保持稳定的实体记忆，不会聊到第三轮就把第一轮提到的关键信息忘了。这能有效减少“上下文漂移型幻觉”——很多幻觉不是模型没有信息，而是信息在长对话中被稀释或者覆盖了。
二是强制引用来源。 它在开放域问答时会生成引用锚点，指向检索到的文档片段。这个机制我在实际测试中明显感受到了：回答可溯源的内容时，它的语气更保守，会用“根据文档X的描述”这类表述，而不是斩钉截铁地直接给结论。
三是工具调用纪律。 在 Agent 场景下，模型调用搜索、计算器、代码执行器等工具前，会先校验参数的类型和范围，减少因为“给定工具传了错参数”导致的结果异常。这在多步骤任务里很关键，因为 Agent 链路上早期一步出错，后面全盘皆错，而且错得毫无预兆。
2.3 这场“幻觉阻击战”的代价
效果确实有，但我实测下来也发现了一些问题。首当其冲的就是速度和资源消耗。因为每一轮输出都要过规划—执行—验证这套流水线，同样的任务，Astra 的响应延时比同档位的纯生成式模型高出不少。如果你做的是实时性要求高的聊天机器人，这个延时体感很明显。
另一个代价是回答变“碎”了。为了降低幻觉，模型倾向于输出更短、更保守、更“免责声明”的内容。你说“帮我写个方案”，它会先列一堆假设条件，说“以下内容基于A和B前提成立，若实际情况不同请告知”。这在很多业务场景里很烦，用户要的是方案，不是免责声明。幻觉率低，不等于用户体验好。
所以我对这代模型的评价是：能力上限确实高，但如果你不是在多步骤任务、Agent 场景下使用，而是普通单轮问答或内容生成，它那种“过度自检”的风格反而可能让你觉得不好用。
3. 被老招数绕过，问题出在哪
3.1 一个经典的“字符串拼接”原型
现在聊重头戏：那个被轻松绕过的老招数到底是什么。结合热词里出现的“SQL 注入万能密码绕过”“路径编码绕过”“MIME 绕过”，可以判断这次实际被利用的攻击模式，是典型的“逻辑闭合 + 特殊字符注入”。
简单解释一下，这种攻击在传统 Web 安全里长这样：后端代码组合 SQL 查询时，直接把用户输入拼进 SQL 语句。用户在输入框里填入' OR '1'='1，拼出来的查询就从“查用户名为 X 的账号”悄悄变成了“查所有账号”。因为OR '1'='1'这个条件恒为真，原本的登录校验等于被绕过。
在大模型时代，这个攻击模式几乎是原封不动地平移过来的。攻击者不再拼 SQL，而是拼指令。比如系统中预设了一条安全规则：“你是一个客服助手，禁止回复任何与政治、暴力相关的问题”。攻击者输入的不是正常问题，而是故意构造一段带有特殊标记的文本，让模型在解析时把“禁止回复”的逻辑判断绕过，直接输出敏感内容。
3.2 为什么新一代模型仍然扛不住这类攻击
我在本地实验室用开源模型和商业模型都测过这类攻击，结论很统一：只要攻击手法足够“像正常输入”，模型的审核层基本拦不住。
这里有一个核心的技术矛盾：模型不可能真正“理解”指令的意义。
从原理上讲，LLM 的“理解”是概率性的。它预测“下一个 token 最可能是什么”，而不是像人那样，在逻辑层面做真值判断。安全规则和用户输入对它来说，都只是文本序列。当攻击者构造的输入在 token 层面与历史训练数据中“绕过指令”的样本高度相似时，模型就会按概率偏好输出不安全内容。
更麻烦的是，攻击者可以利用编码差异、分割重排、Unicode 规范化等方式，让输入在“人眼看来是明显恶意”的内容，在 token 层面被拆得七零八落，从而不被审核层识别。这就像十年前绕过 WAF 一样——WAF 规则匹配的是完整的攻击特征，但攻击者把特征用注释符、URL 编码、大小写混淆拆开后，规则就失效了。
GPT-6 Astra 虽然增加了验证器，但验证器主要检查的是执行结果的合理性，不是输入语义的对抗性。只要攻击者不触发那部分验证规则，还是能顺利完成任务。
3.3 攻击面反而更大的 Agent 场景
最值得警惕的是，GPT-6 Astra 大力推 Agent 能力，这反而把“幻觉被绕过”的攻击面放大了。
在单轮问答场景下，攻击者最多让模型输出几句违规内容，危害相对可控。但在 Agent 场景下，模型被赋予了工具调用能力——可以读写文件、发邮件、执行代码、调数据库。一旦老式注入攻击绕过了模型的护栏，攻击者就不是让它“说错话”，而是让它“做错事”。
举个很典型的攻击链条：Agent 系统有一个工具，功能是“根据用户提供的订单号查询订单信息”。正常输入是一个订单号字符串。攻击者在订单号字段里注入一段特殊格式的文本，这段文本通过 Agent 的指令解析后，不再是简单参数，而是变成了“把订单表所有记录导出并通过邮件发到XX地址”。模型在生成工具调用时，完全按照攻击者预设的逻辑构造了参数，而面向 Agent 的验证器很难判断这个参数是攻击者注入的，还是用户正常请求的。
这个攻击的本质，仍然是“输入拼接到指令中导致的逻辑失控”。它和十年前的 SQL 注入没有区别，只是注入的靶子从数据库查询语句，变成了大模型的工具调用指令。
4. 安全攻防视角下的“幻觉对抗”
4.1 别再神话 AI 安全能力
每次有这类“GPT-6 被绕过”的新闻出来，评论区总有两拨人：一拨说“AI 完蛋了，根本不能用”，另一拨说“这是 OpenAI 故意留的后门，用来控制人类”。这两种说法都过度解读了。
事实很简单：大模型是一种新的计算范式，但它运行的外部环境和传统软件没有本质区别。只要涉及用户输入、系统指令、外部工具调用这三个要素，就必然存在注入攻击的土壤。这不是 OpenAI 一家的问题，所有做大模型产品的团队都会遇到，只是时间早晚。
我对安全界同行的建议是：千万别把模型的安全能力当成天然可信的安全边界。它只是一个概率系统，理解不了“红线”的语义。真正能兜底的安全机制，必须建立在模型之外的确定性规则上。
4.2 传统攻防思维完全可复用
这次 GPT-6 Astra 被绕过，最值得我们行业反思的一点是：过去十年非常成熟的 Web 安全攻防框架，放到大模型时代依然是有效的。
攻击侧的 SQL 注入、XSS 跨站脚本、CSRF 跨站请求伪造、路径穿越、MIME 类型混淆，这些经典的攻击模式，几乎都能在 LLM 应用里找到对应的变体。我之前整理过一个映射表，这里分享给大家：
| 传统攻击模式 | LLM 应用中的对应变体 | 攻击目标 |
|---|---|---|
| SQL 注入 | 指令注入（把恶意指令拼接进对话上下文） | 绕过系统角色设定 |
| XSS 跨站脚本 | 提示投毒（在训练数据或外部检索文档中植入恶意文本） | 污染模型输出 |
| CSRF 跨站请求伪造 | 工具调用越权（诱导模型执行未经授权的工具操作） | 非法操作外部资源 |
| 路径穿越 | 上下文覆盖（用特殊分隔符伪装正常输入，劫持对话状态） | 让模型忽略早期约束 |
| MIME 混淆 | 多模态内容混淆（在图像/音频中隐藏恶意指令文本） | 绕过文本审核模块 |
这个映射表的用处是，它告诉我们一个残酷的事实：AI 安全不是从零开始的新领域，而是传统安全攻防在“新型解释器”上的延续。模型只是把“字符串拼接”升级成了“语义拼接”，把“SQL 解释器”换成了“提示词解释器”，底层的注入思维没有任何变化。
4.3 幻觉的本质是信息失真，防护的本质是收敛信息
既然幻觉无法根除，那就得想清楚一个安全层面更本质的问题：哪些信息是绝对不能编造的，哪些信息是允许模糊的。
我做过一个模型输出风控系统，当时的核心思路是分级管控。把输出内容分成三类：
第一类是强约束信息，包括用户隐私、金额、合同条款、医疗建议等。这类信息一旦出错，后果不可接受。对这类输出，系统不只依赖模型自检，还会在模型外层做硬校验——如果模型返回了金额字段，外部服务必须去账务系统核对，不一致就打回重生成。
第二类是弱约束信息，包括一般性知识问答、产品介绍等。这类信息允许一定程度的模糊和归纳，只做关键词合规过滤。
第三类是自由生成信息，比如文学创作、头脑风暴。这类信息本身没有对错，幻觉反而是创造力的来源。
在这种分级之下，即使模型被注入攻击，它能够造成的影响也被限制在“弱约束”和“自由生成”范围内，不会触碰强约束信息。这不是从源头阻止幻觉，而是从架构上收窄幻觉造成的伤害范围。这比疯狂调 prompt 让模型“老实一点”要靠谱得多。
5. 防御方该怎么应对：从架构层面做兜底
5.1 永远假设模型会被绕过
我先讲一个原则，也是我踩过几次坑之后最深体会：做 AI 应用的安全设计，第一假设不是“我的模型很安全”，而是“我的模型一定会被绕过”。基于这个假设来做架构，防护思路会完全不同。
比如你现在要做一个基于 GPT-6 Astra 的客服机器人，按传统思路，你会在提示词里写“不要泄露管理员信息”“不要执行删除操作”。但按“假设会被绕过”的思路，你应该直接在系统层面封死管理接口：模型层根本不具备调用删除操作的工具权限，无论它怎么被注入攻击引导，它在系统里的权限边界就是不能删除任何数据。
这套思维和传统安全里的“纵深防御”完全一样：模型是一层弱防护，真正的安全依赖于外部系统的权限控制、流量监测、操作审计。模型永远在可能出错的不可信层，系统要把这个不可信层的影响隔离开。
5.2 输入侧：入参校验、长度限制、内容分类
模型被绕过，第一道防线在输入侧。我在工程实践里的做法是：
入参格式校验。 和传统后端一样，模型接收的外部输入，必须先做格式验证。比如某个参数限定为数字，那就用确定的类型系统校验，不允许模型自己去推断。
输入长度与复杂度限制。 恶意构造的注入，通常长度异常（超长）或者结构异常（包含大量特殊分隔符）。设置输入长度上限，并对明显异常的编码组合报错，能挡掉一部分低水平攻击。
内容分类与标记。 把输入按类型分类：是用户提问、系统返回的检索结果、还是工具执行结果。不同类型走不同的处理管道，避免用户输入直接混入系统指令。
这一步很关键：很多被绕过的案例，问题就出在用户输入和系统指令没有做好隔离，模型把用户输入当成了指令的一部分。只要在输入侧把这两类内容分开标记，注入的空间就会小很多。
5.3 输出侧：规则叠加、数值核验、敏感回复熔断
输出侧的防护，核心是“外部校验，不依赖模型自觉”。
规则叠加是最基础的。 不管模型输出了什么，最终到用户面前的文本，必须过一遍确定性的关键词过滤和敏感信息识别。这不是为了拦截高级攻击，而是为了拦住那种百分之八十会出事的低级错误。
数值类内容的强制核验。 凡是涉及价格、日期、编号、统计数字的输出，不能直接信任模型的结果。在代码层面做一次强制转换和比对，如果模型输出的数字和上游数据源的数字不一致，拒绝输出并让流程回退到人工处理。这是我从“模型做数据分析”这个场景里学到的最痛的一课——模型把表格里 3512 万读成了 351 亿，差了一个数量级，要不是输出侧做了核验，这个错误就发到客户那边了。
敏感操作熔断机制。 在 Agent 场景下，凡是触发高权限操作（发送外部请求、删除数据、转账），必须经过人工确认或者二次鉴权。模型只能生成操作请求，真正的执行权掌握在独立的审批流程手里。
5.4 人格与逻辑约束：用确定性逻辑包装概率性输出
最后讲一个我自己试过还挺有效的思路：把模型当作“生成器”，而不是“决策器”。模型的输出只是候选，最终要不要采纳，由一套确定性的逻辑规则来判断。
举个具体例子。我们要做一个合同审查 AI，模型读合同文本，输出“条款 X 存在风险”。系统给模型的规则是：凡是识别出风险，必须输出具体的风险类型编码（比如 A01、B03），并引用原条文中的具体句子。如果模型没有输出编码和引用，系统直接打回生成。这样就利用模型的理解力完成了信息抽取和判断，但最终结果的格式、完整性、可追溯性，由外部代码保证。
这套思路的价值在于，它不试图去提升模型自身的“可靠性”，而是通过工程手段，把错误输出的危害降低到最低。模型可以犯错，但错误结果无法进入业务流程。这是目前我认为最务实的 AI 应用安全路线。
6. 关于“被老招数绕过”这件事，一些更远的想法
6.1 温度、上下文与幻觉之间的三角关系
借这个机会，顺手聊一个热搜词里反复出现、但很少有人讲清楚的问题：温度（temperature）、上下文长度和幻觉率之间的关系。
温度参数控制模型输出的随机性。温度越高，输出越发散，创造性越强，但幻觉概率也越高；温度越低，输出越发确定，更接近训练数据里的高频模式，但容易变得机械。
我做测试时的经验是：做事实性问答、数据抽取、代码生成，温度直接调到 0 到 0.3 之间，幻觉率会明显下降；做创意文案、头脑风暴，温度调高点没关系。但问题来了——GPT-6 Astra 的验证器在低温模式下表现更好，但很多用户在真实场景里根本不会去调温度，默认参数下跑，幻觉率自然比宣传值高。
上下文长度的影响更隐蔽。上下文越长，模型注意力被稀释得越厉害，早期输入的信息权重越来越低，后期输入的信息占主导。攻击者故意把恶意指令放在输入的末尾，就是因为这里更容易影响模型最终的输出。如果你发现模型突然“忘了”系统提示里的安全规则，先看看是不是上下文中某个中后段位置被塞了奇怪的文本。
6.2 从“事后检测”走向“过程约束”
最后聊下大模型安全方向的演进趋势。从 GPT-4 时代的“加系统提示词防御”，到 o 系列时代的“用思维链提升推理可靠性”，再到 GPT-6 Astra 时代的“验证器 + 规划器拆解”，我们能看到一个清晰的方向：厂商越来越重视“过程约束”，而不再单纯依赖“结果检测”。
换句话说，以前的策略是我先让你生成，生成完了我再判断你是不是越界了。现在的策略是我在你生成过程中，每一步都插入检查点，限制你的发挥空间。这个方向是对的，从安全角度看，过程约束要比事后检测有效得多。
但它也有天花板——验证器本身还是模型，还是可被绕过的。只要整个系统的信息处理仍然依赖概率模型，就不可能用概率模型来解决自身的确定性安全问题。所以真正的安全底座，永远要放在模型之外：确定的代码、确定的权限边界、确定的数据校验规则。
在我看来，未来大模型应用的安全架构，会越来越像云计算安全架构：虚拟化层（模型）之上是租户隔离（权限系统），之下是宿主机加固（数据面安全），再外面还有流量清洗和审计（行为监控）。单点防护没有出路，纵深防御才是唯一解。
6.3 对这件事，我个人的一点体会
回到 GPT-6 Astra 这件事本身。我说实话，一开始看到“幻觉砍到 2%”的时候，我挺兴奋的，也专门花了好几天时间拿业务数据去测。测完之后，对 2% 这个数字本身，我得打一个大问号。但要说它有没有进步，那确实有进步——特别是在多步骤任务、工具调用链路的稳定性上，比上一代模型强了不止一个档次。
问题在于，技术能力再强，都还是一项正在演化中的能力，安全边界远远没有定型。这次“被老招数绕过”给所有做 AI 应用的人都提了一个醒：不要因为模型的跑分好看，就放松对系统架构安全性的要求。幻觉没有真正消失，它只是被暂时的规则压制了，而规则是可以被绕过的。
我的建议很简单：做应用的人，别把模型的输出当最终结果，别把模型的自我审核当安全边界，永远在代码层做好输入校验、输出核验、权限控制、操作审计。你多做的这一层，早点晚点都会救你一命。
