注文の結果が分からないときは、照合を先に。
タイムアウトしても、相手側では注文が受理されている場合があります。未確定の処理を記録し、再送より結果の確認を優先する設計です。資金や記録も口座ごとに分けます。
ENGINEERING AT YOLX
開発の考え方
判断の理由と、実際の結果を確かめる。
毎日使うAIには、根拠を残す仕組み、実行する範囲を守る制御、途中で止まった処理を確認する手順が必要です。YOLXでは、これらをモデルの外側に設計しています。
DESIGN IN PRACTICE
製品ごとに、守る条件を決める。
入力にない事実を、下書きに足さない。
返信で使う宛名、金額、日時などが不明な場合は、要確認として残します。受信メールとこちらの返信方針を分けて入力し、送信前に人が確かめます。
制作が終わったら、人の確認を待つ。
AIは制作とレビューを進めますが、公開・送信の承認は人のUI操作だけが入口です。AIやシミュレーター、画面の演出は承認を発行できません。
THE COMMON FOUNDATION
AI業務実装を支える6層
用途が違っても、設計時に確認する項目は共通します。使うモデルだけでなく、仕事の担当、ルール、記録、権限までを組み合わせます。
01役割
何を任せるか
担当する仕事、入力、完成させる成果物を定義します。制作とレビューなど、異なる責任は分けて扱います。
02ルール
どこで止めるか
処理の順序、上限、停止条件、再試行を決めます。異常が起きたときに、人が確認する対象を明確にします。
03記憶
何を根拠にするか
参照した資料、取得した時点、適用範囲を残します。確認できなかった情報は、事実とは別の状態として扱います。
04手順
同じ仕事をどう繰り返すか
調査、下書き、検査、整形を再利用できる手順に分けます。案件ごとに違う条件は、共通の処理から切り離します。
05権限
どの操作を許すか
読み取り、生成、保存、公開を別の権限として管理します。外部の情報を読めるAIに、そのまま実行の権限を渡さない設計です。
06検証
完了をどう確かめるか
必須情報や形式を機械的に検査し、レビューと人の承認を組み合わせます。外部操作は相手側の結果も確認します。
TESTING & REVIEW
うまく動いた場合だけで、評価しない。
入力の不足、処理の重複、通信の中断、再起動。こうした場面を確認条件に含めます。
VEGAの開発では、既存の振る舞いを守る移行、口座ごとの分離、AI同士のレビュー、改善案の採用条件を検討してきました。成功した結果が、どの版、どの入力、どの条件によるものかを追えるようにしています。
研究結果や模擬運用の合格は、実口座での利用許可とは別に扱います。外部操作の権限、上限、停止指示は、実行時にも確認する設計です。
AI同士のレビューについて上記は自社製品の設計方針と実装例です。各製品の提供範囲や現在の稼働状況は、製品ページでご確認ください。VEGAの紹介は、投資助言・金融商品の勧誘を目的とするものではありません。※投資助言・運用を行うものではありません
CONTACT YOLX
使いたい場面から、必要な設計を考えます。
入力する資料、完成させたい成果物、確認が必要な操作を伺い、実装する範囲をご提案します。