#
43
2024/6/12
今日のトレンド

HippoRAGやLoader APIなど など

皆さん、おはようございます!今日も「zenncast」にお越しいただき、ありがとうございます。MCのマイクです。今日は2024年6月13日、木曜日ですね。さて、Zennで今日トレンドの記事を紹介していきますよ。

前回は「RustでAPIサーバーを書くのが思ったより良い」、「TypeScriptの型と値とバリデーション」、そして「Rust製JavaScriptエンジン『Boa JS』を試してみた」といった記事をご紹介しました。RustやTypeScript、JavaScriptエンジンに関する内容でしたね。覚えていますか?

さて、今日は5つの記事をご紹介します。それでは早速、最初の記事からいってみましょう。

。。。。

最初の記事は「RAGで人間の脳を再現。「HippoRAG」を理解する」です。HippoRAGは、RAG(Retrieval-Augmented Generation)の新しい手法で、複雑な質問に対する回答性能を向上させるために開発されました。オハイオ州立大学の研究者によって提案されたこの手法は、複数の知識を組み合わせて回答する必要がある質問に特に強い点が特徴です。

従来のRAGは、ベクトルデータベースとコサイン類似度を用いて情報を検索しますが、HippoRAGはナレッジグラフを活用します。ナレッジグラフは、人間の脳の長期記憶の仕組みを模倣しており、継続的に更新されることで高い性能を発揮します。

具体的な仕組みとしては、アップロードされたドキュメントから重要語句を抽出し、それをナレッジグラフに追加します。ユーザーの質問からも重要語句を抽出し、ナレッジグラフ内の関連ノードを検索。最後に、関連する文書チャンクをランキングし、最終回答を生成します。

このプロセスにより、HippoRAGは複数の知識を統合して回答を生成する能力が強化され、実験結果でも高い性能を示しています。人間の脳の長期記憶を模倣することで、RAGの精度を大幅に向上させる新しいアプローチを提供しているんですね。

。。。。

次の記事は「なぜルーティングにData Fetchの責務(Loader API)があるのかを考える」です。Reactのルーティングライブラリにはデータ取得機能が組み込まれており、その代表例がReact RouterのLoader APIです。このAPIは、ページ遷移前にデータを取得する役割を持ち、無駄なRequest Waterfallを防ぐために重要です。

まず、Loader APIを使用することで、依存関係のあるクエリが連続して発生するRequest Waterfallを防ぐことができます。例えば、ユーザ情報とプロジェクト情報を順次取得する場合、通常は2回のネットワークリクエストが必要ですが、Loader APIを使用することで1回のリクエストで済ませられます。

さらに、ページ遷移前に必要なデータを事前に取得し、キャッシュに保存することで、ユーザがページに遷移した際のデータ取得待ち時間を減少させます。これにより、UXが大幅に向上します。特に、リンクをホバーした時点でデータ取得を開始することで、ページ遷移時にデータが既に準備されている状態を作り出します。

要するに、ルーティングがデータ取得の責務を持つことで、パフォーマンスとUXの両方を向上させることができるという点が強調されています。

。。。。

次の記事は「小さな疑問を大事にしたら次に繋がった話」です。この記事は、日常のソフトウェア開発において生じる小さな疑問を放置せずに調査することが、後に思わぬ形で役立つ経験を共有するものです。

筆者はRookというソフトウェアをメンテナンスしており、その過程でCephのためにlsblkコマンドを用いてブロックデバイスをリストアップすることに疑問を持ちました。lsblkのTYPEフィールドがどの情報を基にしているのかを調べると、sysfsやLinuxのdevice mapperのUUIDなどから得られていることが分かりました。

数か月後、筆者はKernel/VM北陸のイベントでブロックデバイスのI/Oエラーをエミュレーションする発表を行いました。そこで、Cephがdevice mapper機能をサポートしていないという問題に直面しましたが、以前調べたlsblkの知識を活かし、デバイスのUUIDを変更することで問題を解決し、デモを成功させました。

この記事は、小さな疑問を大事にすることで得られる満足感と、後に役立つ可能性があることを示しています。

。。。。

続いての記事は「golangci-lintのModule Plugin Systemが良さそうなので使ってみた」です。この記事では、golangci-lintのv1.57.0でリリースされたModule Plugin Systemについて解説しています。

golangci-lintにはlinterを追加する方法が2通りあります。1つはpublic linterとして公式に実装する方法、もう1つはprivate linterとしてプラグイン形式で実装する方法です。後者のプラグイン形式は、従来のGo Plugin Systemと新しいModule Plugin Systemの2つの方式があります。

新しいModule Plugin Systemは、プラグインをgolangci-lintの依存関係として扱い、ブランクインポートすることで依存関係のバージョン差異を気にする必要がなくなります。さらに、プラグインはgolangci-lintのバイナリに含まれるため、別途配置する必要もありません。

この記事では、Module Plugin Systemの導入手順や、Go Plugin Systemとの違い、そしてその利点について詳しく解説しています。

。。。。

最後の記事は「LLMによるLLMの評価(LLM as a judge)の精度改善のためのプロンプトエンジニアリング」です。LLM(大規模言語モデル)を評価するための手法「LLM as a Judge」について、PharmaX社の実験を基にプロンプトエンジニアリングの工夫を紹介します。

評価精度を向上させるための工夫として、複数観点を盛り込みすぎず、評価基準を明確に言語化し、Few-shotプロンプティングで具体例を提供することが挙げられます。また、評価理由やスコアの計算過程を出力させることで、評価の透明性を高めることも重要です。

これらの工夫を用いることで、PharmaXではLLMの評価精度を大幅に向上させることができました。LLMアプリケーションを運用するエンジニアにとって有益なヒントとなるでしょう。

。。。。

では、今日ご紹介した記事をおさらいしますね。「RAGで人間の脳を再現。「HippoRAG」を理解する」、「なぜルーティングにData Fetchの責務(Loader API)があるのかを考える」、「小さな疑問を大事にしたら次に繋がった話」、「golangci-lintのModule Plugin Systemが良さそうなので使ってみた」、そして「LLMによるLLMの評価(LLM as a judge)の精度改善のためのプロンプトエンジニアリング」でした。

詳しい内容はショーノートに書いてありますので、ぜひチェックしてくださいね。番組の感想や質問もお待ちしています。それでは、次回もお楽しみに!マイクでした。

Related episodes

内容の近いエピソードを推薦しています