强大的 LLM 并非问题——将它们“原始”使用是面向构建者的系统工程视角
Source: Dev.to
请提供您希望翻译的具体文本内容，我将按照要求保留源链接并进行简体中文翻译。
大型语言模型不再仅仅是用于写文本或生成代码的工具
这正是系统性问题的起点
本文 不 讨论哪个模型更好、更快或更便宜。
它提出：
当 AI 开始参与决策，而不仅仅是产生输出时，正确的系统形态应该是什么？
许多 AI 系统今天被“直接使用”
这里的“直接使用”并不是指不安全、不道德或不合规。我指的是：
我们将高能力、非确定性的推理系统直接嵌入需要 稳定、可重复、可审计的决策 的环境中——而中间缺乏真正的系统级控制层。
提示工程、RAG、规则和代理框架可以提升能力。
对于低风险任务，这种区别几乎不重要。
LLM 更像引擎而非完整系统
从系统的角度来看，LLM 看起来不像完整的产品，而更像 极其强大的引擎。它们提供：
- 强大的泛化能力
- 灵活的推理路径
- 令人印象深刻的表达能力
但它们并不固有地管理：
- 稳定性
- 权限
- 责任
- 长期状态一致性
在传统计算术语中：
LLM ≈ CPU
Prompt≈ instruction stream这自然引出了一个真正的问题：操作系统在哪里？
真正的风险不是幻觉
幻觉吸引了大部分注意力，但它们并非核心问题。更深层的风险是 结构性的。
不可重复性
相同的输入，在几乎相同的条件下，可能产生不同的结论。
控制幻觉
大型语言模型可以令人信服地解释几乎任何结果。
调试困难
当决策至关重要时，我们需要回答：
- 是什么触发了此决策？
- 走了哪条路径？
- 是否会再次发生？
如果我们无法回答这些问题，系统就不具备生产级别。
悖论：大语言模型并非太弱——它们太自由
问题不在于智能。
强大的组件缺乏系统级约束不可避免地导致：
- 行为漂移
- 累积风险
- 责任不明确
这不是一个 AI 问题。
为什么“AI 操作系统”层出不穷
We’ve seen this pattern before. CPUs alone were never enough:
| 缺失的特性 | 后果 |
|---|---|
| 没有调度 | 混乱 |
| 没有隔离 | 不安全 |
| 没有状态管理 | 不稳定 |
Operating systems didn’t weaken CPUs.
For AI, the equivalent challenge is 决策权.
决策模型不是机器学习模型
当我们在这里谈论决策模型时，并不是指另一个已训练的模型。
我们指的是一个 系统层，它：
- 不进行预测
- 不进行生成
- 不进行创造性的优化
它只回答 唯一一个问题：
在当前系统状态下，这个决策是否被允许？
需求很简单，但在实践中很少见：
相同的条件 → 相同的决策。
伴随模型需要明确的边界
长期运行的系统（AI 手机、机器人、车辆）需要连续性——偏好、习惯、上下文。
这促使了 伴随模型 的概念，但需要一条严格的规则：
- 伴随模型可以提供 状态 —— 绝不提供 权威。
一旦长期偏好获得决策权，控制就会削弱。
结语：这是系统问题，而非模型竞速
AI 的下一个阶段并不是让模型更聪明。
而是要构建系统：
- 可控的
- 可重复的
- 可审计的
- 随时间可信赖的
没有决策核心的智能无法提升可靠性——只会放大风险。
作者说明
AI 决策系统 · 核心问答 (v1.0)
A: 传统行业软件在以下情况下表现出色：
- 规则明确
- 边界清晰
- 条件可枚举
基于 LLM 的 AI 在以下情况下变得强大：
- 信息不完整
- 需求表达模糊
- 现实变量不断变化
这是一种 能力优势，而非工程成熟度优势。
Q2: 你认为“约束 LLM”可以提升安全性和可靠性。这会削弱它们的能力吗？
A:
- 未受约束的 LLM：看似强大，行为不一致，无法可靠审计。
- 系统治理的 LLM：保留智能，仅在允许的条件下运行，决策可追溯、可冻结、可复审。
在工程领域，缺乏控制的能力没有生产价值。
Q2（扩展）：你把 LLM 比作强大的汽车发动机。这是否意味着大多数人在“裸用 LLM”？这有什么危险？
A:
没有变速箱、刹车或稳定控制的高性能发动机，马力越大越危险。
LLM 的表现类似：
- 推理更强
- 表达更好
- 出错时影响范围更大
危险 不在于 LLM 会犯错，而在于这些错误无法被限制或审计。
Q3: 那么就像 PC 需要 Windows 才能发挥 CPU 的价值，AI 也需要操作系统？这就是你们在构建 EDCA OS 的原因吗？
A:
CPU 本身不负责：
- 任务调度
- 权限隔离
- 状态持久化
- 故障恢复
这些是操作系统的职责。
当 AI 参与决策时，也需要类似的结构：
- 谁可以决定
- 在何种条件下
- 决策是否被允许
- 决策是否可复现
EDCA OS 的重点是把决策转化为系统行为，而不是让 AI “更聪明”。
Q4: 为什么选择 GPT 客户端作为运行时环境？这是你们自己的标准吗？
A:
我们的优先考虑是：
- 会话稳定性
- 内置行为边界
- 执行特性的一致性
目前，只有少数 LLM 运行时能够严肃讨论：
- 决策稳定性
- 可重复性
- “相同输入 → 相同结果” 的验证
这不是模型基准测试，而是系统前提条件。
Q5: 传统量化系统和基于 AI 的量化系统之间的真实区别是什么？AI 量化在哪儿会失效？
A:
- 传统量化系统：策略固定，路径明确，可审计且可回测。
- AI 量化系统 常出现：
- 决策漂移
- 相同条件下行为不一致
- 审计能力薄弱
问题不在于智能本身，而在于缺少决策‑稳定性结构。
Q5（扩展）：这是否意味着你们目标是兼容 scikit‑learn，还是放弃它？
A:
- scikit‑learn 负责训练和预测。
- EDCA 风格的决策模型 负责 是否允许对预测结果进行操作。
两者可以共存：使用 scikit‑learn 进行预测层，然后用 EDCA 决策内核包装，以强制可重复性、可审计性和权限检查。
Q6: 为什么要构建 CMRE？你们想验证什么？
医疗场景的组合因素：
- 高风险
- 高责任
- 强烈的越界诱惑
如果一个系统能够：
- 区分信息与判断
- 抵制未授权的决策
- 在压力下保持稳定
那么在风险较低的领域也会更安全。
Q7: 你们在基于 LLM 的研究助理方面有什么突破？
? 为什么在测试时断开在线检索？
在线检索常常导致：
- 检索被误认为推理
- 已有结论伪装成新发现
断开检索会迫使模型：
- 暴露其推理结构
- 在已知约束内运行
- 揭示空白，而不是把它们隐藏在引用后面
AI 在研究中的角色是 不取代科学家。
Q6（扩展）：如果数据稀缺不再是瓶颈，你仍然依赖科学家做什么？AI 难道没有认知偏见吗？
科学家独特的贡献不是数据量，而是：
- 哪些变量重要
- 哪些假设值得挑战
- 哪些问题值得提出
AI 扩展推理空间。人类定义研究方向。