🤖 AI

Graphical-Probabilistic Modeling of Generative Flows in LLM-Native Software Systems

本文提出了“生成网络”（Generation Networks），这是一个基于图形概率模型的框架，旨在为大语言模型原生软件系统中固有的随机性、提示词依赖型行为引入原则性的设计级推理与分析。

原作者： Víctor A. Braberman, Flavia Bonomo-Braberman

发布于 2026-06-16

📖 1 分钟阅读☕ 轻松阅读

原作者： Víctor A. Braberman, Flavia Bonomo-Braberman

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正试图建造一座房子，但你使用的不是砖块和砂浆，而是一个神奇且难以捉摸的精灵。这个精灵（即大语言模型，或 LLM）才华横溢，但它并不总是能完全按照你的要求去做。它有时会分心，有时会产生幻觉，而且它的情绪也会根据你提出请求的方式（即“提示词”）而变化。

目前，利用这些精灵来构建软件就像是通过对着精灵大喊指令，并寄希望于墙壁能长得笔直一样。这里没有蓝图，没有标准规则，如果房子塌了，也很难查明原因。你只知道：“嗯，这次精灵没听话。”

问题所在：
本文的作者认为，我们需要一种更好的方式来设计这些“由精灵驱动”的系统。我们需要一种语言来绘制蓝图，这种蓝图要能够考虑到这个精灵是有些混乱的这一事实。

解决方案：“生成网络”（Generation Networks）
作者提出了一种绘制这些蓝图的新方法，他们称之为生成网络。你可以把它想象成一种特殊的流程图，它不仅显示发生了什么，还显示不同结果发生的可能性有多大。

以下是该方案的拆解，通过简单的概念进行说明：

1. 行程地图（图/Graph）

想象一张地图，每一个停靠点都是一段信息。

节点（停靠点）： 这些是系统已知或创建的事物。有些是你输入的东西（如用户的提问），有些是系统创建的东西（如摘要或代码片段）。
箭头（路径）： 这些展示了信息如何从一个停靠点流向下一个停靠点。
转折之处： 在普通的软件中，路径是直线。如果你输入“A”，总会得到“B”。但在这种新地图中，有些路径是波浪状且模糊的。如果要求精灵总结一个故事，它每次生成的摘要可能会略有不同。这张地图通过将输出视为一个“可能性的云团”而非一个固定的点，从而承认了这一点。

2. 两类工人

论文将该系统中的工人分为两支队伍：

确定性团队（机器人）： 这些是标准的计算机程序。如果你要求它们查找文件或进行数学运算，它们每次都会执行得完全一样。在地图中，它们表现为实心的、直线型的线条。
生成式团队（精灵）： 这些是 LLM。它们接收指令并创造新内容。因为它们是概率性的（基于随机性），所以地图将它们展示为模糊的云团。论文建议我们可以通过描绘这些云团，来展示精灵在给定指令下可能做出的行为。

3. 绘制规则（“处方/指令”）

这个想法中最酷的部分之一是，你可以直接在蓝图上编写规则。

“黄金标准”： 假设你已经写下了一个“完美”的答案。蓝图可以包含一条规则，例如：“精灵的回答必须与黄金标准有 95% 的相似度。”
“安全网”： 你还可以画一条规则，例如：“如果精灵被问及一个它并不了解的话题，它必须承认自己不知道，而不是胡编乱造。”

这使得蓝图从一张简单的图纸变成了一份合同。它允许工程师说：“我们设计这个系统是为了使其表现得像这样，”然后检查系统是否真的遵循了这份合同。

4. 测试“如果……会怎样”的情景

论文还建议使用这些地图来进行“如果……会怎样”的游戏，而无需实际构建系统。

提示词调优器： 你可以问：“如果我们给精灵三个例子而不是一个例子，会怎样？”地图可以帮助你计算这种改变是否会让精灵变得更准确。
破坏者： 你可以问：“如果精灵在第 2 步感到困惑并给出了错误的答案，会怎样？整个系统会崩溃吗，还是它能恢复过来？”地图可以帮助你观察错误是如何扩散的。

5. 比较设计方案

最后，作者展示了如何使用这些地图来比较构建同一事物的两种不同方式。

设计 A： 要求精灵在一个巨大的步骤中完成所有事情。
设计 B： 要求精灵将问题分解为三个较小的步骤。
地图允许你在编写哪怕一行代码之前，就能通过数学手段证明设计 B 失败的可能性更低，或者它更有可能找到正确答案。

大局观

简而言之，这篇论文为构建 AI 软件的工程师提出了一种新的“语言”。他们不再只是猜测和尝试，而是绘制一个生成网络。这个网络是流程图与天气图的结合体：它展示了数据的路径，同时也展示了“风暴”（不确定性）和“晴天”（高成功概率）。

其目的是为 AI 软件带来与我们几十年来在常规软件中所拥有的同等水平的规划、安全性和清晰度，同时承认虽然 AI 是神奇的，但围绕它构建的系统必须是稳固且可预测的。

技术摘要：LLM 原生软件系统中的生成流图形概率建模

问题陈述
LLM 原生软件系统的工程化仍是一项具有挑战性且在很大程度上依赖于经验主义的学科。目前的开发实践高度依赖于探索性启发式方法，例如提示词工程（prompt engineering）、上下文微调（context tuning）和工作流脚本编写。虽然这些技术在孤立状态下有效，但它们缺乏传统软件工程中所具备的原则性结构、抽象机制和设计级推理能力。因此，由于大语言模型（LLM）具有随机性和依赖提示词的特性，该领域在缺乏形式化方法来记录系统行为的情况下，在分析、维护和复用方面面临困难。

方法论：生成网络 (Generation Networks, GNs)
为了填补这些空白，作者提出了生成网络 (GNs)，这是一个基于针对 LLM 中心化架构定制的图形概率模型的框架。该方法通过三个主要层级进行：

数据依赖图 (Data-Dependency Graphs, DDGs)： 该方法的基础是将系统执行建模为有向无环图（DAG）。
- 节点： 代表具有概念类型的数据实例，包括输入、内部变量和输出。
- 边：将这些节点连接起来的数据转换。作者将其分为两类：
  - 基于 LLM 的转换： 随机过程，其中 LLM 根据提示词（指令、示例和父变量值）生成内容。这些被视为由 Token 生成过程隐式定义的条件概率分布。
  - 算法转换： 确定性过程，例如数据投影或向量数据库检索。
- 向贝叶斯网络映射： 鉴于输入和 LLM 转换的内在随机性，DDG 被映射到贝叶斯网络 (BN)。在此形式化过程中，节点变为随机变量，图结构编码了它们之间的条件独立性和因果关系。
建模设计属性： 该框架不仅限于简单的流程可视化，还能够捕捉细致的设计级属性。
- 显式控制变量： 该符号允许包含分布控制变量（例如模型参数 $\theta$ 、温度、超参数）和领域选择变量（例如区分基准测试、合成数据或“野外”数据分布）。
- 潜在与概念变量： 模型可以包含不可观测的量，例如真实输出或关于正确性的布尔指标，以表达预期的系统属性。
- 形式化查询： 该框架支持对联合概率分布进行一阶公式运算，利用来自因果建模的两种经典操作：
  - 概率查询： $P_N(Y | E=e)$ （给定证据的后验概率）。
  - 干预查询： $P_{N_{Z=z}}(Y | E=x)$ （在强制执行某种操纵后的后验分布，捕捉因果推理）。
用例与表达能力： 论文通过三个特定场景阐释了该框架的效用：
- 规定行为： 将性能约束形式化（例如，确保转换在基准测试数据上达到 $\geq 1-\epsilon$ 的正确率，同时保持与目标领域的分布相似性）。
- 探索机制参数： 将提示词配置（例如少样本示例）视为干预变量，通过基于模型的搜索来优化特定结果（ $s^* = \arg \max P(\text{success})$ ）。
- 断言设计改进： 定义布尔变量以比较替代设计（例如，单步与分解后的两步流水线），从而以概率方式量化回归风险和性能增益。

核心贡献

一种结构化符号： 引入生成网络，为记录和推理 LLM 赋能系统的结构与行为提供了统一的词汇，架起了软件工程抽象与概率建模形式化方法之间的桥梁。
处理随机性： 该方法在保持建模确定性算法组件能力的同时，显式地考虑了 LLM 的概率性质，从而能够分析涌现现象和系统级属性。
设计级推理： 该框架能够形式化表达设计愿景，包括关于系统行为、鲁棒性和组合性的描述性、预测性和规范性陈述。

结果与主张
本文并未呈现经验性的实验结果或新的推理引擎。相反，其“结果”是该框架表达能力的概念性演示。作者声称，生成网络为以下方面提供了原则性的基础：

沟通和记录复杂的生成流。
推理系统级属性，如正确性、鲁棒性和设计改进。
阐明确定性逻辑与随机生成之间的相互作用。

作者将这项工作定位为迈向“生成式系统原则化、基于模型的工程学科”的一步。

意义与未来方向
这项工作的意义在于试图将传统软件工程的严谨性（模块化、抽象、形式化规范）引入新兴的 LLM 原生开发领域。通过将提示词和超参数视为概率图中的干预变量，该框架允许对优化和调优任务进行声明式规范。

作者概述了几个未来的研究方向：

分析集成： 利用概率编程和图形建模的方法，在定义了具体实现后，支持经验或符号推理。
可扩展性与抽象： 将模型扩展到处理具有不同交互深度的复杂生成轨迹，并探索用于层次化表示的因果抽象。
组合分析： 使用 GNs 来验证链式转换之间的分布兼容性，并推理组合系统在不同训练和部署假设下的鲁棒性。