正答率35%から93%へ、清水建設が建設技術文書をRAGで検索する試み

効いたのは、文書を1ページごとのまとまりに切り出すという分割の設計です。RAGは文書を細かく区切って検索する仕組みのため、区切りが粗ければ関係のない記述まで混ざり込み、細かすぎれば前後のつながりが失われます。建設技術文書という対象に対して、試行錯誤の末に1ページという単位へ落とし込んだ判断が、検索の土台を作りました。

図表の解釈という最大の難所には、自社だけで抱え込まない体制で臨んでいます。建設の技術文書では、工法の手順や注意点が本文ではなく図や表に置かれていることが多く、文字として読み取るだけでは肝心の情報が抜け落ちます。この部分でLightblueが画像処理の最適化を担い、清水建設側が現場で実際に飛ぶ質問と対象文書を持ち込むという役割分担が取られました。どちらか一方の知見だけでは越えにくい壁を、分業で崩した形です。

回答の根拠となる該当ページを示す参照の作り込みも、実務に耐えるかどうかを分けた要素だったのではないでしょうか。建設現場は判断を誤ったときの影響が大きく、AIの答えをそのまま鵜呑みにする運用は成り立ちません。原典に戻って確かめられる設計は、現場が長く守ってきた確認の作法を壊さずにAIを差し込む余地を作りました。さらに、社員自身がTeamsから独自のアシスタントを組み立て、チームで共有できるようにしたことで、報告書の要約や前任者の引き継ぎ資料の参照といった使い道が現場の側から次々に立ち上がっています。