キッツ、人事・総務の問い合わせに答えるRAGチャットボットを2カ月で検証

精度の伸び悩みを、AIの答え方ではなく答えのもとになる文書の探し方の問題として切り分けた点が、この取り組みの起点です。当初はキーワードを軸に文書を引き当てるAmazon Kendraと生成AIサービスのAmazon Bedrockを組み合わせていましたが、これを文章の意味の近さで文書を探すベクトル検索、Amazon Bedrock Knowledge Basesへ差し替えています。就業規則のような文書では、社員が使う言葉と条文の言葉が一致しないことが珍しくなく、正しい条文にたどり着けなければ生成側をどう工夫しても答えは合いません。探す層を入れ替える判断が、実務水準への道筋をつくったと考えられます。

構成変更後も残った「あと一歩」を、具体的な誤答のケースに翻訳して持ち込んだ進め方も見逃せません。精度が低いという訴えのままでは打ち手が定まりませんが、どの質問でどう外したかまで具体化すると、Knowledge Basesのオプションを有効化するという、手の届く調整作業に変わります。曖昧な不満を設定項目のレベルまで降ろす作業を挟んだことが、限られた期間内での着地を可能にしたのではないでしょうか。

期限を先に置き、既存の土台の上で組み立てた設計も、この短期決戦を支えています。AWS上で生成AIを検証するためのユースケース集であるGenerative AI Use Cases JP（GenU）を出発点に据えたことで、ゼロから作る工程が省かれました。手を動かすのは自社メンバーとし、支援側は機能要件の洗い出し、導入手順の案内、導入作業の立ち会い、技術的な質問への回答に回るという役割分担も、週1回の定例やクイズ形式の復習とあわせて、開発物と同時に社内の知見が残る形につながっています。