AI 笔记

大模型

大模型幻觉(Hallucination in LLMs)

大模型一本正经地胡扯(胡扯指数,Bullshit Index)。幻觉是否是智力特征,不能从根本消除?

幻觉来源:

幻觉检测:

幻觉缓解 Hallucination Mitigation:

幻觉引发的可靠性问题已经成为制约大模型在企业级应用落地的瓶颈。一种新的缓解策略是通过工程化方式,工程化在不同的领域有着不同的表现形式,可以归纳为2点:分解与核验。

行业最佳实践往往存在于专家的大脑中,任务执行依赖人的随机应变。但这种方式难以规模化,并且容易因个体差异导致执行出现偏差。将业务逻辑程序化,避免自然语言的歧义与模糊性,并将复杂业务逻辑分拆到可核验的颗粒度,以支撑后继的高效核验,同时提供与编程语言类似的大规模可扩展能力。

AI

社会影响

如果人们不再想为互联网生产内容,那 AI 又将从哪里获取它所需要的信息?如果人类不再亲自阅读互联网内容,因此也不再看广告。

好的 AI 用例--安全漏洞赏金项目。项目会收到海量的报告——某个研究员声称在我们的应用里发现了漏洞。我们必须处理这些报告。我们大概会收到……可能一个季度 300 份报告之类的数量。但真正“靠谱、有效、值得修”的——大概只有 3 份。 真正有价值的比例大概只有 1%。而这个 1% 非常重要,因为它们可能真的指出了一个严重问题,我们必须修。但为了抓住这 1%,你必须花巨大精力去验证剩下 99% 的垃圾——这对团队来说是巨大的麻烦、巨大的时间黑洞、巨大的烦躁来源。 AI 能在报告进来时就先处理一遍,给我们一个初步判断——“这到底是扯淡,还是不扯淡?”然后还会帮我们写回复邮件。 而写回复其实才是痛点的一半:当 99% 的提交都是彻头彻尾的狗屎,写这些狗屎的人还常常—— 根本不懂自己在说什么,却又特别理直气壮,还特别不耐烦,甚至还一副“你必须立刻给我 5000 美金赏金”的态度。 这时候让人类程序员保持冷静、不直接对他们开喷,是很难的。AI 就完全没这个负担。它特别乐意用一种非常冷静的语气写一大段回复:“为什么你这个东西不成立。”它帮我们省了大量时间。 以前要看 100 份报告,现在可能只要看 5 份——这就是真实的生产力提升。就算你最后要看 10 份、20 份,只要你能把原本 100 份的工作压缩到 20 份,这就是 AI 承诺的生产力收益。如果我们能把这种压缩能力用到业务的其他方面——那简直太好了。

待改进的 AI 用例--客服支持(support)。support 很微妙:如果你只能 90% 正确,那其实很糟糕。因为这意味着你会有 10% 的概率把事情说错——而且是对着客户说错。如果给客户一个完全错误的答案,让客户体验很差,客户可能就直接流失了。 那这个客户的终生价值是多少? 你以为 AI 带来的那点“节省成本”,可能瞬间就被一次流失抵消得干干净净。目前效果不太行。但一切都在飞速变化。

作为一个文明整体,我们最终仍然会在更多类别、更多细分领域里,更快地获得更好的软件。问题的一部分在于:无论是 Web 开发圈,还是独立开发者(indie hacker)圈,很多讨论都过于短视地集中在那些我们一直反复折腾的“通用大类”上。当你解决的是自己的问题时,你立刻就能判断你做出来的软件到底好不好。

Opus 5 和 Genie 3 渲染3维场景区别

Opus 5 生成是一套显示程序,开发者可以阅读、修改和复用代码,缺点是视觉粗糙。Genie 3 是生成式视频,根据操作预测下一帧画面,视觉表现丰富。Opus 5 面临问题:模型能否连续工作(比如2+小时),组织数千行代码,完成后自己运行,发现并解决 bug。

AI 落地

2026年企业 AI 已进入到企业认知(Enterprise Cognition)阶段。从 SaaS 和数据平台内部生长出来的 Agent,可能比独立 Agent 更容易进入企业核心业务。它们不一定拥更强的模型,却天然靠近客户的敏感数据,熟悉业务规则,无需重新搭建权限体系。数据背后就是业务,业务背后就是权限。

Open Semantic Interchange 项目在2026年被 Apache 软件基金会接纳进入孵化器,并更名为 Apache Ossie。它试图用厂商中立、机器可读的格式,描述指标、维度、数据集及其关系,让 ETL、数据平台、BI 工具和 AI Agent 能够交换语义模型,而不是只交换原始数据。

企业需要把数据转化为语义,把语义组织成认知,再把认知转化为 Agent 可以遵循的决策规则。最终,Agent 才能从“会查询企业数据”,进化到“理解企业如何运转”,并在权限范围内参与业务流程。

当 AI 进入参与决策并执行阶段时,新问题是企业如何设置自主边界,做好风控,如何判断 AI 对错和好坏,企业核心资产是否会因 AI 流失,承担责任的最终是人。

AI 代码检查

Grady Booch:测试覆盖率和复杂度指标可以让我们对功能正确性抱有信心,却无法发现 Agent 是否引入安全漏洞、生成无效死代码悄悄侵蚀后续的可维护性,或是漏掉对性能至关重要的逻辑拆分。

Uncle Bob 为 Agent 设置了强约束体系:单元测试、Gherkin 验收测试、QA 测试流程、圈复杂度阈值、模块大小限制、依赖结构分析、变异测试(mutation testing)以及测试覆盖率要求。核心逻辑是:只要 AI 生成的代码能够全部通过这一道道关卡,即便没人读过一行函数内部实现,也有充分理由相信代码的正确性。

Uncle Bob:Agent 速度快、智能化程度高,但也和人类一样无法应对极度混乱的代码。只是它们的容错阈值和人类略有不同,但依然存在上限。Agent 的短期记忆能力远超人类,容量更大、精度更高,能处理更复杂的代码逻辑。如今编程的修改成本已经无限趋近于零,没有必要耗费大量精力做重度前置规划。让 AI 先完成单个、小型需求迭代,结束后人工复盘架构、优化结构,再推进下一轮迭代,逐步完善整体系统。

单是变异测试这项技术,就会系统性改动源代码,其严谨程度已经超过绝大多数普通工程团队的人工评审流程。但这种模式需要前期投入巨大成本,极强的工程纪律,而绝大多数团队并不具备,也很难快速建立这套能力。变异测试原理:通过程序遍历源代码,对代码中的正负号、大小于符号、等于符号等逻辑符号进行反转修改,随后运行全套测试用例。正常情况下,代码逻辑被修改后,测试用例必然会报错;如果测试用例依旧通过,就说明存在“存活变异体”,代表这段代码存在测试漏洞,必须修复。

模型的上下文窗口存在注意力机制偏差,开头和结尾的信息权重更高、优先级更强,而中间的内容会被弱化、忽略。如果规范提示词过长,大部分规则都会落入上下文窗口的中间区域,直接被模型无视。随着迭代推进,上下文信息不断累积,模型根本无法筛选全部有效规则。 但自动化检测工具不会出现这种问题,规则固定、执行确定性强,不会被上下文窗口的机制影响。使用 AI Agent 的核心技巧,就是精简初始提示词,只保留最核心的规则,让所有关键信息都处于高优先级区域,剩余的规范约束,全部依靠后置自动化工具落地。

更新于[2026-08-25]

文章参考