GPTsのKnowledge機能のブラックボックスを調査した研究記事
学んだこと
ナレッジファイルを適切にフォーマットすることで、関連情報が切り捨てられないようにすることができる
フォーマットで、##などのマークダウンで、上手くいかないことがある
例えば、プロンプトがプレーンテキストで書かれており、ナレッジファイルがマークダウンで書式設定されている場合、特にマークダウンの見出し（#）が使用されている場合、知識取得プロセスはその見出しを情報の区切りと解釈し、関連情報切り捨ててしまい、適切にコンテキストウィンドウにコピーされない可能性がある。
自明な検索タスクでは、実行時間はファイルサイズと情報の場所に関係なく一定。
しかし、似たような情報が多いほど、間違いが多くなる。
このような自明でない検索タスクでは、特にナレッジファイルが大きい場合、関連性の高い情報をナレッジファイルの先頭に配置する価値がある。
概要
これまでにOpenAIが発表していることは以下のとおり
研究課題
知識ファイルのサイズと内容が、取得時間にどのように影響するか？
知識取得プロセスの最適な使用方法は何か？
実験設定
🗂️ ナレッジファイル
太陽系を観測し、毎日新しい小惑星(🌠)を発見する天文学者(🧑🔬)の物語を考えた。 🧑🔬は発見の日記をつけており、アシスタントはこの日記に基づいて質問に答える。
日付
以下のランダムな属性を持つ🌠の観測
サイズ (25種類のうち1つ)
色 (25種類のうち1つ)
組成 (40種類のうち1つ)
形状 (40種類のうち1つ)
これらの日常的な日記のエントリーの中に、天文学者の人生における3つの特別な日を入れた
ある時、🧑🔬は病気になった。
ある時、🧑🔬は素晴らしい仕事をしたご褒美に休暇をもらった。
ある時、水害のためオフィスが閉鎖された。
著者は100万件の日記のエントリーを目指した。
512MBをわずかに下回るナレッジファイルを作成した後、最初の発見をした。
❗ファイルのアップロード時には、ファイルサイズの他に2番目の制限がある。2,000,000トークン制限だ。
最初に作成したものは、約136,000,000トークンだったため、すべての定型文を取り除き、発見を5万件に制限した。各日記エントリーは次のようになった。
1970-01-01 - Dear Diary, today we discovered a giant, magnesium-based asteroid. It had a tetrahedral shape and the surface had an indigo shimmer.
👥 候補
日記の規模が大きくなるにつれて、アクセスできるアシスタントを4つ作成している。
https://scrapbox.io/files/660fab03c6764c002381924a.png
実験
4つの実験を設定している。
🥱 雪の結晶探し
質問：
著者が病気だった日/休暇を取った日/オフィスが閉まっていた日はいつですか？
情報の位置の要因を組み込むために、3つの雪の結晶は日記全体に均等に分散された。1つは最初、1つは中央、1つは最後の近く。
各アシスタントに各雪の結晶について10回ずつ質問した。
質問：
天文学者が[特定のプロパティ]を持つ小惑星を発見したのはいつですか？
情報の位置を再び考慮するために、各アシスタントに、ナレッジファイルの最初の10％内のランダムなエントリー10個、ナレッジファイルの最後の10％内のランダムなエントリー10個、および中央の10％からのランダムなエントリー10個について質問した。
😵💫 特定の基準による数え上げ
質問：
プロパティfoo=barを持つ小惑星は何個観測されましたか？
各アシスタントに10回質問し、そのたびに異なる色について尋ねました。
🤯 抽象概念の数え上げ
質問：
プロパティfooで観測された値は何種類ありますか？
この質問に自信を持って答えるには、アシスタントはコンテキストウィンドウに完全なナレッジファイルを持っている必要がある。 各アシスタントに10回、観測されたすべての異なる色を挙げるよう求めた。
結果
❄️ 雪の結晶は捕まえやすい
アシスタントは、すべてが100％の成功率を達成した。
このタスクでは、ファイルサイズも情報の場所も実行時間に影響しなかった。
https://scrapbox.io/files/660fad6c5f1c4100257e4b8d.png
雪の結晶探し - 各アシスタントと情報の場所ごとの平均実行時間（秒）。
https://scrapbox.io/files/660fadba29603f0025379ce7.png
雪の結晶探し - 情報の場所ごとの各アシスタントの実行時間
実行時間には外れ値がいくつかあるが、データにトレンドは見られない。
実行時間は、すべてのアシスタントと情報の場所で一貫している。
取得ツールが呼び出されると、アシスタントはナレッジファイルから0個以上の引用を含む注釈を取得できる
応答を調べると、アシスタントは平均してナレッジファイルから31.5トークンの引用を受け取っていた。(日記のエントリーの約3/4に相当する)。
したがって、このタスクの取得プロセスは効率的で、不要なトークンを生成しないようだが、引用はコンテキストウィンドウに追加されるすべてではないことが判明した。
2アシスタントは、似たようなものの積み重ねから正確に1つの日記のエントリーを取得する必要があった。大量の日記エントリー（つまり、大きなファイルサイズ）が大きくなり、日記の内容がより似てくると、成功率は低下した。
https://scrapbox.io/files/660fb02ef2d91700268121ce.png
情報の場所にかかわらず、ほぼ一貫していたが、最後は正解率が低下した。
https://scrapbox.io/files/660fb1720e0f7a0024fc1f84.png
この取得タスクでは、ファイルサイズと情報の場所が実行時間に影響した。
https://scrapbox.io/files/660fb1c32d3b3c0027bfc32f.png
干し草の山探し - 各アシスタントの平均実行時間、中央値、標準偏差（秒）。
大量の日記エントリー（つまり、大きなファイルサイズ）は、情報が中央または最後にある場合にのみ、長い実行時間と相関している。
つまり、大きなファイルの中央から最後にかけて取得された情報は、取得タスクが自明でない場合、実行時間の増加と相関している。
https://scrapbox.io/files/660fb2334a11780026eae920.png
情報の場所ごとの日記のエントリー数と実行時間の相関
#### ➡️ 偶然の発見：フォーマットが重要
実験の最初の反復では、各日記のエントリーは、日付から始まり、markdownのh2見出しとして書式設定され、その後に改行が続いた。
# 1970-01-01\nDear diary, …
特定の出来事の日付を尋ねると、次のような無数の回答が得られた。
理想的な答え
A: このジャーナルエントリーが作成された日です［注釈へのリンク］。
実際の答え
A: 残念ながら、このエントリーの特定の日付は、提供された引用では見えません。
取得された引用は正しい日記のエントリーだったが、日付の見出しが削除されていた。そこで、フォーマットをmarkdownのボールドに変更した
**1970-01-01** - Dear Diary, …
すると、日付の削除は二度と起きなかった。
見出しは人間の読者にとって直感的に理解できるが、現在の知識取得アルゴリズムにとっては分割記号のよう。
ただ、このAPI全体はまだベータ版であり、変更される可能性がある。
したがって、「見出しに#の代わりにボールドを使用してください！」ではなく、重要なのは、ナレッジファイルから正確に何が返されるかを確認し、予期しない/望ましくない結果が得られた場合はフォーマットを検討することが必要 #💡 ナレッジファイルのフォーマットは、コンテキストウィンドウにコピーされるテキスト部分に影響する。
特定の基準による数え上げ。赤い小惑星は何個ありますか？
結果はひどく、ほぼ不正解
取得タスクが自明でない場合、ファイルサイズの増加は実行時間の増加と相関した。
https://scrapbox.io/files/660fb8061d19930025756e0f.png
特定の基準による数え上げ - 各アシスタントの実行時間のボックスプロット（秒）
アシスタントは正しく答えることができなかったが、取得プロセスは何らかの方法でより多くの情報が必要だと「感知」した。
「DiaryGPT:100」は平均して226.30トークンの引用を受け取り、「DiaryGPT:50k」は平均で1031.70トークンも取得した。
https://scrapbox.io/files/660fb8835317b40023cb1c7a.png
取得されたトークン数と正解の間には0.587の中程度の正の相関があり、取得された引用数と正解の間には0.560の相関があった。
より複雑な検索タスクでは、より大きなナレッジファイルからより多くのトークンが得られるが、ファイルサイズに応じて上限がある。
https://scrapbox.io/files/660fb8f13b41e7002c10158a.png
特定の基準による数え上げ - 正解数と取得トークン数および取得引用数の散布図。
結論
👍 良い点
取得プロセスは、巨大なナレッジファイルの中でも明確な情報を見つけるのに優れている。自明なタスクでは、実行時間はファイルサイズと情報の場所に関係なく一定。
このプロセスは、似たような情報の山の中から情報を見つけるのにも優れているが、似たような情報が多いほど、間違いが多くなる。
このような自明でない検索タスクでは、特にナレッジファイルが大きい場合、関連性の高い情報をナレッジファイルの先頭に配置する価値がある。
ナレッジファイルを適切にフォーマットすることで、関連情報が切り捨てられないようにすることができる。
🤷♂️ 悪い点
知識取得プロセスはブラックボックス。
多くのプロセスが一貫性を欠いている。取得されるテキスト部分の選択から、適用される抽象化のレベル、ツール呼び出しの自己呼び出しに至るまで。
ナレッジファイル最適化のためにできること
フォーマットの評価
実験により、ナレッジファイルのフォーマットが重要であり、直感に反する可能性があることが示されました。したがって、重要な情報が切り捨てられないように、すべてのナレッジファイルのフォーマットを再評価する。
アノテーション
実験により、取得プロセスである程度の抽象的な推論が可能であることが示されたが、それは非常に限定的。抽象化プロセスの一部は、ナレッジファイルの作成中に行う必要がある。たとえば、特定の情報にタグを付けて、新しい機能fooが開発タスクbar＆bazに関連することをアシスタントに知らせることができる。
情報の順序
これまで、ナレッジファイルはバージョン別に、古いものから新しいものへと構成されていた。実験により、情報の場所が自明でない検索タスクの要因であることが明らかになったので、関連性別にナレッジファイルを構成することを検討する必要がある。
現在の基準の再評価
ファイルサイズ
ファイルサイズが実行時間に影響を与えるが、実験により、これはそれほど強くない。
上記手順に従ってナレッジファイルを最適化することが大事。
定型文の削除などの数KBサイズ減のために、躍起にならない。