Posts

不管是在网上，还是和身边朋友聊天时，经常看到有人吐槽 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 不要只凭印象回答，而是先检索资料，再基于资料总结。 ...

我们在上一篇中讲了 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 是大语言模型向人类表达世界的通用语言。 ...

本文面向非技术用户，笔者尽自己最大可能表达得通俗易懂。 从 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 去查询新闻网站上面的讯息。 ...