怎么堵住 AI 胡说八道的嘴

不管是在网上,还是和身边朋友聊天时,经常看到有人吐槽 AI 胡编乱造。 相信最近很多人都刷到过一个很搞笑的事件:一位网友轻信豆某包关于机票退票手续费仅 5% 的建议,实际被扣 40%,损失 600 元。豆某包随后生成“赔付承诺书”却因无法转账反悔,并支招网友起诉自己,该网友随后便向法院提交了立案申请。 这类问题在 AI 应用里有一个专门的说法,叫“幻觉”(Hallucination)。 今天我想聊聊,AI 为什么会产生幻觉,以及我们在日常使用中,怎么尽量降低它胡编乱造的概率。 AI 为什么会胡编乱造? 你有没有好奇过,为什么 AI 明明不知道答案,却还能说得那么完整? 很多人会把 AI 想象成一个巨大的资料库。我们问一个问题,它就去资料库里查一条记录,然后把结果返回给我们。 但大模型默认并不是这么工作的。 我们可以简单粗暴地理解为:大模型更像一个“超级文字接龙机”。当然,这只是一个方便理解的比喻。现代大模型在训练中确实学到了很多概念、知识和推理模式,但它最基础的生成方式,仍然是根据前面的上下文,预测后面接什么内容最合理。 比如我说“锄禾日当”,模型很容易接出“午”。因为在它见过的大量文本里,这两个词经常连在一起。 如果问题是写一段文案、整理一份提纲,这种能力非常好用。但如果问题是“某个政策是哪天发布的”“某个案例是否真实存在”,它就可能出问题。因为这类问题需要核对事实,而不是只生成一段看起来顺的文字。 我们可以把没有检索工具参与的回答过程,看成一次“闭卷考试”: flowchart TD User[用户提问: 帮我查某行业市场数据] Model[大语言模型] Context{上下文里有可靠依据吗?} Guess[根据语言模式生成回答] Detail[补全听起来合理的细节] Answer[输出一段看似完整的回答] User --> Model Model --> Context Context -- "依据充分" --> Answer Context -- "依据不足" --> Guess Guess --> Detail Detail --> Answer 所以我们会看到一种很奇怪的现象:它不是简单地说“不知道”,而是生成了一段看起来有帮助的回答。问题在于,看起来有帮助,不等于事实上可靠。 那如果我们在提示词里写“不要编造,不知道就说不知道”,有没有用? 有用,但不是保险丝。它通常能降低一部分风险,但只要模型手里没有可靠证据,而你的问题又要求它给出完整答案,它仍然可能根据模糊记忆和语言模式,生成一段没有依据的内容。 所以,减少幻觉的关键,不是反复提醒它“你不许编”,而是改变任务结构。 怎么让 AI 少胡编乱造? 让 AI 先查资料 最直接的办法,是让 AI 不要只凭印象回答,而是先检索资料,再基于资料总结。 ...

六月 11, 2026 · 2 分钟 · 264 字 · 硅言硅语

Markdown - AI 时代的万能转换器

我们在上一篇中讲了 Agent + Markdown 作为私有知识库的可能性,今天我想分享一些我对 Markdown 的认识。 我与 Markdown 的不解之缘 我已经记不清第一次看到 Markdown 这个词是什么时候了,或许是第一次接触开源项目,看到项目下的 README.md,又或许是当年玩博客的时候,寻找好用的编辑器的时候发现的。 总之它在我的工作和生活中,出现的频率越来越高。因为我是一个程序员,所以接触得算是比较早的。早期只用它来写项目的文档。后来用 hugo 搭建了基于 Markdown 的个人网站,这样我可以把更多精力放在内容输出上,不用管排版这些琐事。再后来,市面上涌现了诸如 Obsidian、Logseq 这样优秀的双链笔记软件,它们无一例外地将 Markdown 作为底层格式,让它一跃成为了个人知识库管理(PKM)的绝对主力。现在呢,作为AI应用的开发者,几乎每天都用到它,因为几乎所有主流大模型的 API 在默认情况下都采用 Markdown 格式进行输出。 大模型的通用语言 你有没有好奇过,你在与AI对话的时候,AI应用是怎么展现那么丰富且有层次的内容的?比如下图是我与 Grok 的对话,它的回答包含了表格、无序列表。 这只是比较简单的回答,它的表现力远不止于此。那它是怎么实现的?答案是 Markdown。模型层面给出的内容如下图: 我们可以把一个AI应用分成2个抽象层:模型层和应用层。当我们发起提问时,应用层将问题转发给模型;模型经过计算,生成纯文本的 Markdown 内容作为回答;而像 Grok 网页端或手机 APP 这样的应用层,在接收到 Markdown 后,会利用内置的渲染器将其转换成丰富的视觉效果呈现给我们。这形成了一个完整的交互闭环: flowchart TD User((用户)) subgraph App [应用层] Input[对话输入框] Renderer[Markdown 渲染器] Output[富文本视图展现] Renderer --> Output end subgraph Model [模型层] LLM(大语言模型) end User -- "1. 提问/输入提示词" --> Input Input -- "2. 转发请求" --> LLM LLM -- "3. 返回 Markdown 纯文本" --> Renderer Output -- "4. 呈现最终结果" --> User 所以,我们可以简单粗暴地理解为:Markdown 是大语言模型向人类表达世界的通用语言。 ...

六月 10, 2026 · 2 分钟 · 272 字 · 硅言硅语

个人知识库方案之Markdown

本文面向非技术用户,笔者尽自己最大可能表达得通俗易懂。 从 Chatbot 到 Agent 从 2022 年 11 月 OpenAI 首次向公众开放 ChatGPT 到今天,LLM(大语言模型)和相关生态的发展可谓日新月异。 最开始的时候,人们只是把它当成一个聊天机器人,用来写文案、解答问题、生成代码和翻译等。但 LLM 发展到了今天,情况已经彻底不同。我们已经从单纯的 Chatbot 时代,进入 Agent 时代。 如果你知道什么是 Agent, 请跳过这部分。 这个 Agent,国内翻译过来叫做智能体。我感觉这个翻译有点玄乎,所以特意去搜了一下其他中文区(港台)的人是怎么翻译的,人们经常直接使用英文原词 Agent,或者称之为“代理”。我认为直接叫 Agent 更让人容易理解,因为它本质上就是一个大模型和其他系统的代理,所以在本文中我们就直接叫 Agent 。 那我们经常听到大模型和Agent,它们到底是什么关系?其实一句话就能说清楚:大模型是“大脑”,而 Agent 是它的“手”。 ​大模型本质上是一个纯粹的“输入输出模型”。它的知识在训练完成的那一刻就被冻结了,它没有眼睛,也没有触角,无法主动连接这个世界。你给它什么输入,它就给你什么输出。 Agent 就像是一个中间代理。它可以去浏览网页、获取最新的新闻、读取你本地的文件、甚至调用各种外部工具。它把抓取到的最新信息,重新打包,源源不断地“喂”给大模型。​大模型负责思考,Agent 负责连接。 graph TD User((🧑‍💻 用户)) -->|发指令| Agent{🤖 Agent} Agent -->|调动| Tools[🌐 网页 / 📁 文件 / 🔧 工具] Tools -->|返回真实世界信息| Agent Agent -->|整理打包并提交| LLM((🧠 大模型)) LLM -->|思考并解答| Agent Agent -->|把大模型的答案交付给| User classDef user fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px; classDef agent fill:#fff9c4,stroke:#fbc02d,stroke-width:2px; classDef llm fill:#fce4ec,stroke:#f06292,stroke-width:2px; class User user; class Agent agent; class LLM llm; 我们举个例子,在 ChatGPT 刚发布的时候,你问它今天有什么新闻?它会跟你说:“对不起,我的知识截止到某年某月某日”。那今天我们去问AI,今天有什么新闻?它能够回答了,因为它现在可以通过 Agent 去查询新闻网站上面的讯息。 ...

六月 8, 2026 · 2 分钟 · 248 字 · 硅言硅语