こんにちは、Kaiです。
最近もだいぶ大規模LLM関連のニュースが落ち着いてきています。
OpenAIもGPT-5に関する煽りがトーンダウンしてきていることから、「基盤モデルを用いて質問に回答する」というタスクにおいては限界が見えてきているのではないかという印象です。
一方で、アツくなってきているのがローカルLLM、オムニモーダル、エージェントモデル、オープンエンドAIといった領域です。
特にオープンエンドAIは、基盤モデルをベースとして自ら目的を立て、自らを改善するAIというコンセプトであり、AIそのものを一段階上のレベルに引き上げようとする試みで面白いです。
のちほどご紹介するSakana AIの論文がイメージをつかむのによいかと思います。
（オープンエンドAIに関するポジションペーパー by Google）
注意事項
- 先週収集したAIおよびWeb系の記事やポストが中心になります
- 私のアンテナに引っかかった順なので、多少古い日付のものを紹介する場合があります
- 業務状況次第でお休みしたり、掲載タイミングが変わったりします
特定AIサービス
Gemini: NotebookLM
先週は比較的この話題を多く見かけました。
Googleがリリースした、Geminiと統合されたNotebookサービスです。
100万トークンという膨大なコンテクストウィンドウを持ち、Notebookの箱に複数のドキュメントを放り込むと、そのドキュメントをリファレンスとして回答してくれるというものです。
また、「ドキュメントにない情報は回答しない」という方向で調整されているらしく、ハルシネーションもかなり少ないとのこと。
こちらのユースケースが最も分かりやすいかと思いますのでご紹介します。
ちなみに診療ガイドラインをまとめていくつか放り込んでみましたが、解析処理が終わらず使えませんでした……さすがにデータ量が多すぎたようです。
llava-calm2-siglip: サイバーエージェント製7.5B日本語VLM
VLM＝視覚言語モデルということで、日本語の商用利用可能な大規模オムニモーダルモデルは初かな？
その他AI系話題
GNN-RAGで7BモデルでもGPT-4と同等の性能を引き出す
グラフニューラルネットワークを用いたRAG論文の解説。
本質的にRAGは基盤モデルの中に埋め込まれて拡散している知識に、一定の重みづけを行った上で処理させるプロセスだと考えて差し支えないと思います。
その観点では、GNNを用いた知識表現を行うことで精度が上がることに違和感はありません。ただ、事前学習に必要な手間やコストを鑑みると、トータルのBenefitはどうなのだろう……と感じます。
LLMにまつわる"評価"を整理する
いわゆるLLMベンチマークではなく、特定の目的を達成するためのサービスとして考えたときの評価のお話。
結局自然言語による出力になるわけで、ELYZA TASKSのような基準を構築した上での別LLMによる評価や、人間による目視評価に帰着してしまうところがあります。
ローカルモデルのQwen2-72B-Instructがすごい
72Bで気軽に試せるモデルではありませんが、取って出しローカル動作でGemini1.5 Flashの少し下スコアとのこと。
Sakana AI論文：Discovering Preference Optimization Algorithms with and for Large Language Models
冒頭で述べたオープンエンドAIに通じる概念です。
LLMを反復的に用いることにより、未知の高性能最適化アルゴリズムを発見することができたという内容です。
具体的には、LLMに既知のアルゴリズムを与えた上で改善案を提出させ、その実行結果（エラーが出た場合はエラーも）をフィードバックして自ら評価させ、さらに改善案を提出させるという手法を100回繰り返したところ、未知の高性能アルゴリズムが出来上がったとのこと。
これはシンプルな単一課題ですが、再帰的向上はシンギュラリティにつながる第一歩かもしれません。
レコメンドアルゴリズム入門：基礎から応用まで実装に必要な知識を解説
DeNAよりレコメンド総まとめ記事。ほぼこれだけで全部カバーできてそう。
実際に取り組む前までは割と簡単なイメージを持っていましたが、やってみると本当に奥が深い。人間の嗜好というのは厄介なものだなと感じています。
新たな次元の呪いの発見: Hubs in Space
次元の呪いは一般に計算量爆発という形で認識されていますが、新たな呪いがあるというお話。
次元数が大きくなればなるほど、特定の領域に値が集中するという、「分布のゆがみ」が生じるとのことです。
確かに体感で、高次元データを扱っていると近傍処理の結果に違和感を覚えることが多々あります。
RAG for Agentプロセスという考え方
RAGは知識ばかりではなく、プロセス情報を与えた方がよいという深津さんの提案。
これはその通りで、標準業務プロセスを定義した上で、それぞれの場合分けをワークフローのチェックポイントとしてLLMにやらせながら最終アウトプットを作るのが王道だと思います。
Doing RAG? Vector search is not enough
Microsoftより、RAGはベクトル検索と全文検索をハイブリッドすべきという記事。
検索結果をマージし、リランキングすることで単体よりも性能が向上するとのこと。
RAGで人間の脳を再現。「HippoRAG」を理解する
RAG部分にTripleを介したナレッジグラフを使う……というお話ですが、なんかこう、ディープラーニング前夜にNNの研究してた頃に一周回って戻ってきた感じがあります。
基盤モデルの外側での知識表現、投与方法については、ひょっとしたらディープラーニング前夜の頃のアルゴリズムが有効かも。
llama-cpp-agentで多機能ローカルLLM環境を作る
私はOllama+DifyでローカルLLM環境を作っています（記事執筆中……）が、これも良さそうです。
株式会社ケアネットのエンジニアブログです。CareNetサービスの技術情報を中心に記事を投稿しております。 各記事の内容は個人の意見であり、企業を代表するものではございません。
Discussion