人类、机器和Ratatouille 🐀

I’m happy to translate the article for you, but I need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line exactly as you provided and preserve all formatting, markdown, and technical terms.

介绍

对 AI 系统中系统复杂性的务实响应

很长一段时间里，我们设计数字产品的方式就像许多人想象厨房的运作方式：只要菜看起来好看，工作就完成了。我们优化了呈现效果——精美的幻灯片、漂亮的 PDF、看起来合适的文档。它们成为组织知识的默认容器，对人类来说，这大多是有效的。

当前知识呈现的问题

当代理和大型语言模型（LLM）进入“厨房”时，单纯的呈现已不再足够。如今，同样的信息必须不仅能被人类消费，还能被搜索、复用、摘要和推理的系统所使用。然而我们仍然把没有配方的精美摆盘菜肴递给机器，结果不一致时却怪厨房。

我们归因于 AI 复杂性的许多困难其实早在知识的准备阶段就已出现。

检索增强生成（RAG）及其摩擦

在许多组织中，首次认真尝试将 AI 应用于内部知识往往是通过检索增强生成（RAG）实现的。这个想法听起来很简单：拿现有文档，连接到模型，然后提问。

但在实际操作中，会出现摩擦。当知识散落在 PDF 或幻灯片中时，RAG 系统必须重建从未明确的结构。标题需要推断，章节需要猜测，分块也只能靠经验法则。从系统的角度来看，这并不是在遵循配方，而是尝尝菜肴后猜测配料。

常见的症状包括：

• 检索噪声
• 答复不一致
• 为了解决问题而不断增加的修补层，导致成本和脆弱性上升

在某个时刻，问题变得不可回避：我们为何要花如此多的精力去解释人类已经理解的信息？

来自 Ratatouille 的教训

Ratatouille 惊人地捕捉到了这个问题。Remy 是一位卓越的厨师，而 Linguini 能够在专业厨房中工作。单独来看，两人都无法持续制作出厨师级别的菜肴。使他们合作成功的不是天赋，而是共享的操作语言——手势、约束和惯例，使意图与执行保持一致。没有这种语言，厨房就会陷入混乱；有了它，结果就可以重复。

现代 AI 系统面临同样的挑战。人类直观地理解意义，而机器则精确执行。没有共享的知识表示，系统只能猜测。

为什么结构化格式很重要

专业厨房的运作并不依赖于摆盘，而是依赖 配方。配方使结构显式化，并让多位厨师在无需猜测的情况下协同工作。为人类和机器设计遵循相同的逻辑。

• 人类 需要叙事性和可读性。
• 机器 需要明确的结构和无歧义的含义。

这正是基于文本的结构化格式变得至关重要的地方。

Markdown 作为协作层

Markdown 的价值不在于它简单，而在于它是显式的。它对人类可读，易于版本控制和差异比较，并且可以直接用程序处理。更重要的是，Markdown 将文本视为一种接口。当代理和大型语言模型（LLMs）与知识交互时，它们并不消费视觉内容，而是消费结构化信息。

单一的 Markdown 源文件可以为人类渲染，同时仍可被系统、流水线和自动化代理直接使用。从这个意义上说，Markdown 更侧重于协作，而不是单纯的文档编写。

对RAG系统的影响

许多RAG系统的局限并非源于模型能力，而是源于最初知识的组织方式。当渲染后的文档成为唯一可信来源时，下游系统必须事后逆向解析其含义。当知识首先以结构化、语义透明的格式创建时，整类问题将不复存在：

• 检索效果提升
• 维护成本下降
• 系统更易扩展

在AI系统中，表示方式往往是隐藏的瓶颈。

结论

• 《料理鼠王》并不是真正关于学习烹饪的故事——雷米已经具备了技能。真正的挑战是让协作在复杂系统中成为可能。

• 在你的系统中，哪些地方仍然让机器从成品中猜测配方？有时，优化开发需要先写好配方，再上菜。