4 ポイント 投稿者 GN⁺ 2024-05-15 | 2件のコメント | WhatsAppで共有
  • needle-in-a-needlestack は、GPT-4o、Llama、Jamba、Sonnet、Gemini に関する実験記事とコードを1か所に集めた公開ページ
  • プロジェクトの コードリポジトリ も提供されており、Needle in a Needlestack の実験資料を直接確認できる
  • モデル別の記事では、長いコンテキスト処理 と拡張性の違いを中心に、Llama 3.1 8B、Jamba 1.5 などの結果を比較している
  • GPT-4o-mini は GPT-4 Turbo に近い性能を持ちながら価格が 98.5% 低い事例として、Sonnet 3.5 は NIAN で Sonnet 3.0 より優れた事例として紹介されている
  • ページ自体が オープンソース で、GitHub の "Improve this page" リンクからドキュメント修正に参加できる

Needle in a Needlestack 関連リンク

モデル別比較記事

オープンソース文書

  • このサイトは オープンソース
  • Improve this page リンクから GitHub 上でページを修正できる

2件のコメント

 
wedding 2024-05-18

技術の進歩は本当にものすごいです..(泣)

 
GN⁺ 2024-05-15
Hacker News のコメント
  • このテストは、2021年に公開されたリメリック・データセットに基づくもの: https://zenodo.org/records/5722527
    GPT-4o がこのデータで学習されていた可能性は非常に高いと思う。あえて入れない理由がないから。NIAN チームがなぜ複数のモデルでリメリックを生成し、その結果がデータセットに含まれていないか確認しないのか気になる。そうすれば、モデルがそのリメリックで学習されていた可能性を排除できる

    • リメリックを与えない場合、LLM が質問に答えられないかをテストした。4oを除けばこのベンチマークでの性能は非常に悪いので、学習データに含まれていたかどうかによってテストが無効になるとは考えていない
    • ただ完全なランダムテキストを作って、その中から探させればいいのでは?
    • NIAN はとても面白いアイデアだが、単にN個の異なる言語に翻訳して質問すればよいのでは? DeepL、Google Translate、LLM 自身の翻訳などを混ぜて使うこともできる
  • 小さな法律文書2つを比較してみたところ、一方にはあり、もう一方にはない条項があると完全に幻覚した。契約書の異なる3か所でそうだった
    ctrl-f で確認すると、両方に同じように入っていた。サンプル1つにすぎないが、90%という数字はもっともらしく見えない。全体はおよそ8万トークン程度だった

    • 似た感触がある。6千項目のリストから重複を探させたら、回答全体を何度もほぼ幻覚した。たまに一部の重複を見つけることはあるが、その間に幻覚した項目を混ぜ込む
      固定数のアテンションヘッドでは難しい作業だと思っていたので正解は期待していなかったが、Claude Opus や GPT-4 よりずっと悪く見えた
    • それは干し草の山から針を探す問題ではない
      LLM は2つの文書をより小さな区間に分け、区間ごとに反復処理すると、この作業をよりうまくこなす。推論能力や記憶がないため、比較的小さな断片を超える2つのテキスト塊を構造的に分析できない。その代わり、意味的に独立していて関連のある小さな断片を段階的に見ていけば、かなりうまく機能する
      これらを魔法の機械だと見なすのは間違いだ。限界と能力があり、他のツールと同じように何ができて何ができないのかを理解すべきで、なぜそうなのかも知っておくほうがよい。開発者の99.9%にとっては今なおかなり新しい進歩なのに、なぜ期待値が事実上無限に高いのか分からない。以前の技術には「よし、正しく使う方法を見つけよう」というような基準のほうが合理的だった。もしかすると人間のように話すため、実際にはない能力まであるように見えるからかもしれないし、人間にあまりにも似て聞こえるので、人間ではないことを責めているのかもしれない。誇張もあれば、同時に過小評価もある。XML でさえ、かつて世界の飢餓を終わらせるかのように見なされた、似たような過熱サイクルを経験した
    • それは needle-in-a-needlestack とは別のテストだが、モデルがどれほど脆弱かはよく示している。ある領域では有能だが、別の領域では壊滅的に悪い
      needle-in-a-needlestack は、異なるものの中から探す needle-in-a-haystack と違い、似たデータの中から特定のデータを探す問題だ。例えば数千個のリメリックの中から1つを探すようなもの
    • 地域の法規で同じ実験をして、GPT が罰金と手数料を幻覚するのを見つけた。実際に存在する問題だ
    • 興味深いが、少なくとも公式には GPT-4o のコンテキストウィンドウは128kだ
  • needle-in-a-haystack テストは、モデルの実際の長文コンテキスト処理能力を非常に限定的にしか示さない。初期のモデルがこのタスクをひどく苦手としていて、テストしやすかったため主に使われただけだ
    実際、最近のモデルの多くはこの1つのタスクではかなりうまくやるが、現実には32Kトークンを超えて複雑なことをする能力は大きく低下する。RULER のほうがはるかに良いテストだ: https://github.com/hsiehjackson/RULER

    基本的な needle-in-a-haystack(NIAH)テストでほぼ完璧な性能を達成しているにもかかわらず、すべてのモデル(Gemini-1.5-pro を除く)は RULER タスクでシーケンス長が伸びるにつれて大きな性能低下を示す
    すべてのモデルが32kトークン以上のコンテキストサイズを主張しているが(Llama3を除く)、半数だけが定性基準である Llama2-7b の4K性能(85.6%)を上回り、32Kシーケンス長を効果的に処理できる。基準を超えた性能には下線が付けられている

    • そうかもしれないが、第一にこの記事は NIHS ではなく独自の変形テストを扱っているので、より関連性があるかもしれない。第二に記事の主張の核心は GPT-4o のほうが優れているという点だが、挙げられたテストは GPT-4o をベンチマークしていない
    • RULER がベンチマークしたモデルは needle-in-a-needlestack ではより悪い結果になっている。4o が RULER でどうなるのか気になる
  • Gemini Pro 1.5 でもこれを見てみたい。先週、『Moby Dick』全文を入れてみたし、一度はビョン・チョル・ハンの全著作を入れてみたが、どちらの場合も、私の質問に言及または回答している文の一部を毎回そのまま見つけ出し、ハルシネーションもなかった

    • 研究室の何人かが、小説作品に対する LLM の長文コンテキスト評価を研究している。『Moby Dick』は学習データに入っている可能性が非常に高い。そのため研究室のメンバーは、こうした問題を避けるため最近出版された本を探してきた
      先週 ICLR で発表された BooookScore(https://openreview.net/forum?id=7Ttk3RzDeu) と、最近のプレプリント FABLES(https://arxiv.org/abs/2404.01261)を参照するとよい
    • その内容はおそらく学習セットに入っているのでは? モデルの最後のリリースより後に出版された本の集合で同じ作業をすると面白そうだ
    • 記事でリンクされていた2500個の例を Gemini 1.5 Flash に入れてみたところ、正解である “The tree has diseased leaves and its bark is peeling.” を当てた: https://aistudio.google.com/
    • そのモデルへのアクセス権があり、印象的なコンテキスト抽出を見たこともある。大きなコードベースを丸ごと入れたら、要約も非常にうまかった
      誰かが巨大なログファイルを分析しているのも見たが、モデルが何かを見落とす時点を特定するには、こういう needle-in-a-needlestack のようなものが本当に必要だ。少なくともモデル開発者が候補モデルを分析するのに使える
    • もう2〜5年もすれば、ePub を入れて数分以内に正確なグラフィックノベル版を得られるようになりそうだ。トールキン風の木の絵4000枚を見る準備はできている
  • 誰か、検索だけでなく、さまざまな情報の間の理解の深さ、つながり、抽象化をテストする「haystack での総合」テストを作るべきだ
    人が本を読むと、その本についての「全体的な直感」が生まれる。これを定量化する方法が必要だ。needle-in-haystack テストは単純すぎて、十分に遠くまで届いていない気がする

    • 精巧なアガサ・クリスティ風の犯人探しができそうだ。どんでん返しやアリバイを複数入れ、作品の終盤を切り落とすと最有力容疑者が変わるようにする方式だ
    • 針同士がグラフを構成し、プロンプトがグラフベースのタスクを尋ねる方式も可能だ
    • 詳細で内部的に一貫した世界観と、よく設計された動機を持つ登場人物が含まれる未公開の小説や脚本を購入し、中盤以降の任意の地点から、まだ出会っていない2人の人物を絡める新しい筋書きを続けて書かせる、というアイデアがある
      コンテキストを理解しているなら、物語の新しい部分を書けるはずで、読者が直感的に感じ取る人物の動機を使って彼らの物語を展開できるはずだ。ただし有用にするには全体を徹底して非公開に保つ必要があるため、個人的なベンチマークに近い形でしか使えない。あるいは、方法論を公開して分野の改善に使うのではなく、結論の信頼性そのもので評価される権威ある賞のようなものにすることもできる
    • 似たようなことを考えていた。質問の一部が LLM にリメリックを見つけるのに十分な情報となり、2つ目の部分ではそのリメリックや別のテキストに対するより深い理解が必要な内容を尋ねる方式だ
    • 理解は存在しないので、そんなことはできない
      GPT-4o も、学習セットにない2つの異なるアイデアの交差点をまだ扱えない。さらには、異なる2つのアイデアの交差点に対するランダムな変形すら作れない。まして、モデルがこうしたことをするはずだと期待すべきではない。モデルと実際の有用性、そして理解なしに成し遂げる驚くべきことに対して公平ではない。モデルが理解していると信じるのは、自分を欺くことだ
  • これで GPT を使い、生の動的データをその場で見栄えのよい HTML レイアウトに変換できる。トラフィックの少ない変更ログや監査ログのようなページで開発時間を大きく削減し、データ構造が変わっても HTML を最新の状態に保てる
    以前の試みでは、GPT-4-Turbo が時々コンテキストと指示をほぼ完全に無視したため、一貫して動作しなかった

  • この記事は、GPT-4o が入力ウィンドウ全体にわたって注意を払う能力で、GPT-4 Turbo と Claude-3 Sonnetよりどれほど向上したかを示している
    しばらく前から needle-in-a-haystack のアップグレードが必要だったが、この「Needle In A Needlestack」はよい次の段階だ。NIAN は数千個のリメリックを含むプロンプトを作り、特定位置のリメリックについて質問する

    • 同意する。しばらく Claude にお金を払っていた。大きなコンテキストをサポートすると強くうたい、大きなコンテキストを使うとトークンをものすごく消費するが、ほんの数ページ前のソースコードでさえ、コンテキスト内にあるとほとんど役に立たなかった
      他のすべての面は悪くなく、雰囲気も気に入っていたので余計に腹立たしかった。昨夜 4o を使ってみたところ、20問前に貼り付けた C++ クラスをまだ完璧に認識していた。賢いかどうかはどうでもよく、有用かどうかが重要で、これは有用性に本当に大きく貢献する
  • 公開インターネット上でまともな LLM 評価ができる人は誰もいないのではないか、という確信がますます強まっている

    • それでも、2022〜2023年に皆がやっていた「アメリカの第29代大統領は誰か」「Van Gogh 風に描け」のような LLM 評価をようやく通り過ぎたというだけでも幸いだ
  • このテストに意味を持たせるには、テストセットのデータが学習データに含まれていなかったことを知る必要がある

    • リメリックを先に与えずに質問すると、絶対に正解できない。LLM が間違えるときは、たいてい学習データに戻って、リメリックに合わない一般的な答えを出す
    • 必ずしもそうする必要はない。資料をアップロードする前後のモデル性能を比較すればよい
    • テスト用のリメリックは自動生成されたものだと思っていた
  • いい話だ。GPT-4.0 で最大の問題は、会話が長くなるほど品質が落ちることで、特にコーディングプロジェクトでは重要だった
    これで改善されたのか気になる。今日テストしてみるつもりだ

    • 今のところ私の経験もそうだ。現在の会話は、以前の GPT-4 の会話より信じられないほど長くなっている。以前はコンテキストを頻繁にコピーして新しいチャットでやり直す必要があった
    • 同じ経験をした。16k プロンプトでは Turbo はほぼ完璧だったが、32k ではいまいちで、100k 以上では使い物にならなかった。長いプロンプトで良い結果を得るには、情報を繰り返し入れる必要がある