Function callingとは｜自由文から拾った12件のうち、2件は別の数値だった

自由文から拾った12件のうち、2件は別の数値だった

応答12通りに実際に正規表現を当てました。拾えたのは9件で、そのうち2件は文中の別の数値を拾っています。

Function callingを使わずに答えを取り出すと何が起きるのかを、実際の応答で確かめました。題材は「東京の今日の気温を調べて」への応答12通りで、正解は18です。

応答は実際にAIが返しがちな言い回しを並べたもので、正規表現とJSON解析は本当に実行して数えています。

// 自由文から数値を拾う正規表現。「18度」「18℃」を狙う
const NUM = /(\d+(?:\.\d+)?)\s*(?:度|℃|degrees)/;

function parseFree(r) {
  const m = r.text.match(NUM);
  if (!m) return { got: false, value: null, correct: false };
  const v = Number(m[1]);
  return { got: true, value: v, correct: v === r.expect };
}

応答                              拾えた値  判定
東京の気温は18度です                      18  正しい
気温: 18度                              18  正しい
The temperature in Tokyo is 18 degrees   18  正しい
今日の東京は18度から22度の見込みです         18  正しい
昨日は15度でしたが、今日は18度です           15  別の値を拾った
気温は平年より3度高い18度です                3  別の値を拾った
東京の気温は十八度です                       —  拾えない
東京: 18                                  —  拾えない
摂氏18                                    —  拾えない

取り出し方           拾えた  値が正しい  取りこぼし
自由文を正規表現で拾う     9件         7件         3件
決めた形で返させる      10件        10件         2件

拾えた9件のうち2件が誤りでした。「昨日は15度でしたが、今日は18度です」から15を拾っています。

誤読は取りこぼしより厄介

取りこぼした3件は、拾えなかったことがその場で分かります。ですから再実行するなり、人に回すなりの手が打てます。

誤読した2件は違います。15という数値が返ってきて、そのまま次の処理に流れます。正しく動いたのと見分けがつきません。

正規表現を足しても直らない

取りこぼした3件は、表現を足せば拾えます。漢数字や単位なしにも対応させればよいだけです。

ところが誤読は減りません。文中に数値が2つあるとき、どちらが答えかを決める材料が文面にないからです。表現を足すほど、むしろ誤って拾う機会が増えます。

決めた形での失敗の仕方

決めた形で返させた側も2件失敗しています。応答が途中で切れて解析できなかったものです。ただし失敗の理由は1つで、失敗したこと自体は必ず分かります。

Function callingとはどういう仕組みなのか

受け取りたい値の形を先に宣言しておき、その形に沿った答えを返させます。文章ではなく構造で受け取ります。

Function callingは、返してほしい値の形をあらかじめ宣言し、その形で返させる仕組みです。文章で返させて後から拾うのとは順序が逆になります。

定義に書くもの

定義は2つの部分でできています。受け取る値の形と、その道具が何をするかの説明です。Anthropicの説明でも、形の指定と説明文の記述、そして呼ばれる場面の制御が扱いとして挙げられています。

形の指定にはJSON Schemaが使われます。同じ文書では、その道具に期待される引数を定めたJSON Schemaのオブジェクトだと説明されています。

受け取り方が変わる

宣言しておくと、答えは文章ではなく構造として返ってきます。ですから拾う処理そのものが不要になります。前の節の正規表現のような部分が消えます。

解析に失敗するのは、応答が壊れた場合だけです。何が起きたかがはっきりしているので、再実行という単純な対処が効きます。

ツール利用との関係

同じ仕組みを別の側から呼んだ言い方です。外部の機能を呼ばせる側面を強調するとツール利用、返す値の形を決める側面を強調するとFunction callingになります。呼ぶ側の設計はツール利用の記事で扱っています。

定義はどこまで書けばよいのか

説明文は3〜4文以上が目安です。形だけ正しくても、説明が薄いと呼ばれる場面がずれます。

Function callingの定義でつまずくのは、形ではなく説明文のほうです。形はJSON Schemaで書けば済みますが、説明は書き方次第で動作が変わります。

説明文の分量

Anthropicは目安を示しています。説明文はそれぞれ最低でも3〜4文を目指し、複雑な道具ならもっと長く、という書き方です。

同じ文書では、説明文に含めるべき内容も挙げられています。その道具が何をするか、いつ使うべきか、どう振る舞うかを詳しく書いた平文だとされています。

書き方の順番

1. 何を返すか。整数か文字列か、単位は何か
2. いつ使うか。どんな依頼のときに呼ぶべきか
3. 例外の振る舞い。見つからない場合、権限がない場合
4. 実装の詳細。呼ぶ側には要らない

3番目を忘れがちです。見つからなかった場合に何が返るかを書いておかないと、0なのか空なのかで判断がぶれます。

形は狭く決める

形の指定も、緩くしないでください。文字列で受けておけば何でも入りますが、入ってしまったものを後で検査することになります。

取りうる値が決まっているなら、その一覧を形の中に書きます。範囲があるなら上下限も書きます。定義した形の外は最初から届きません。