ブラザー工業プリンティング・アンド・ソリューションズ事業LM開発部の挑戦
第2回 実装を通じて学ぶ─RAG開発で得た気づき
AWSやAIを一から学びながら挑戦したRAG構築。試行錯誤を重ねるなかで見えてきたのは、ファインチューニングよりもRAGを選ぶ理由、そして「情報構造化」の重要性だった。
【ブラザー工業株式会社】
ブラザーグループは、1908年にミシンの修理業として創業し、以来、110年を超える歴史の中で、事業の多角化、グローバル化を推進。あらゆる場面でお客様を第一に考える”At your side.”の精神で、優れた価値を迅速に提供することを使命としている
【プリンティング・アンド・ソリューションズ事業LM開発部】
家庭用から業務用まで豊富なラインアップを誇るラベルライター・ラベルプリンターなどを設計・開発。お客様の多様なニーズに対応している。
目次
手探りからのスタート
RAGを開発するうえでの障害や壁みたいなものはありましたか。
水谷 そうですね、僕らは初学者でしたので、AWSだったりAIについて一から勉強するところから始まっていますので、そこはたくさんサポートしていただかないときつかっただろうと思います。でも会話する場を多く設けていただいたので、うまく行ったと思います。
AWSを使ったということですが、社外秘、部外秘の情報を扱う際に気をつけていたことはありますか。
水谷 そうですね。AWSについては社内でちゃんと管理されている環境に移行してもらっているので問題ありませんでした。そこのセキュリティは自社基準で担保している状態です。
ブラザーのセキュリティのルールに則って進めたというわけですね。
水谷 社内のセキュリティ管理部門に許可を取ったうえで、進めていました。
他に大変だった点があれば教えてください。
水谷 ブラザーはいろんな商品を持っているので、単純にキーワード検索すると、本来聞きたい商品のことではなく、他の商品の情報も混ざってきてしまうので、そのあたりはディスカッションをして解決していきました。
どういう解決方法になるんですか。
水谷 プロンプトを工夫するというのも1つですし、情報の登録の仕方とか検索の仕方を工夫したりしていました。
RAGに入れ込むデータの量はどのぐらいあるんですが。
水谷 製品情報だけでも何万とかの行数の領域になってくるので、少なくとも人が扱える量ではなかったことは確かです。
RAGの実装がうまくいっているのかどうかはどうやって判断するんですか。
水谷 今回は公開情報である製品カタログや取扱説明書からスタートしたんですけど、それこそ取扱説明書をつくっている部署の人たちにも協力いただいて、出てきた回答が具体的かどうかジャッジしていただきました。さらに、フィードバックの機能をつけて、実際に利用者から情報を取れるような仕組みを仕込んだうえでスタートして、改良点を数値データから考えようという形で回していました。
今回のRAGシステム構築ですが、社内における横展開も考えていらっしゃいますか。
水谷 社内でも同じような活動をしている方々もいるので、今回僕らが持ち帰ってきたノウハウと合わせて、ある程度みんな技術がわかった状態で話ができると、さらにもっといいものに昇華できるだろうという視点でやっています。今回のRAGシステム利用を通して考えたいのは横展開ではなく、自部門におけるデータ管理やナレッジマネジメントのあるべき姿です。技術はどんどん進歩していくと思いますが、そこに入れ込むデータは変わらないため組織として残すべきものが何かを考えるテストケースとしていきたいです。生成AIをどんどん使っていくことになった場合に乗り遅れないように、またその先のビジョンをイメージする際に今回のケースが実例として活きてくると考えています。
ファインチューニングではなくてRAGを選んだ理由
ファインチューニングではなくてRAGを選ばれた理由をお聞かせいただけますか。
水谷 ものづくりの話になると会社内でしか通用しないような専門用語がすごく多くて、僕らも過去の資料を参照して学ぶことが多いんですよね。それをAIに回答させるのは結構難しいというのは理解したうえで、過去の資料を直接取り込んでくれるRAGを選んでいます。ファインチューニングの手間を考えると、直接データを参照した方がトータル的にはいいだろうというのと、継続利用も含めてデータベースだけいじっていけばいいので、そういったところも含めていい技術だなと感じています。
RAGありきで話が始まったということではないんですね。
水谷 そうですね。その頃、話題になっていた技術でもあったので、提案していただいて、じゃあそれを軸にしようということになりました。あと、勉強に適しているというのも大きな要因でした。RAGだとAWSの設計もやりますし、コードも書きますし、フロントエンジニアリングもやりますし、トータルとして学習するにはいい教材だったと思います。やっぱりデータは日時どんどん溜まっていくので、それが溜まっていった時に古いAIをもう1回チューニングにするのは現実的ではないので、それこそモジュール化の発想でRAGを選んだということです。
普遍性の高い形でチューニングするよりも、限定されたデータを対象にするという意味でRAGの優位性があるという考え方なんでしょうか。
水谷 そうですね。AI自身を育てるというよりは、AIに見せる資料をなんとかしようという発想です。AI自体はそれこそ日夜進歩しているので、もしそこが切り替わってもデータは無駄にならない。
わかりやすいですね。ファインチューニングとRAGの話って、どうしても混同しがちですけど、AIそのものを育てるか、データの精度を上げるのかはコスト的に全然違うのですね。
水谷 ファインチューニングだとめちゃくちゃ時間がかかるというのもあります。その時間を待っているのがもったいない。ファインチューニングはコストがかかる割には、どのぐらいの精度を確保できるかもわかりません。RAGはつくってしまえば基盤は変えないでモデルを変えるだけでよかったりしますし、プロンプトを変えるだけでいいので、対応も継続的にできます。
その辺は議論するなかで出てきたんですか。
水谷 複数の課題をリスト化してエクセルで出したときに、トリプルアイズさんから、「RAGを使えば横断的にできますよ」とご提案いただきました。先ほど話したように、内部技術ではステップを踏んで検討するのですが、外部技術になると突然実用から入るので、技術の要旨を正しく組織に還元したいという話をさせていただいて、まさに伴走していただいて勉強しました。社内にもリソースはあるんですけど、外部の方とやる方が柔軟性もあるし、視点も広がるというのは実感しています。
最初の段階から社員さんが利用する以上の想定はされていないということですよね。
水谷 そうですね。学習するうえで1番大事なのはサイクルを回すことだと思っているので、1年間は担当者レベルのニーズである程度成果の出るものにしようと絞り込みをしていました。
「情報の構造化」こそがAI活用の鍵
今回のRAGシステムの構築を勉強なさってきたなかで、いちばんの気づきはなんだったのでしょうか。
水谷 情報の構造化がいかに重要であるかということです。ナレッジマネジメントと言い換えてもいいかもしれません。機械が理解できるように情報を機械に寄せていくということです。となると、過去の情報の再構造化作業も必要ですし、今後の情報はきちんと構造化してマネジメントしましょうと結論づけています。
過去情報の再構造化は結構大変そうですね。
水谷 そこはこれからの課題ですね。
今回学ばれた成果はどう社内にフィードバックしていくのですか。
水谷 僕らが勉強してきた技術の要旨を部内に知ってもらおうという活動であったり、それを知ってもらったうえで、各自どう使いますかと発信して、今度は僕らが伴走者になって社内の人たちに持ち帰ってきた技術を使っていただこうという予定です。AIに関するリテラシーが低いというのが課題だと思っていて、それを上げて、AIは使えるものだと認識してもらって、アイデアを膨らますという段階を踏まなきゃいけないと思っています。これも勉強した後だからこそ言えることですが。
勉強することで、リテラシーを高める必要があると感じられたわけですね。
水谷 学ぶ前と後では、データを見たときにこれだったらいけそうかいけないか、見方が変わってきました。生産活動のプロセスの中にそういう視点があるとないとでは、全体の結果にもだいぶ影響してくると思います。やっぱり僕らも実際にコードをいじってこそわかることがあって、実践こそが学びであると実感しました。
