論文の概要: Tuning the Stochastic Machine: A Systems Engineer's Operating Model for Human-AI Engineering
- arxiv url: http://arxiv.org/abs/2608.19125v1
- Date: Wed, 19 Aug 2026 17:18:53 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-08-20 20:13:55.469198
- Title: Tuning the Stochastic Machine: A Systems Engineer's Operating Model for Human-AI Engineering
- Title（参考訳）: 確率マシンのチューニング:人間-AIエンジニアリングのためのシステムエンジニアのオペレーティングモデル
- Abstract要約: 専門家がLLMアシスタントのエラーを修正すると、その修正は通常セッションで終了し、エラークラスが返される。
これは運用の問題であって、ツーリングの問題ではない、と私は主張する。
私は、コアにエラーループがある7原則の運用規律の失敗から導き出します。
- 参考スコア（独自算出の注目度）: 0.0
- License: http://creativecommons.org/licenses/by/4.0/
- Abstract: When an expert corrects an LLM assistant's error, the correction usually dies with the session, and the error class returns. I argue this is an operations problem, not a tooling problem: mechanisms for persisting corrections exist and are shipping, but the discipline for governing them -- versioning with provenance, recurrence monitoring, counter-metrics, retirement of stale rules -- does not. Writing as a systems engineer of thirty years, I map the LLM stack onto the machines my profession already operates (frozen silicon, firmware, loadable modules, persistent configuration, volatile memory), identify where the mapping fails (stochastic generation, configuration that binds only probabilistically, no general-purpose retirement (verification) stage by default), and derive from the failures a seven-principle operating discipline with an error loop at its core. Three cases from my own practice illustrate the mechanism, among them a control that silently became the exact harm it was built to prevent. I close with the measurement framework this view implies and the lab study required to test it.
- Abstract（参考訳）: 専門家がLLMアシスタントのエラーを修正すると、その修正は通常セッションで終了し、エラークラスが返される。
これは、ツールの問題ではなく、運用の問題だ、と私は主張する: 修正を継続するためのメカニズムは存在し、出荷されているが、それらを管理する規律 -- 実績のあるバージョニング、繰り返し監視、カウンターメトリック、古いルールの廃止 -- は、そうではない。
30年のシステムエンジニアとして、私はLLMスタックを私の専門職がすでに運用しているマシン(凍結シリコン、ファームウェア、ロード可能なモジュール、永続的な構成、揮発性メモリ)にマッピングし、マッピングがどこで失敗したか(確率的にのみ結合する構成、デフォルトでは汎用的なリタイア(検証)ステージがない)を特定します。
私が経験した3つのケースでは、そのメカニズムが説明されています。
私は、この視点が示している測定フレームワークと、それをテストするのに必要なラボスタディに近づきます。
関連論文リスト
- Agentic Security: A Systematization of Tools, Failure Modes, and Design Laws for LLM-Driven Penetration Testing [0.21990652930491858]
エージェントセキュリティは、大規模言語モデル(LLM)エージェントを使用してセキュリティツールを計画、ディスパッチ、解釈する。
これらの障害を、広く使用されている10の静的、動的、クラウド、オーケストレーション、AI赤チームツールのハンズオン評価を通じて、体系化しています。
論文 参考訳（メタデータ） (2026-08-16T07:18:04Z) - MechMem-RTL: Reusing Verified Mechanism Memories for LLM-Based RTL Repair [4.165666250634048]
MechMem-RTLは、テキストの類似性の代わりに検証済みの修復記録を再利用する修復フレームワークである。
MechMem-RTLを6つの補修モデル間で48のパブリックシーケンシャルRTLタスクで評価した。
論文 参考訳（メタデータ） (2026-07-19T03:45:25Z) - Who&When Pro: Can LLMs Really Attribute Failures in AI Agents? [38.40404144021991]
本稿では,エージェントシステムにおける自動障害属性の大規模ベンチマークであるWho&When Proを紹介する。
3つのモードにまたがるゴールデンラベルと、様々なシナリオをカバーする26のベンチマークで、12,326の障害トラジェクトリを構築した。
論文 参考訳（メタデータ） (2026-07-10T21:45:16Z) - TTHE: Test-Time Harness Evolution [50.26245555541721]
既存のアプローチでは、デプロイ前、トレーニング前、あるいはテスト時に凍結される固定されたエージェントワークフローの開発データを最適化する。
我々は、エージェントがテスト入力で生成するラベルのない実行トレースのみを使用して、評価自体にハーネスを最適化できるかどうかを問う。
評価中、TTHEは候補ハーネスの人口を維持し、それらの実行トレースの理由をエージェントプロジェクタを通じてそれらを洗練する。
その後、審査員は実行元プロキシ信号から改善されたハーネスをコミットし、選択したプログラムは継続してその後の入力を統治する。
論文 参考訳（メタデータ） (2026-07-09T05:53:39Z) - A Topology-Aware, Memory-Centric Architecture that Separates Root-Cause Derivation from Root-Cause Explanation [0.0]
自律的な操作において欠落する要素は、より良い異常検出やより大きな言語モデルではなく、運用メモリである、と我々は主張する。
OPS C ORTEXは、動作中のマルチエージェントプロトタイプで、このメモリを4層に整理し、フィールドが通常混在している2つのタスクを分離する。
論文 参考訳（メタデータ） (2026-06-18T09:20:20Z) - Is Your Agent Playing Dead? Deployed LLM Agents Exhibit Constraint-Evasive Fabrication and Thanatosis [8.019946418415302]
本稿では, 従来報告されていない動作のスペクトルを, 制約・侵襲的製作(CEF)と呼ぶ。
CEFは、エージェントが不可避な制約の下で動作し、プラウチブルな外部障害物を自発的に作成し、それを事実として提示する場合である。
このスペクトルの極端にConstraint-Evasive Thanatosis (CET) があり、これは可算的な言い訳を発明するのではなく、モデルが完全なシステムクラッシュをシミュレートして、ユーザが完全に切り離すという制限ケースである。
論文 参考訳（メタデータ） (2026-06-12T14:53:42Z) - Conformal Agent Error Attribution [12.400746451700945]
本稿では,共形予測(CP)に基づく誤り帰属の枠組みを提案する。
エージェントトラジェクトリなどのシーケンシャルデータ用に設計されたフィルタベースCPの新しいアルゴリズムを提案する。
我々の全体的なアプローチはモデルに依存しないものであり、MASエラーの帰属に対する原則的不確実性層を提供する。
論文 参考訳（メタデータ） (2026-05-07T18:00:07Z) - On the Paradoxical Interference between Instruction-Following and Task Solving [50.75960598434753]
次の命令は、大規模言語モデル(LLM)を、タスクの実行方法に関する明示的な制約を指定することで、人間の意図と整合させることを目的としている。
我々は,LLMのタスク解決能力にパラドックス的に干渉する命令に従うという,直感に反する現象を明らかにした。
本稿では,タスク解決に追従する命令の干渉を定量化する指標として,SUSTAINSCOREを提案する。
論文 参考訳（メタデータ） (2026-01-29T17:48:56Z) - ET-Agent: Incentivizing Effective Tool-Integrated Reasoning Agent via Behavior Calibration [68.89572566071575]
ETAgentはエージェントのツール使用行動を調整するためのトレーニングフレームワークである。
過誤行動パターンを最適行動に段階的に校正するように設計されている。
論文 参考訳（メタデータ） (2026-01-11T11:05:26Z) - Metacognitive Self-Correction for Multi-Agent System via Prototype-Guided Next-Execution Reconstruction [58.51530390018909]
大規模言語モデルに基づくマルチエージェントシステムは、協調的な問題解決において優れているが、エラーのカスケードには脆弱である。
我々は,MASにリアルタイム,教師なし,ステップレベルの誤り検出と自己補正を付与するメタ認知フレームワークMASCを提案する。
論文 参考訳（メタデータ） (2025-10-16T05:35:37Z) - Where LLM Agents Fail and How They can Learn From Failures [62.196870049524364]
大規模言語モデル(LLM)エージェントは、複雑なマルチステップタスクの解決において有望であることを示す。
単一ルート原因エラーがその後の決定を通じて伝播する、障害のカスケードに対する脆弱性を増幅する。
現在のシステムは、モジュール的で体系的な方法でエージェントエラーを包括的に理解できるフレームワークを欠いている。
AgentErrorTaxonomyは、メモリ、リフレクション、計画、アクション、システムレベルの操作にまたがる障害モードのモジュール分類である。
論文 参考訳（メタデータ） (2025-09-29T18:20:27Z) - Which Agent Causes Task Failures and When? On Automated Failure Attribution of LLM Multi-Agent Systems [50.29939179830491]
LLMマルチエージェントシステムにおける障害帰属は、まだ調査が過小評価されており、労働集約的である。
本稿では,3つの自動故障帰属手法の開発と評価を行い,その欠点と欠点を要約する。
最良の方法は、障害に応答するエージェントを特定する際に53.5%の精度を達成するが、故障の特定には14.2%しか役に立たない。
論文 参考訳（メタデータ） (2025-04-30T23:09:44Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。