【イベントレポート】RAGの基礎から実践運用まで：AWS BedrockとLangfuseで実現する構築・監視・評価 #CDLE福岡

いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！

今回は2025.03.24に開催したRAGの基礎から実践運用まで：AWS BedrockとLangfuseで実現する構築・監視・評価へ参加しましたので、アウトプットとしてイベントレポートを執筆しました。

初見の方でもサクッと読めるように平易な表現で執筆しておりますのでお気軽に読んでいただければ幸いです。

誤字脱字・わかりづらい表現に関しては極力なくすように心がけていますが、リアルタイムで執筆しているため誤字脱字があるかもしれません。

イベントページ

目次

• イベント概要
• RAGの基礎から実践運用までAWS Bedrock
• Langfuseで実現する構築・監視・評価
• Q&Aセッション
• まとめ

イベント概要

本講演では、Retrieval-Augmented Generation (RAG)の基礎から応用まで、実践的なアプローチで解説します。
AWS Bedrockを活用した実装手法から、Langfuseによる効果的な監視体制の構築、そしてRAGASとLangfuseを組み合わせた評価手法まで、RAGシステムの構築・運用・最適化に必要な知識を包括的に提供します。

RAGの基礎から実践運用までAWS Bedrock

• 自己紹介
  • 2024年のCBs
  • 忍者だったりスパルタンだったりする方
  • 現在は生成AIをメインに業務を従事されている
• RAGとは
  • ざっくり言えばデータベースに入っている情報から回答するAI
  • 流れとして、データ登録とランタイムがある
  • データ登録関連
    • チャンク分割：大量の文章を小さな意味のあるカタマリにしていく
    • Embedding：それっぽいカテゴリごとに分類わけする
  • ランタイム
    • アプリケーションを通じて質問結果に対する回答を生成する
    • （個人的考察）システムプロンプトがポイントなのかしら
• Amazon Bedrock
  • ざっくり言えば、AWSが提供しているAI開発サービス
  • Bedrockを利用すればRAGを3分で構築できる
  • S3に同期させたいデータを放り込めばいい感じに処理してくれる
  • Lamdbaを用いれば簡単にコード移行もできる
• チューニングあれこれ
  • チューニングしたくなるタイミング
    • ドキュメント量が多くなった時
    • 特定ファイルへの回答精度が悪くなった時
    • 抽象的な質問に対応したいといった要望
  • チューニングするポイントは前処理とチャンク分析
  • チャンク周りの調整
    • チャンクが大きい場合：検索にヒットしなくなる
    • チャンクが小さい場合：生成されるテキストがぶつ切りになる
  • チャンク分割のポイント
    • チャンク分割の内容を重複させる
      • ざっくり言えばぶつ切り防止対策（連続性を持たせる）
    • 階層構造で分割する
      • （個人的考察）プレゼン資料の整理でもいえる内容ですな
      • 階層構造させることで子チャンク↔親チャンクでやり取りするようが増加する
  • 前処理関連
    • PDFからテキスト・マークダウンに変換する
      • 余計なタグ情報を削除することができる
    • 自分でデータを作成する（少量の場合）
      • 元データ自体を加工しておくことで回答精度が上がる
      • （個人的考察）どのくらい加工するかの勘所が難しいのよね
    • LLMで複雑な構造のデータを加工・成形させる
      • （個人的考察）確かBedrockの機能であった気がするな
      • 複雑な様式だったらLLMに任せた方がいい
  • Bedrockであればデータソースに対して様々なチューニングを設定できる
• まとめ
  • RAGのチューニングは意外と泥臭い作業がある

Langfuseで実現する構築・監視・評価

• 自己紹介
  • Fusic所属の機械学習エンジニアの方
  • 忍者になったりスパルタンになったりする方
  • 最近ではビール検定を取得されている
• 今回テーマ
  • RAG構築後の運用周りの話
• LLMアプリのつらみ
  • 開発時のデバックが大変
    • 特にエージェントのように複数回入出力を繰り返すアプリはLLM依存
      • ざっくりいえば、挙動がよくわからなくなる
  • ユーザがどのように使用しているかよくわからない
• LLMOps周りのお話し
  • ざっくり言えば、テキスト系のアプリケーションのDevOpsをまとめたもの
  • LLMOpsでできること
    • データの管理：プロンプト情報・バージョン管理など
    • アプリケーションの監視：メトリクス記録が行える・LLM実行履歴も
    • テキスト評価：指標に応じた生成AIの回答精度を見ることができる
  • ツールあれこれ
    • LangSmith：LangChainと連携が容易に行える
    • LangTrace：OpenTeremetryを活用したトレース。VectorDBとの連携も
    • Langfuse：SaaSやOSSと組み合わせて利用できるOSS
      • 自分でカスタマイズすることができる
• Langfuseを使ってみた
  • ナレッジベースの場合：Langfuseだといい感じにトレースしてくれる
  • LLMが回答するまでの流れに関してもいい感じで情報を取ってくる
  • （個人的考察）裏側の仕様を知りたくなりますね～
• RAGASに関して
  • 評価指標に関してライブラリで管理されている
  • （個人的考察）開発しやすくなる印象ですね
  • （個人的考察）やはり言語はPythonなのね
  • データセット名に空白が入ると取ってこれないといった課題も
  • 人手の評価を行う機能も実装している
    • （個人的考察）Amazon　A2I的な機能も実装しているのね
  • キューに入れてまとめて評価することもできる
  • LLM-as-a-judgeも機能として実装している
    • （個人的考察）やはりLLMによる評価も流行っているんですな

Q&Aセッション

• 法規制などの更新が入る情報でも正確に回答できるのか？
  • 資料に対して適切なメタデータを使用すれば回答できる
  • インプットデータから日付を取得する機能を用いればできるかも
  • バージョン比較となると厳しい
    • 変更前・変更後双方のデータを取得する必要があるため
• LLM-as-a-judgeのAIモデルは変えることができるのか
  • AIモデルを変えることはできる
• 比較するためのAIエージェントを組み込んだマルチエージェントは実装できるのか
  • 実装することは可能
• TeXベースの数式も取り扱えるのか
  • 認識自体はできると思うがLLM性能による
  • 定理間の矛盾検証ができるかどうかはわからない
• プロンプト入力時に名詞・形容詞・副詞などの日本語解析知識が使えるのでは
  • 技術として活用できる
• Bedrock Agentが自動判断してメタデータをフィルタリングできる機能はあるのか
  • フィルタリングできる機能はある
• なぜRAGに入れる前にLLMを通す必要があるのか
  • 直接RAGにデータを投げ込んでしまうと数値のバグが発生してしまう
  • 数値を正しく認識させるためにLLMを通しているイメージ
  • （個人的考察）確かにテキスト化させるとベクトル処理はうまくできますよね～
• Langfuse上の評価について日本語より英語の方が精度が高くなるのか
  • 日本語のテンプレートでも十分な精度を出せる
  • 巷では英語のテンプレートのほうが良い精度が出るとも
• 企業内でのRAG利用事例について
  • 製造業系企業：ベテラン職人のナレッジを暗黙知から形式知にしていく
  • AWS事例だと機密データを学習⇒社内チャットBotの場合
  • RAGを取り入れることでドキュメントに残す文化が醸成される

まとめ

個人的にRAG周りは少し触っていますががっつり触っているわけではないので、今回の勉強会でRAGを活用してこんなこともできるのかといった発見を得ることができました。

私自身も個人開発を行っていきたいと思っていますので、RAG関連のインプット↔アウトプットを行っていきたいと思います。

最後まで記事を読んでいただきありがとうございました！！