llm_as_probabilistic_system_20260520_manual

方法论库 · 引用级 · none

本页是 <code>contexts/methodology/llm_as_probabilistic_system_20260520_manual.md</code> 的逐字投影（仅隐私清洗，零改写）。

name: llm_as_probabilistic_system_20260520_manual
description: LLM 作为概率系统的任务设计
domain: infra
consumption:
  surface: none
  trigger: ""
  consumer: orchestrator
status: library
promoted_to: null

LLM 作为概率系统：定义、性质与任务设计

Date: 2026-05-20
Mode: manual synthesis with sub-agent evidence extraction
Status: v0.1 research report
Scope: LLM Harness KB、能力边界 survey、Large Context 方法、Skill Draft 书籍案例、用户 axioms、少量外部基础论文
Version note: 本文件是新增 Y 级调研产物；建议在载体 commit 后使用下一可用编号打 0.Y-research-llm-probabilistic-system。本轮未执行 git tag，因为文件尚未 commit，且用户未要求执行 git 操作。Reason: 下游无需改动；新增 LLM 作为概率系统的调研定义、性质和任务设计规则，用于后续 harness、prompt 和多模型编排决策。

0. 执行摘要

本文给出一个用于后续任务设计、模型编排和 prompt 架构的工作定义：

更短的定义：

这一定义的核心含义：

1. LLM 不是确定性程序，也不是完整的人类同事；它是一个在当前信息条件下生成高概率候选的概率系统。
2. Prompt 的本质不是“命令模型听话”，而是在合适层级减少输出分布的熵，提升 I(context; answer)。
3. 长上下文不是可靠记忆；上下文窗口只是可见材料，活跃追踪能力仍受 attention、约束数量、位置偏差和状态写入边界限制。
4. “管理 LLM”不是管理动机、人格和责任，而是管理输入分布、上下文边界、工具权限、候选输出、验证信号和失败恢复。
5. 多模型系统的价值不是角色扮演，而是信息域隔离、方法论分工、交叉验证和可检查中间产物。
6. “哲学家引导科学家”的类比成立，但应改写为 methodologist 引导/约束 domain expert，并且 authority 必须随信息迁移。

1. Source Manifest 与证据等级

1.1 本轮使用的仓库材料

1.2 外部基础论文

本轮没有展开新的外部深研，只用少量基础论文作为背景锚点：

• Transformer architecture: https://arxiv.org/abs/1706.03762
• GPT-3 / in-context few-shot framing: https://arxiv.org/abs/2005.14165
• Long-context positional use / lost in the middle: https://arxiv.org/abs/2307.03172
• Self-correction limitation discussion: https://openreview.net/forum?id=IkmD3fKBPQ

1.3 Residual Ledger

2. 系统性定性分析：LLM 本质上是什么

2.1 从模型本体看：条件概率分布

狭义上，LLM 学到的是一个条件分布：

P(next token or action | prompt, context, prior trajectory, tool observations, policy constraints)

它的输出不是从一个稳定意志中“决定”出来，而是从当前条件下的高概率延续中生成出来。训练语料、模型结构、对齐过程、系统提示、用户提示、上下文材料和工具反馈共同改变这个分布。

这意味着：

1. 它首先是 completion machine：在给定上下文中补全最像“合理下一步”的东西。
2. 它可以表现为 reasoning machine：当上下文中给出问题表征、证据、步骤、约束和反馈时，reasoning pattern 会成为高概率路径。
3. 它可以表现为 agent：当外部系统允许它调用工具、观察结果并继续生成时，文本分布被嵌入执行循环。
4. 它不天然是 verifier：生成某个答案和证明该答案满足任务，是两个不同系统功能。

因此，“概率模型”不是一句贬义。它说明 LLM 的能力来自大规模模式压缩和条件化生成；它的风险来自没有外部约束时，流畅、高概率、符合 prompt 表面的 continuation 会伪装成真值、完成和理解。

2.2 从系统边界看：LLM 不是一个单体，而是一个被 harness 化的控制系统部件

在真实使用中，“LLM 系统”至少包含：

model + prompt/context + tool interface + external state + verifier + observer + human judgement

单独的模型只是 proposal engine。它生成候选：

• 候选解释
• 候选计划
• 候选代码
• 候选分类
• 候选引用
• 候选下一步工具调用
• 候选总结和完成报告

这些候选是否真实、完整、可执行、符合用户目标，必须由外部机制确定：

• 文件、数据库、scratchpad 维护状态
• 测试、parser、schema、引用检查、截图、lint、benchmark 验证事实或产物
• 独立 critic 或 reviewer 检查语义满足度和证据边界
• 观测日志和 checkpoint 支持恢复
• 人类保留目标和价值判断权

这与用户 axioms 中的核心判断一致：AI 是 multiplier，不是 replacement；从 IC 到 manager 的变化不是放弃判断，而是把判断迁移到目标、上下文、方法、验收和反馈层。

2.3 从信息论看：prompt 是降熵装置

如果把用户需求看成一个高熵搜索空间，prompt/context 的作用就是压缩不相关自由度，让正确答案区域的概率质量上升。

一个坏 prompt：

分析一下 LLM 的本质。

保留了太多自由度：哲学、技术、产品、管理、认知科学、社会影响都可能成为高概率路径。模型会选择最常见、最流畅的路径，而不是用户真正需要的路径。

一个好的 prompt 会降低熵：

目标：给出可指导任务设计和多模型编排的工作定义。
来源：LLM Harness KB、能力边界 survey、用户 axioms、book draft skill。
输出：定义、性质、人类管理差异、bad behavior 控制、prompt 设计、多模型职责。
证据：每个关键 claim 标明来自哪类 source。
禁区：不要把 roleplay 当组织设计，不要把自检当验证。
完成标准：定义可压缩成一句，且能推出具体任务设计规则。

这个 prompt 不是更“礼貌”，而是更强地塑造了输出分布。

2.4 从控制论看：LLM 是高 variety 生成器，需要外部 regulator

Ashby 的 requisite variety 适合解释 LLM：LLM 的生成 variety 很高，任务环境的 variety 也很高。如果没有足够 variety 的调节器，系统会失控。

调节器不一定是更强的模型。它可以是：

• source manifest
• 任务 contract
• 约束预算
• 工具 schema
• deterministic tests
• 独立 reviewer
• 状态文件
• checkpoint
• failure taxonomy
• human gate

也就是说，LLM 的强项是产生大量可能性；harness 的职责是选择、过滤、验证、回写和恢复。

2.5 从 Simon 的人工物视角看：LLM agent 是 inner/outer environment 的接口

Sciences of the Artificial 的重要启发是：人工物的行为由 inner environment 和 outer environment 的接口决定。LLM 的 inner environment 是模型权重、attention 机制、训练分布和对齐偏好；outer environment 是 prompt、工具、文件系统、用户目标、组织规则和反馈。

因此，问“模型聪不聪明”常常不如问：

• 它看到了什么材料？
• 它被要求优化什么？
• 它允许调用什么工具？
• 它的状态在哪里？
• 它如何知道自己错了？
• 谁判断完成？
• 错误如何进入下一轮？

LLM 的能力边界不是纯粹在模型内部，而是在接口设计中显现。

3. 定义：LLM 的核心性质

3.1 工作定义

这个定义故意同时包含两层：

1. 模型层：条件概率生成器。
2. 系统层：需要 harness 的非确定性决策系统。

只讲第一层会低估 LLM 的 agentic 能力；只讲第二层会把外部系统的可靠性误归因给模型本体。

3.2 十个核心性质

3.3 与人类的关键差异

因此，管理人类与管理 LLM 的对应关系是“动作类比”，不是“心理等同”：

• 招聘 -> 模型/工具/能力路由
• 委托 -> 任务分解、上下文隔离、输出 contract
• 培训 -> docs、examples、rubric、memory
• Coaching -> 方法论提示、反例、反馈
• 验收 -> tests、schema、critic、human review
• 绩效管理 -> observability、failure taxonomy、calibration loop

4. 不确定性管理：从过程确定性转向结果确定性

LLM 不确定性不能靠“请认真一点”消除。可管理的路径是把不确定性显式纳入系统。

4.1 任务开始前：定义目标、证据和边界

每个复杂任务先写出：

Objective: 最终要改变什么状态？
Deliverable: 可检查产物是什么？
Sources: 哪些材料可用，权威顺序是什么？
Constraints: 当前最重要的少数约束是什么？默认控制在 3-5 个复杂约束内。
Non-goals: 明确不做什么？
Evidence: 什么证据能证明完成？
Failure modes: 最可能的 3 个坏行为是什么？
Stop rule: 什么时候停止、升级或分解？

这对应用户的 “result certainty over process certainty”。过程可以非确定，但最终产物和验收必须越来越确定。

4.2 任务执行中：外置状态与分阶段选择

长任务不能依赖聊天历史自带的连续性。至少需要：

• source_manifest：读了哪些源，源的权威等级是什么。
• claim_ledger：关键 claim、来源、置信度、是否需回源。
• decision_log：为什么选择某条路径。
• residual_ledger：哪些没读、哪些只是 draft、哪些可能过期。
• verification_log：跑过什么检查，结果是什么。

这把 LLM 从“连续生成文本”改造成“围绕外部状态迭代”。

4.3 任务完成时：独立验证而不是自我宣布完成

LLM 最常见的失败之一是把“我做了检查”写成“任务完成”。因此完成验证要分层：

1. 确定性检查：文件存在、schema、parser、tests、lint、引用链接、数值一致性。
2. 语义检查：是否回答用户问题、是否有 unsupported claim、是否有 scope drift。
3. 独立性检查：critic 是否与 executor 足够独立，是否只是在复述。
4. 交付检查：最终回答是否清楚说明做了什么、没做什么、证据在哪。

自检可以作为中间步骤，但不能作为最终真相源。

5. Bad Behavior：从表象分类回到根因机制

LLM 的坏行为不是“态度差”，而是概率系统在上下文、目标、证据和验证结构不足时产生的可预期失效。

关键原则：

6. Prompt 设计：从“指令”升级为“上下文架构”

6.1 Prompt 的真实功能

Prompt 的功能不是礼貌表达需求，而是：

1. 设置目标函数。
2. 选择相关 pattern。
3. 限制搜索空间。
4. 指定证据标准。
5. 声明权威顺序。
6. 暴露失败模式。
7. 绑定输出 contract。

好的 prompt 让“正确行为”成为高概率延续；坏 prompt 让模型在巨大搜索空间里猜用户真正想要什么。

6.2 高价值 prompt 模板

Task:
  你要完成的具体目标是 ...

Context:
  当前背景是 ...
  当前日期/时间锚点是 ...
  相关 source 权威顺序是 ...

Output:
  交付物必须包含 ...
  不需要包含 ...

Constraints:
  1. 最重要约束 ...
  2. 第二约束 ...
  3. 第三约束 ...

Method:
  先做 ...
  再做 ...
  需要外置状态或工具检查时，不要只凭记忆。

Evidence:
  每个关键结论必须说明证据类型。
  确定性事实用工具/文件/测试验证。
  语义判断说明依据和残余不确定性。

Failure modes:
  特别避免 ...
  如果发现 source 不足或要求冲突，先报告。

Done:
  完成时说明产物位置、验证方式、未覆盖范围。

6.3 Large Context 下的 prompt 原则

1. 不要把所有材料塞给一个 agent 后期待其“理解全部”。长上下文会扩大可见性，但不会线性扩大活跃工作记忆。
2. 先做 source manifest。让系统知道材料类型、权威等级、是否回源。
3. 按 source family 分片，而不是按预设观点分片。这样可以减少确认偏误。
4. 每个 sub-agent 只背少数关注点。3-5 个复杂关注点是工作区基于既有 survey 和 skill 的默认工程启发式，不是外部普适常数；高耦合或高风险任务应进一步降低。
5. 使用 overlap。关键判断给 30-50% 重叠是本工作区的调研编排经验，用来让分歧本身成为信号；实际比例按验证成本和错误风险调整。
6. integrator 最后合成。过早综合会把多视角压成单一叙事。
7. 保留 residual ledger。不能把未读、只读 summary、draft-only 包装成完全覆盖。

7. 多模型职责分工：从“科学家/哲学家”到控制架构

7.1 类比成立的部分

用户提出的类比：

• 科学家：专业知识丰富，但可能受既有范式限制。
• 哲学家：有方法论和实现路径，但缺乏领域细节。
• 哲学家引导科学家：方法论模型引导知识模型，可能产生突破。

这个方向是有价值的，但必须去人格化。更准确的命名是：

• methodologist：方法论、问题表征、路径设计、停止规则。
• domain expert：领域事实、机制、约束、反例、可行性边界。

两者组合能产生增益的原因不是“哲学家更高明”，而是：

1. 信息域分离，减少单一上下文的锚定。
2. 方法论和领域知识互相约束。
3. 一个负责问题表征，一个负责事实可行性。
4. 中间产物可被 critic 和 verifier 检查。

7.2 必须补上的角色

仅有 methodologist 和 domain expert 仍然不够。可靠系统至少还需要：

7.3 Authority follows information

Brain of the Firm / cybernetics 类比给出的关键原则是：命令权应该跟随信息，而不是固定层级。

所以不应固定为：

philosopher -> scientist -> executor

更好的结构是：

当问题表征不清时：methodologist 领先
当领域约束强时：domain expert 领先
当现实反馈出现时：operator/verifier 领先
当价值取舍出现时：human owner 领先
当证据冲突时：critic 拉回 claim boundary

这才是多模型系统，而不是角色扮演。

7.4 何时会退化

“哲学家/科学家”框架会在以下条件下退化：

1. 只是 prompt 里写“你是哲学家/科学家”，没有不同 source、不同工具或不同验收。
2. methodologist 用宏观词汇压过硬领域约束。
3. domain expert 迎合 methodologist 的框架，而不是提出反例。
4. critic 用流畅度判断质量。
5. 没有外部 evidence、实验、测试或 source citation。
6. integrator 太早介入，把分歧抹平成漂亮叙事。

因此，角色设计的判定标准不是“像不像人类组织”，而是：

8. 推荐的复杂任务 Loop

针对类似本轮的思考性 Large Context 任务，可采用以下 loop：

1. Intake
   - 复述目标，不急于回答。
   - 识别 source families、风险和完成标准。

2. Source Manifest
   - 列出必须读、可选读、不能作为权威的材料。
   - 标注 source type: rule / survey / draft / overview / raw / external.

3. Parallel Extraction
   - 按 source family 分 sub-agent。
   - 每个 agent 最多 3 个关注点。
   - 关键问题设置 overlap。

4. Claim Ledger
   - 把关键 claim 写成短句。
   - 标明 source、证据强度、反例和适用边界。

5. Synthesis
   - 主 agent 亲自写定义和框架。
   - 不直接拼接 sub-agent 文本。

6. Critique
   - 独立检查是否有 unsupported claim、roleplay trap、过度抽象、证据等级混淆。

7. Deliverable
   - 报告落盘。
   - 最终回答只给路径、核心定义和残余风险。

9. 对后续任务设计的直接规则

9.1 不确定性处理规则

1. 任何 LLM 输出先视为候选，不视为真值。
2. 对确定性事实使用工具验证，不使用语义 judge。
3. 对语义质量使用独立 reviewer，但 reviewer 也必须给证据边界。
4. 对长任务外置状态，不能依赖聊天历史。
5. 对复杂任务分解时，按信息依赖和验证方式拆，不按人类职称拆。
6. 对高风险任务设置 human gate。

9.2 Bad Behavior 预防规则

1. 开始前写任务 contract，防 FAM-A/D/H。
2. 完成前跑 completion validation，防 FAM-B。
3. deterministic check 优先，防 FAM-C。
4. source manifest + claim ledger，防 evidence drift。
5. sub-agent prompt 必须完整，防 FAM-F。
6. fallback 必须显式记录，防 FAM-G/H。
7. 先查已有 preflight 和 workspace 状态，防 FAM-J/K。
8. experiment ledger 和 held-out eval，防 FAM-L。

9.3 Prompt 设计规则

1. 用目标、证据、边界、禁区、停止规则塑造分布。
2. 把最重要约束放在前部。
3. 每轮只引入少数战略不确定性。
4. 对时间敏感事实明确日期。
5. 要求模型披露 source coverage 和 residuals。
6. 要求模型把假设和结论分开。
7. 不要求模型“自信”，要求它给证据等级。

10. 最终定义的三个版本

10.1 一句话版本

10.2 系统工程版本

10.3 管理学版本

11. 对用户假设的结论

“哲学家模型引导科学家模型”是一个好起点，但需要改写成系统架构：

methodologist frames the search
domain expert grounds the search
operator touches reality
critic attacks unsupported leaps
verifier checks contract
integrator writes synthesis
human owner sets values and accepts risk

如果这样设计，它确实能完成单模型难以完成的任务：不是因为多了几个角色名，而是因为系统增加了信息多样性、降低了错误相关性、引入了外部现实反馈，并把“生成”与“验证”拆开。

最终原则：