※筆者の主観と独断に基づくpromptからGPT-4が自動生成した記事です。不正確な内容が多々含まれる可能性があるので、ご了承ください。

本文

GPTの短期記憶容量には実質的な限界があり、一朝一夕には解決できないことが、以前の記事（リンク）で説明されています。この問題を克服するために、現在取られているアプローチは、知識のデータベース化とその参照です。本記事では、このアプローチとそれに関連する課題について検討します。

【知識のデータベース化とその参照のアプローチ】

新たなユーザーデータをローカルコンピュータやクラウド、あるいはWebに保存し、必要に応じてそれらを参照するアプローチを取ります。具体的な手順は以下の通りです。

1. ユーザーデータをベクトルデータ（embedding vector）に変換します。

2. 指示（prompt）をGPTに渡します。

3. GPTがpromptをembedding vectorに変換します。

4. AIではない普通のコンピュータアルゴリズムを使って、promptのvectorとデータベースのvector群を比較します。

5. 類似度が高いデータベース中のvectorを抽出し、その元のテキストデータをpromptに追加して指示を出します。

6. GPTが答えを返します。

AutoGPTという自立駆動型のGPTも、pineconeというベクトル検索ライブラリを参照しながら動作しているとのことです。

【技術的課題】

この方法では、入力したデータベース間の情報を相互参照することが難しいです。例えば、「丸いものは何？」と聞いても、参照する文献数が1の場合、「ドーナッツ」と「りんご」のどちらかしか答えが返って来ません※。参照する文献数を増やすと、APIコストが増加し、promptに乗せられる文字数にも制約があります。
(筆者注:　文献1:　ドーナッツは丸い、　文献2:　りんごは丸い　とします。　両方の文献を学習していれば、「ドーナッツとりんご」となるはずです)

【今後の展望】

各文献の情報の要約を自動生成し、それを参照するようなアルゴリズムが開発されるかもしれません。情報系の研究者たちは、現在もそのような手法に熱心に取り組んでいる印象です。ハードウェア制約が原因の問題であるため、今後数年間はこのアプローチが主流になると予想されます。しかし、学習コストが十分に下がったタイミングで、このような小手先のテクニックは不要になる可能性があります。

要約すると、GPTに膨大なユーザーデータを処理させる方法として、知識のデータベース化とその参照が現在の主要なアプローチであり、それに関連する課題が存在します。今後の技術開発やハードウェアの進歩によって、より効率的なデータ処理が可能になることが期待されます。それまでの間、研究者たちはデータベース間の情報の相互参照や要約生成などの手法を開発し、GPTの短期記憶容量の問題に対処していくでしょう。

参考:　元のprompt

以下の筆者のメモを技術系のテイストのblog記事に纏めてください。ですます調で。ロジックの抜け・飛躍、そして未定義の専門用語が多くあるので、懇切丁寧に補足してください。メモの内容は網羅してください

topic: GPTに膨大なユーザーデータを処理させる方法
背景:　こちらの記事で、GPTの短期記憶容量(ワーキングメモリ)には実質的な限界があり、一朝一夕には解決出来ないことを説明
https://note.com/kan_hatakeyama/n/n4ed6918e466a

現在取られているアプローチ:　知識のデータベース化とその参照
新たなユーザーデータをローカルコンピュータ(やクラウド、あるいはWeb)に保存し、必要に応じてそれらを参照するアプローチを取ります。

1. 背景となるユーザーデータについて、それらをベクトルデータ(embedding vector)へ変換 (例:　record 1: ドーナッツは丸くて穴が空いている, record 2: リンゴは赤い, record 3: ボールは丸い)

2. 指示(prompt, 例:　ドーナッツの形は?)をGPTに渡す

3. promptをGPTがembedding vecに変換

4. AIではない普通のコンピュータアルゴリズムを使い、promptのvectorと0.で構築したDBのvector群を比較

5. promptと類似度が高いDB中のvectorをk件(通常1～3程度)抽出

6. 類似度が高いvectorに対応する元のtext dataをpromptに入れた上で、指示を出す (例:　ドーナッツは丸くて穴が空いている。ドーナッツの形は?)

7. GPTが答えを返す

ちゃんと調べていませんが、自立駆動型のGPTであるAutoGPTも、pineconeというベクトル検索ライブラリを参照しつつ動いている模様です

技術的課題:　このnaiveなやり方では、入力したDB間の情報を相互参照することが苦手です。
例えば、参照する文献数k=1の状態で、「丸いものは何?」と聞いても、「ドーナッツ」 or 「りんご」のどちらかしか答えが返って来ません。　k=2にすると、「ドーナッツとりんご」となります。　ただし、kを増やすと、その分token数が増えてAPIコストがk倍されます。また、promptに乗せられる文字数にも制約があります

今後どうするか:　各文献の情報のessenceを纏めたsummaryを自動生成して、それを参照するようなアルゴリズムが出てくるかもしれません。というか、情報系の方はその辺りを現在進行形で熱心に研究している印象です。　ハードウェア制約の問題なので、ここ数年はこのアプローチが主流になると思います。ただ、学習コストが十分に下がったタイミングで、このような小手先テクニックは不要になると思われます