鍵はベクトル化前処理
——ネットワーク検証者の仕様情報探索の高度化に向けてRAGを導入するものの、はじめは回答精度が上がらなかったそうですね。
渡邉
はい。ですが、最初はドキュメントをそのままチューニングなしで外部知識DBに格納したので、これは想定内のことでした。回答精度の向上に向けて、私たちはまず、質問に対して不正確な回答が出たケース一つひとつの参照元を調査し、原因を探りました。すると、ベクトル化が上手く行われていないケースが多いことがわかりました。ここから私たちは、ベクトル化前処理の最適化に取り組みました。
——ベクトル化前処理の最適化とは、具体的に何を行うのですか。
中西
テキストを、意味的特徴を示す数値の並びに変換することをベクトル化といい、RAGはこの数値に基づいて意味的に近いテキストを検索し、回答に活用します。このベクトル化の前処理としてドキュメントの構造をわかりやすく整理しておくことで、数値化が正しく行われ、RAGの検索性能も向上します。具体的には、例えば「マークダウン記法」の最適化がそのひとつです。
渡邉
マークダウン記法とは、見出しを表す「＃」や強調を表す「＊＊」などの記号を使って、文章の構造を明確化する言語形式です。例えば、マニュアルに書かれた文章などは、ツールで問題なくマークダウン記法に整形できます。ただマニュアルなどには複雑な「表」が数多く含まれており、ツールはこうした表の意味を正確に認識できず、マークダウンが高精度に行われないことが多々あります。
例えば、複数の項目が結合されて中央に数値が1つ入っているような表では、人間ならば結合された全ての項目が同じ数値だと理解できるのですが、LLMは、空白を空欄と認識するケースがあります。私たちは、LLMが認識に失敗した表を検出しては、別の手法でマークダウン記法を整形し直していきました。
中西
また、「チャンキング」の最適化も重要でした。チャンキングとは、長文のドキュメントをトークン数単位——すなわち「チャンク」に分割する工程を指します。RAGは質問に関連するチャンクのみをLLMに渡すことで、回答速度などのパフォーマンスを担保しますが、調査をすると、不適当なチャンキングも回答精度を下げている要因のひとつになっていて、ここでも複雑な「表」が問題のひとつでした。
チャンク処理ツールは文字数やマークダウン構造にしたがってドキュメントを分割しますが、表を正しく認識できず、途中で切ってしまうこともあり、そうなるとそのチャンクのベクトル化は正確には行われません。私たちはドキュメントごと、時にはチャプターごとにチャンクサイズを変えるなど、表がひとつのチャンク内に納まるよう、調整をきめ細かく繰り返しました。
渡邉
こうした取り組みの結果、はじめは一般的で、ありきたりな答えしか返せなかったこのツールは、現在では、内容も濃く、情報量もしっかりある回答を生成できており、検索精度も最初は平均で47％の評価だったものが、現時点では平均で83％にまで向上しています。
ベクトル化前処理では、生成AIやRAGに関するノウハウが大事なのはもちろんですが、マニュアルや仕様書の内容をしっかり理解できるネットワークの知識も不可欠でした。
RAG改善後、実際のネットワーク運用者からツールの利便性に高い評価を得た。
生成AI×RAGの回答を評価するエージェント
——めざましい向上ですね。しかし、回答を一つひとつ評価し、不具合があったものについて改善を進めたということでした。これはかなりの手間ではないですか。
渡邉
それについては、RAG評価用のAIエージェントを開発し、効率化を図っています。RAGで使うドキュメントをもとに、質問と理想の回答のセットを生成AIに大量に作らせ、実際にその質問を生成AIに投げて得られた回答が、理想の回答にどれだけ類似しているか、自動評価するエージェントです。
このエージェントにより、これまで5件の評価に15～20分かかっていたものが、約2分で済むようになり、また質問応答データセットの作成と評価も、人手なら500件当たり125～170人時かかる計算のところをエージェントは約17時間で完了させました。
——気になるのは、評価のクオリティですが。
中西
人間が評価した場合と比べて、87.5％の一致率でした。また人間が評価を行うと、スキルによってバラツキが生じますが、エージェントならそうした属人性も排除できます。
RAGは作って終わりではなく、メンテナンスを継続的に行い、ユーザーの利用価値を低下させないことが重要です。現在もこのエージェントで回答精度をモニターし、ツールのさらなる進化に取り組んでいます。
生成AIとネットワークの知見を融合
——今回の取り組みの、これからのビジョンについて聞かせてください。
中西
まずはRAGの改善をさらに推し進めます。例えば、先程話題に出た複雑な「表」や、ネットワーク構成図などの「画像」を自動でベクトル化する技術開発に、いま研究部門と一緒に取り組んでいるところです。
また、生成AIの活用領域の拡大も図っていきます。現在、「障害対応窓口」と「ネットワーク機器ドキュメント質疑応答」の2つのユースケースを運用していますが、今後は「予兆、異常検知」、「監視ルールの立案」、「原因分析・対処方法の立案」、「各種レポート案の作成」などの取り組みをさらに進めることで、最終的にはネットワーク運用全体の高度化を生成AIの活用でめざしています。
最終的には、6つのユースケースでネットワーク運用全体の高度化を生成AIの活用でめざす。
渡邉
ネットワーク分野では、熟練者の引退と生産年齢人口の減少による人財不足が進んでおり、通信事業に携わるお客さまには、これまで蓄積したノウハウの継承と、少人数での運用を可能にする業務の効率化が求められています。これらの課題を解決できるツールの一つが、生成AIだと考えています。日立では、今回ご紹介したような取り組みをさらに磨き上げて、AI関連部署と連携し、お客さまに提供できるよう準備を進めています。
日立グループ全体で徹底活用することで蓄積してきた生成AIに関する豊富な知見。そして設計から運用まで通信キャリアのお客さまを支え続けてきたネットワーク分野の高度な知見。私たちはこれらを結集して、ますますインフラとしての重要性が高まるネットワークの安心、安全な稼働のお役に立っていきたいと考えています。
渡邉 仁（わたなべ ひとし）
株式会社 日立製作所 マネージド＆プラットフォームサービス事業部
エンジニアリングサービス第1本部 テレコムネットワークインテグレーション部
主任技師
入社後、通信キャリアのモバイル系通信ネットワークのインフラ建設事業をSEとして支援。その後、通信インフラの建設、設計関連業務のDXに取り組む。手順書、運用マニュアル、設定ファイルなど各種ドキュメントの作成の自動化などに携わるなかで、生成AIへの知見を深め、現在、ネットワーク運用高度化に向けた業務全般への生成AI活用を推進。
中西 映之（なかにし ひでゆき）
株式会社 日立製作所 マネージド＆プラットフォームサービス事業部
エンジニアリングサービス第1本部 テレコムネットワークインテグレーション部
主任技師
入社後、通信キャリア向けネットワーク・ハードウェアの設計に従事。方式検討からFPGAなどの回路設計までハードウェア設計全般に携わる。その後、モバイル系通信機器の開発に取り組んだ後、これまで開発した機器の保守業務に移行。保守の高度化に取り組む中で、生成AIによるインシデント履歴の活用を推進し、現在その領域をネットワーク運用業務全般に拡大している。
PDF形式のファイルをご覧になるには、Adobe Systems Incorporated （アドビシステムズ社）のAdobe Acrobat Readerが必要です。
