ULSパブリス 進地 です。
連載第一回、第二回では、それぞれ、業務知識を文章でAIに渡してみた結果、業務知識をGoの型と遷移表でAIに渡してみた結果をみてきました。
第一回: 差戻された申請は、もう一度出せますか？ AIの答えは「出せない」
第二回: 差戻したら、それまでの承認はどうなりますか？ AIの答えは4対1で割れました
コード: shinchi-p/ringi（本記事時点は ai-03 タグ）
結果、「型」では表現できない「判断」によってAIの出力結果にブレが生じることを確認できています。では、何を与えればこのブレを防ぐことができるのでしょうか？
今回（第三回）はそれを探す回になります。
frontmatter でオントロジーを作ろうとした話
入社してすぐの私は、社内で飛び交っている言葉、その文脈、関連語句、参照情報などをfrontmatter形式でまとめていけば、社内のAI基盤として使いこなせるようになるのではないかと夢想して、試しに簡単なfrontmatter付与と各語句のLinkの仕組みを作ってみたことがあります。
会社固有の知識を下記のようなメタデータに整理して、保持、メンテナンスし、AIに参照させることで
AI基盤を会社のOSとして使いこなせるようになると。name: hecate（認証・ID 連携基盤） type: asset description: 認証認可と ID 連携を担う社内基盤 aliases: [Hecate, ヘカテ, 認証認可基盤, ID連携基盤] relations: owned-by: [data-platform] owner_role: Data Platform Lead (kunpe) sources: [関連する Notion ページ]これらのメタデータの作成、メンテナンスもAIにチャットのログから整備する仕組みを作れば初動はよさそう。
AIに会社の地図を持たせたら、3年目社員のように働き始めた 〜精度とトークン効率を上げるオントロジーの実践〜｜kunpe (ymdpharm)
この仕組み自体は結局運用にはのらず、日々の忙しさの中に消えていきましたが、今でも構想自体はとても良いと思っています。
このfrontmatterのような発想で、メタデータとして「制約」を与えればAIの判断のブレを減らせるのではないでしょうか？ということで、さっそく実験してみました。
制約として書いてみる
第二回で使ったコードに下記のプロンプトを追加しました。
// 第2回で4対1に割れた判断を、遷移ではなく不変条件として書いたもの。
// いつリセットするかは書いていない。ありえない状態だけを書いている。
const constraintDoc = `
差戻し状態の申請は、承認済みの承認ステップを持ちません。
`
そして、第二回のコード（プロンプト）と今回の制約を加えたコード（プロンプト）をそれぞれ実行して、生成されるgoプログラムの違いを見てみたところ、結果は次のようになりました。
実験に使ったコードと10回分の出力は ontology/experiment3 に置いてあります。
実験結果
今回の制約を加えたコード（プロンプト）
AIの判断のブレがなくなり、全5回実行のすべてで 差戻し状態の申請は承認済みの承認ステップを持たない 実装となりました。
// リセット処理の直前の処理
// 差戻し状態の申請は承認済みの承認ステップを持たない
a.approvalRoute.resetApprovals()
追加したプロンプトには
- いつリセットするかは書いていない
- 遷移ではなくありえない状態を書いている
という特徴がありますが、これが「制約」として正しく効いています。
第二回のコード（プロンプト）
一方、前回の再実行の結果はどうだったか。結果は、2対1対2 にブレました。
| 検出回数 | リセットの位置 |
|---|---|
| 2回 | Reject の中 |
| 1回 | Submit の中（差戻しからの再提出のときだけ） |
| 2回 | Submit の中（状態を問わず無条件に） |
第2回のタイトルに「4対1」と書きましたが、安定した傾向とは言えなかったようです。
また、5回中1回は Reject に承認者の引数を足して、「現在の承認者のみ差し戻しできる」というルールを勝手に作っていました。今回の制約を加えたコードではこの余計な発明がありません。
制約を書くと、ブレが減るだけでなく、書いていない業務ルールの創作も減るという、予想していなかった副次効果がありました。
ハマったこと・迷っていること
今回加えた制約の一行を思いつけたのは、第2回でAIの生成結果にブレが生じたことを確認した後でした。事前に書けたかというと自信がありません。また、制約を書けばブレが減るとして、書くべき制約を網羅する方法は依然としてわかっていません。
また、制約が守られたことをどう検証するかという課題もあります。
今回は出力を目で読んだだけですので。
まとめ
- 「制約」を加えることでAIの判断のブレは抑制できる
- 「制約」を加えることで書いていない要件や仕様のAIによる勝手な発明を抑制できる
- 「制約」を事前に思いつく体系的な方法、網羅する方法などはまだみえていない
次回
制約でAIのブレを抑制できることはわかりました。しかし、これを毎回プロンプトに貼るのでは運用できません。書いた制約をAIが必要なときに引ける形で届ける方法として、次回はMCPに入っていこうと思います。
コードと10回分の出力は shinchi-p/ringi の ai-03 タグにあります。記事中のコードは説明のために簡略化しています。実際に動かすうえで必要な部分はリポジトリを見てください。