Jev System Architect

目的

以下の判断を決定するためにこのスキルを使用します。

Jevがシステムにそもそも属するかどうか
Jevの境界線を正確にどこに引くべきか
どの判断をChoice、Score、またはNoulの質問にするべきか
各判断がどのような状態を見るべきか
どの質問をまとめて実行すべきか
通常のコードがその結果をどのように構成するか
不確実性がシステムの動作をどのように変えるか
本番利用前に統合をどのように評価すべきか

これは主にアーキテクチャと分解のスキルです。

正確なSDK構文、リクエスト/レスポンスフィールド、モデル、制限、またはバージョン固有のAPI動作については、現在のTypeSafeドキュメントを読み、可能であればTypeSafeの公式エージェントスキルを使用してください。

APIフィールドを発明しないでください。

コアメンタルモデル

Jevはアプリケーションではありません。

Jevはワークフローエンジンではありません。

Jevは自律エージェントではありません。

推奨されるアーキテクチャは次のとおりです。

アプリケーションの状態
      ↓
境界が設定されたセマンティックな質問
      ↓
     JEV
      ↓
型付きの判断 + 確率
      ↓
決定論的なアプリケーションコード
      ↓
ルーティング / ランク付け / 検証 / 確認依頼 / エスカレーション / 実行

モデルはプログラム可能な判断を提供します。

コードは以下を所有します。

制御フロー
権限
計算
決定論的ルール
永続化
トランザクション
副作用
ツール実行
認可
ポリシー適用

Jevは、通常のソフトウェアが非構造化または曖昧な情報のセマンティックな理解を必要とする場合にのみ使用してください。

トリガー条件

システムに次のような境界が存在する場合、Jevを検討します。

非構造化またはコンテキスト情報
                ↓
     境界のある判断が必要
                ↓
 ソフトウェアが続行するために型付きの値を必要とする

有力な候補は次のとおりです。

意図の分類
セマンティックルーティング
モデレーション判断
文書分類
証拠検証
引用チェック
セマンティックガードレール
リスクシグナル
メッセージ解釈
候補選択
ランキングの次元
関連性の判断
感情や緊急性
ユーザーリクエストの解釈
ツール/関数の選択
既知の候補セットからの抽出
RAGパッセージフィルタリング
ワークフローのトリアージ
品質判断
ポリシーとケースの比較
ファジーマッチング
エンティティの調整
エスカレーション判断

また、次のような症状がないかコードを検査します。

LLM → 散文 → パーサー → JSON → 検証 → 再試行

または：

大規模な正規表現ツリー
巨大なif/elseセマンティック分類器
プロンプトベースの分類器が任意のJSONを返す
限定的な判断を行うためだけに使用されるエージェントループ
些細な分類に高価な推論モデルが使用されている

これらは潜在的なJev挿入ポイントです。

Jevをデフォルトで使用しない

以下の場合は通常のコードを優先します。

算術演算
すでに構造的に表現されている正確な日付
データベースルックアップ
正確な文字列一致
権限
認可
スキーマ検証
決定論的なビジネスルール
既知の変換
既知の数値のソート
暗号化操作
問題を確実に解決する正確なパーサー

必要な出力が根本的にオープンエンドである場合、生成モデルを優先します。

執筆
要約
説明
ブレインストーミング
コード生成
長文合成
オープンエンドな調査
多段階推論

Jevは、それらのシステムの周辺で境界のある判断を行うことでサポートできますが、生成的な役割を強制されるべきではありません。

ステップ1 — 判断の境界を見つける

入力から出力までのワークフローを検査します。

ソフトウェアが事実上次のように問いかけているすべてのポイントにマークを付けます。

「情報はあるが、どの決定論的なパスを取るべきかを知る前に、その意味を理解する必要がある。」

各候補境界について、次のように記述します。

入力状態: どのような情報が存在するか？

判断: どのようなセマンティックな決定が必要か？

出力: コードが続行できるようにする、境界のある値は何か？

アクション: コードはその答えをどうするか？

ステークス: 判断が間違っていた場合、何が起こるか？

すぐにJevを実装しないでください。

まず、決定論的なコードがその問題をより確実に解決できるかどうかを判断します。

ステップ2 — Jev適合テストを適用する

以下のほとんどが当てはまる場合、判断はJevの有力な候補です。

入力に自然言語またはコンテキストデータが含まれている。
必要な出力が境界設定可能である。
ソフトウェアがプログラム的に答えを必要としている。
知識のある人間がその判断を迅速に行える。
判断を明示的に記述できる。
不確実性が有用な情報である。
結果を例やラベルに対してテストできる。
コードが判断後のアクションを所有できる。

次のようなタスクが必要な場合は懐疑的になります。

深い熟考
長い推論チェーン
多くの依存する中間結論
オープンエンドな生成
自律的な計画

まず分解します。

ステップ3 — 質問をアトミックにする

Jevの質問は、1つの一貫した判断を表すべきです。

悪い例:

この顧客を分析し、返金すべきかどうか、どの程度怒っているか、詐欺の可能性があるか、どの部門がケースを処理すべきかを判断してください。

より良い例:

topic → Choice
refund_requested → Noul
fraud_signal → Noul
frustration → Score

次に、それらの答えをコードで構成します。

目標は次のとおりです。

複雑な振る舞い = 多数の小さな判断 + 決定論的な構成

コードがそのポリシーを明示的に表現できる場合、アプリケーションポリシーを巨大なセマンティックな質問の中に隠さないでください。

ステップ4 — 正しいプリミティブを選択する

Choice

定義されたセットから正確に1つの答えを選択する必要がある場合に使用します。

形状: どれか？

例:

billing | technical | sales | account
refund | rebook | information
python | javascript | rust | other

指定されたオプションで入力をカバーできない場合に備えて、「other」「unknown」「none」の結果を追加します。

Noul

命題が真である確率が有用な場合に使用します。

形状: これは真ですか？

例:

顧客は返金をリクエストしていますか？
このパッセージはユーザーの質問に答えていますか？
このメッセージは資格情報を要求していますか？
履歴書にプロフェッショナルなPython経験が記載されていますか？

出力を「はい」の確率として解釈します。

~0.5を「中程度の強度」と解釈しないでください。

これは、「はい」と「いいえ」がほぼ同程度に妥当であることを意味します。

Score

判断が順序付けられた次元に存在する場合に使用します。

形状:定義されたスペクトルのどこに状態が該当するか？

例:

calm / concerned / very frustrated
irrelevant / partially relevant / strongly relevant / direct answer

各レベルは、具体的なセマンティックな状態を記述する必要があります。

意味が明示的に定義されていない限り、bad / okay / good / great のような未定義のラベルは避けてください。

ステップ5 — 状態を意図的に設計する

質問に必要な証拠を含む最小の状態を送信します。

構造化された状態を優先します。

{
  "ticket": {
    "message": "...",
    "sender": {}
  },
  "customer": {
    "plan": "...",
    "orders": []
  },
  "policy": {
    "refund_policy": "..."
  }
}

1つの巨大な散文の塊ではなく。

原則:

関連性 > 包括性
構造化 > 平坦化
観測された事実 > 仮定されたモデル知識
現在の情報 > 古い埋め込み知識

観測された事実と推論された判断を区別できるようにします。

質問が特定の状態フィールドに関するものである場合、それらのフィールドを明示的に指し示します。

ステップ6 — 独立した質問をファンアウトする

複数の質問が同じ既存の状態から回答できる場合、それらをまとめて尋ねることを優先します。

                    ┌── topic
                    ├── urgency
STATE ── JEV ───────┼── refund_requested
                    ├── frustration
                    └── fraud_signal

次のような不必要なシリアル呼び出しを作成しないでください。

Jev → answer → Jev → answer → Jev → answer

3つの質問すべてが元の状態から評価できた場合。

安価で後で役立つ可能性がある場合は、推測的な質問をします。

例: category, bug_severity, reproduction_quality, refund_requested, frustration

category = billing の場合、コードはバグ固有の回答を単に無視します。

ステップ7 — 実際の依存関係にのみ複数のJevステージを使用する

最初の回答が以下のために必要な場合、2番目のJevリクエストは正当化されます。

新しい証拠を取得する
新しい状態を構築する
次の候補セットを選択する
どの質問が有意義に尋ねられるかを決定する
階層をトラバースする
次の判断に必要なドキュメントを取得する

例:

ステップ1  どの製品ファミリー？
   ↓
コードがそのファミリーの製品を取得
   ↓
ステップ2  どの製品が最もよく一致するか？

ワークフローが概念的ないくつかのステップを含むという理由だけで質問をシリアル化しないでください。

ステップ8 — 構成をコードに保持する

Jevはセマンティックシグナルを生成します。

コードは、それらのシグナルが操作上何を意味するかを決定します。

例:

topic = billing
refund_requested = 0.94
frustration = high

アプリケーションコードは次のように決定する可能性があります。

if topic == billing:
    route_to_billing()

if refund_requested > REFUND_FLAG_THRESHOLD:
    add_refund_flag()

if frustration > PRIORITY_THRESHOLD:
    increase_priority()

ビジネスロジックは検査可能であるべきです。

「私たちのアプリケーション全体は何をすべきか？」をJevに尋ねないでください。その答えはより小さな判断から構築できるのに。

ステップ9 — 不確実性を第一級のシグナルとして扱う

型付き出力を真実と同等に扱わないでください。

型付き出力はインターフェースが制約されていることを意味します。

セマンティックな判断が間違ってはいないことを意味するわけではありません。

ChoiceとScoreについては、確率と信頼度を検査します。

Noulについては、「はい」の確率を直接検査します。

次のような動作を設計します。

高い確実性 → 自動パス
中程度の確実性 → 確認を求める / より多くの証拠を収集する / より強力なモデル / レビューのためにフラグを立てる
低い確実性 → 推測しない / エスカレーションする

しきい値はアプリケーションポリシーです。

これらは、偽陽性/偽陰性のコスト、元に戻せるかどうか、ユーザー/財務/セキュリティ/規制への影響を反映する必要があります。

例からコピーされたしきい値は、このシステムに適切であるという証拠にはなりません。

ステップ10 — 信頼度ゲートをリスクに合わせる

1つの普遍的な信頼度しきい値を使用しないでください。

例:

show_help_article — 低い結果
route_support_ticket — 中程度の結果
cancel_subscription — より高い結果
move_money — 非常に高い結果

セマンティックな判断は同じである可能性がありますが、必要な確実性と確認パスは異なります。

結果が重大なアクションの場合、Jevは通常、独立して副作用を承認するのではなく、制御された決定境界に情報を提供する必要があります。

ステップ11 — 自動化前に評価を設計する

Jevの境界を実運用化する前に、代表的なケースを特定します。

含めるもの: 簡単な陽性、簡単な陰性、曖昧なケース、証拠不足のケース、エッジケース、敵対的ケース、まれだがコストのかかる障害。

記録するもの: 状態、質問、期待される動作、Jevの回答、確率/信頼度、アプリケーションのアクション、可能な場合はグラウンドトゥルースの結果。

システムの動作を評価します。単にトップラベルが妥当に見えたかどうかだけではありません。

しきい値化されたシステムの場合、いくつかのしきい値で動作を測定します。

特に測定するもの: カバレッジ / 自動化率、偽陽性率、偽陰性率、人間によるレビュー率、エラーのコスト、レイテンシ、コスト。

実際のターゲットドメインデータを使用してしきい値を調整します。

ステップ12 — Jevポリシーを集中管理する

Jevの質問、基準、重み、しきい値定数を見つけてレビューしやすくします。

次のような構造を優先します。

ai/
  jev/
    questions.*
    thresholds.*
    evaluation/
    client.*

またはプロジェクトに適した同等の構造。

セマンティックポリシーを多数のルートハンドラに分散させないでください。

人間のレビュー担当者は以下を検査できる必要があります。

Jevは何を判断しているか？
どのような定義を与えたか？
どのしきい値がアクションを引き起こすか？
どのアクションが元に戻せるか？
信頼度が低い場合、何が起こるか？

ステップ13 — 生の判断を保持する

実用的な場合、有用な生の出力を、それらから導出されたアクションとは別に保持します。

例:

refund_probability = 0.91
frustration_score = 1.72
topic = billing
topic_confidence = 0.88

priority = high だけを保存するのではなく。

これにより、しきい値の再評価、重みの変更、動作の監査、モデルバージョンの比較、障害の調査、およびダウンストリーム分析が可能になります。

アプリケーションの正当な要件を超えて機密データを保持しないでください。

ステップ14 — 生成AIの周辺でJevを探す

Jevは、LLMを置き換えるのではなく、その周りで価値があることがよくあります。

例:

入力 → Jevガードレール → LLM → Jev引用/品質検証 → コードが返すかどうかを決定

または:

クエリ → 検索 → Jev関連性 / インジェクション判断 → 選択されたコンテキスト → 推論モデル

または:

ユーザーリクエスト → Jev意図/関数選択 → 決定論的な型付き関数 → 結果

これにより、オープンエンドな生成モデルに委ねられるアプリケーション制御の量を減らすことができます。

アーキテクチャレビュープロシージャ

既存のシステムをJevの機会についてレビューするよう依頼された場合。

1. ワークフローをマッピングする

特定するもの: 入力、決定論的ステップ、セマンティックな決定、モデル呼び出し、パーサー、ルーター、ツール呼び出し、副作用、人間によるレビューポイント。

2. Jev機会マップを作成する

各候補について:

場所: 現在のコード/モジュール/ワークフロー
現在の方法: 現在どのように判断が行われているか
Jev候補: はい / いいえ / おそらく
理由: なぜ境界のあるセマンティックな決定が適切であるか、または適切でないか
状態: 最低限必要な証拠
プリミティブ: Choice / Score / Noul
質問: 提案されたアトミックな判断
構成: コードがそれらをどのように使用すべきか
不確実性: 答えが不明確な場合に何が起こるか
リスク: 誤った判断の結果
評価: それを検証する方法

3. レバレッジで優先順位を付ける

Jevが脆弱なセマンティックコード、繰り返されるLLM解析、高価で些細な推論呼び出し、無制限のエージェントループ、重複した分類器、または明らかなケースの手動レビューを置き換えながら、システムの動作を境界設定可能でテスト可能に保つことができる機会を優先します。

4. 最小のvを推奨する

…[翻訳のため省略]

Jev システムアーキテクト