GraphRAGでナレッジ検索を改善できないかなあ

by tsuruta

2024/12/25

Nulab / TechBlog

この記事はヌーラボブログリレー2024 for Tech Advent Calendar 2024 の 25日目です。

はじめに

以前LLMでBacklogのWikiや課題情報から業務をアシストするようなナレッジ検索ができないかを検討し、RAGを使って試作しました。今もそれなりに動いてはいるのですが、まだまだ課題は残っています。

複数のドキュメントから情報を収集することが難しい。
狙った情報が正しく取得できないことがある。
精度の問題で、ハルシネーションを起こすことがある。

これらの問題は、ナレッジ検索を実運用する上で大きな障害でした。

先月、AWS Startup Loft TokyoのイベントでGraphRAGの説明を聞きました。これらの課題解決に役立つ可能性があるのではないかと思い、理解を深めるために軽く試してみることにしました。イベント内の説明では、AWS Neptuneを使って構築されていましたが、まだGraphRAGについての理解が浅いため、GraphRAGのドキュメントを見ながらローカルで試してみることにしました。

全体の流れ

今回は今月たくさん書かれてきたヌーラボブログの情報を取得し、GraphRAGを構築して記事の情報を取得してみます。

ざっくり３ステップのことが書いてあります。

記事データの収集
ナレッジグラフの構築
クエリの実行

実際に手を動かしてみる

まずはコマンドを実行してgraphragプロジェクトを初期化し、吐き出されたsettings.yamlのAPIKeyやモデルの設定を変更します。

graphrag init --root ragtest

今回はllmのmodelにgpt-4o, embeddingsにtext-embedding-3-smallを指定しました。

記事データの収集

次にブログの記事をクローリングしていきます。

from itertools import chain

def get_article_urls(url) -> list[str]:
    response = requests.get(url)
    soup = BeautifulSoup(response.text, 'html.parser')
    return [article.find('a', href=True)['href'] for article in soup.findAll('article')]

target_pages = [f"https://nulab.com/ja/blog/page/{i}/" for i in range(1, 11)]   
article_urls = list(chain.from_iterable([ get_article_urls(url) for url in target_pages]))

記事の本文を取得したらragtestのディレクトリにぶち込んでおきます。

def crawl(url) -> str|None:
    response = requests.get(url)
    time.sleep(0.1)
    soup = BeautifulSoup(response.text, 'html.parser')
    article = soup.find('div', class_='blog-article__body')
    if article is None:
        return None
    return article.get_text(strip=True)

articles =  filter(None, [crawl(url) for url in article_urls])

for i, article in enumerate(articles):
    with open(f"./ragtest/input/article_{i}.txt", "w") as f:
        f.write(article)

ナレッジグラフの構築

次にインデックスのコマンドを実行し、ナレッジグラフを作ります。

graphrag index --root ./ragtest

これにより、記事をチャンクに分割し、ベクトルデータに変換し、さらにグラフ構造を生成します。Leidenアルゴリズムを使用してクラスタリングし、情報の要約を作成します。

クエリの実行

作成されたナレッジグラフを使い、クエリを実行してみます。

graphrag query --root ./ragtest --method global \
--query "ヌーラボブログリレー2024ではどんなAWSの記事が書かれていますか？"

SUCCESS: Global Search Response:
### ヌーラボブログリレー2024におけるAWS関連の記事

ヌーラボブログリレー2024では、AWSに関連する技術的な記事がいくつか投稿されています。これらの記事は、AWSのさまざまなサービスを活用した技術的な最適化や実装に焦点を当てています。

#### Auroraストレージの最適化

林氏は、Backlogのソフトウェアエンジニアとして、Auroraストレージの最適化に関する記事を執筆しました。この投稿は、Tech Advent Calendar 2024の一部として公開され、林氏の技術的な専門知識が評価され、サービス開発部門からTry First賞を受賞しました [Data: Reports (23)]。

#### サーバーレスファイル共有

VVVATANABE氏は、Amazon S3とDynamoDBを使用したサーバーレスファイル共有に関するブログ記事を執筆しました。この投稿は、技術的な専門知識を示し、コミュニティの知識ベースに貢献しています [Data: Reports (5)]。

これらの記事は、AWSのサービスを活用した実践的な技術の共有を目的としており、ヌーラボの技術者たちの専門性と革新性を示しています。

林さんと渡辺さんのブログについて教えてくれました。渡辺さんのブログは2024夏のブログリレーのものですね。
https://nulab.com/ja/blog/nulab/optimize-aurora-storage-with-aurora3-mysql/
https://nulab.com/ja/blog/nulab/serverless-file-sharing-with-s3-and-dynamodb/

林さんの記事の紹介にはTry First賞を受賞したと出てきているのですが、これはこちらのブログで別の林さんが受賞した記事の内容が混ざっていて惜しい感じでした。
https://nulab.com/ja/blog/nulab/nulab-general-meeting-2024/

このあたりはクラスタのサイズを調整することで精度を上げることができるかもしれません。

次にローカル検索も試してみます。

graphrag query --root ./ragtest --method local\
--query "ヌーラボブログリレー2024ではどんなAWSの記事が書かれていますか？"

SUCCESS: Local Search Response:
ヌーラボブログリレー2024では、AWSに関連するいくつかの記事が公開されています。これらの記事は、技術的な知見や実践的な経験を共有することを目的としています。

### Aurora MySQLの移行と最適化

Backlogのソフトウェアエンジニアである林氏による記事では、Amazon Aurora MySQL 2から3への移行に伴うストレージの最適化について詳しく説明されています。この記事では、Auroraストレージの特性や、移行に際しての課題とその解決策について触れられています。特に、バイナリログの特性を利用した最適化や、テーブルの最適化にかかる時間の削減についての具体的な手法が紹介されています [Data: Sources (68)]。

### Amazon Chime SDKの活用

サービス開発部の伊藤氏による記事では、Amazon Chime SDKを利用してチャットアプリに音声通話機能を組み込む技術検証の結果がまとめられています。この記事では、Chime SDKの信頼性や拡張性についての評価が行われており、音声通話機能の実装におけるアーキテクチャやデータフローについても詳しく解説されています。特に、WebRTCを用いた音声通話機能の実装における注意点や、ノイズキャンセリング機能の実装についての知見が共有されています [Data: Sources (54)]。

これらの記事は、AWSのサービスを活用した具体的な事例を通じて、技術者にとって有益な情報を提供しています。ヌーラボのブログリレーは、技術的な挑戦や成功事例を共有する場として、参加者にとって貴重な学びの機会を提供しています。

ロードした記事が少ないことやクラスタサイズもあってか、ローカル検索でも問題なく期待する情報を出してくれました。グローバル検索だとよりブログリレーの直接的な情報以外も含め、広い範囲の情報を参照して回答を作ってくれています。

まとめ

GraphRAGを使うことでBacklogやCacooに蓄積されているナレッジをもっと活用できる可能性があります。ただ、やはりGraphRAGだけでは限界があるようにも感じ、用途に合わせて全文検索などを組み合わせる必要があるように感じました。

GraphRAG自体はローカルで試すだけならすぐにできました。しかし、AWS Startup Loft TokyoのイベントではAmazon NeptuneでGraphRAGが構築されており、実際に稼働させるとなるとデータの追加によるグラフ再構築コストも気になってきます。

もし実用となると、GraphRAGのコストと顧客に提供できる価値を天秤にかけることになるだろうと感じました。技術の検証はどこかのタイミングで引き続き行っていきます。しかしながら、より大きな顧客価値を提供できるよう視野を広げてアイデアを出す必要がありそうです。今回さらっと体験しかできていませんが、試してみたことでその新しいアイデアにつながると良いなと思います。