こんにちは！TECH Street編集部です！
2024年9月25日（水）に開催した、 「LLMアプリ開発エンジニア勉強会」のイベントレポートをお届けします。今回は3社のアプリケーション開発に携わるエンジニアが集まり、それぞれの知見を発表し、学びあう勉強会を開催します。
登壇者はこちらの方々！
Seiya Umemoto／パーソルキャリア株式会社 リードエンジニア
Saito Taishi／個人事業主 エンジニア
有馬三郎／セゾンテクノロジー 執行役員 CTO
早速、内容を紹介いたします！
- 月間4000人以上の社内利用を達成したRAG搭載LLMチャットアプリの機能改善の取り組み
- LLMを使ってWebスクレイピングやってみた
- 10個のLLMアプリを開発し、精度と責任の二軸から見えてきた未来
- Q&Aコーナー
最初は、Umemotoさんの発表です。
月間4000人以上の社内利用を達成したRAG搭載LLMチャットアプリの機能改善の取り組み
目次
- はじめに
- 結論
- 概要の説明
- 取り組んだこと
- 今後の課題
- まとめ
はじめに
Umemoto：はじめに社内向け生成AIチャットサービスの概要についてお伝えします。
社内向け生成AIチャットサービスの概要
もともと社内イントラ用のボットサービスはありましたが、ルールベースのため定型の内容以外は回答ができず、そのため、日々蓄積する社内データに対して柔軟な対応をすることは不可能でした。
そこで、生成AIを活用して上手く対応しようと思い、社内で利用される生成AIチャットサービスを構築し、さらに社内文書を参照して回答を可能にさせるため、いわゆるRAGを使って、機能を実現させました。
今回のお話の前提として、対象ユーザーは社内の7000人ほどです。社内文書検索については、前回の発表時にはベータ版でしたが、今回は正式版としてリリース済みです。
結論
2024年度上期の開発を通して
上期の開発を通してのまとめですが実績としては、月間利用者数が4000人を超えました。
アプローチとしては、URL共有機能によって、個人のテンプレートプロンプトを共有し合える状態にし、サジェストプロンプトを表示することでチャットを進めることを実現、慣れていないメンバーの利用障壁を下げることに成功しました。そしてベータ版では業務に関わる到底の文書のみを参照できるようにしていましたが、正式版では全社員がアクセスできる文書に絞って、RAGでアクセスできるようにしました。
概要の説明
アーキテクチャ
前回と変わった部分は、下図の赤色で囲ったところ(データ転送のパイプライン部分)です。
選定技術
選定技術に関しても、赤枠で囲った部分が追加されました。
取り組んだことをさらに掘り下げてご説明します。まずはURL共有機能について。
取り組んだこと
URL共有機能
もともと、テンプレートプロンプト機能は存在していました。
固定で使いたいプロンプトをテンプレート名や説明と一緒に管理する機能でしたが、Entra ID認証に紐づいていて個人単位での管理となり、コンプラ上の背景もあって部署や全社向けには共有ができませんでした。そこで代替案として、URL共有機能を設けました。
これは個人のテンプレートプロンプトをURL形式で他ユーザーに共有できる機能で、個人利用という制約がありつつも、社内メンバーに共有できる状態を実現しました。
URL共有機能（分析方針）
URLを共有して利用すると、新しくプロンプトドキュメントがDB内に保存され、チャット回答のドキュメントにも紐づきます。これによって、テンプレートプロンプトがどのURL共有元から派生しているのかが分かり、チャットを開始すると、どのテンプレートプロンプトを利用しているかもわかります。
そのため人気のあるテンプレートプロンプトを分析し、推進施策に活かすことも可能です。
プロンプトサジェスト機能
事業部側においても生成AIに対する抵抗感といった課題があったので、新規利用者でも利用しやすくなるUI/UXの提供の一環として、プロンプトをサジェストする機能を提供しました。
初期画面の固定プロンプト
初期画面でおすすめのプロンプトを表示していて、今はランダムで4つの選択肢が表示されるようになっています。また、ID情報を元に、事業部や部署ごとに表示するプロンプトを切り替えられるようにしています。
チャットのやり取りで次に質問するプロンプトのサジェスト
また、直前の会話内容から、次に質問するプロンプトをサジェストしています。
鋭い方であれば「Structured Outputsを使ったほうが良いのでは？」という意見もあるかと思います。その通りなのですが、登壇発表時点ではPTU契約では利用可能なモデルでは、対応してないことが利用できていない理由です。
（参考記事：GPT-4oによる生成AIチャットアプリ改善：プロンプトサジェスト機能 - techtekt）
社内文書検索機能（正式版）-RAGの精度維持
またこれまでの社内文書検索機能はベータ版で、一部のファイルを手動で連携する形で実現していましたが、本当に必要なファイルにアクセスするためにも、全社員がアクセスできるファイルに限定をしてパイプラインを構築して連携できるようにしました。
以前は100ファイルほどでしたが、1000以上のファイルに増えるため、RAGの精度担保が重要となりました。そこで、セマンティックハイブリッド検索の力を借りることにしました。
（ 参考記事：社内向け生成AIチャットサービス：社内文書検索機能の正式版リリースとLLM-as-a-Judge導入に向けた改善の取り組み - techtekt）
結果、ファイルの量が増えても回答に大きなブレは生じず、むしろ連携ファイルが増えたことで回答の質が向上したと感じました。
しかし長期的に精度を維持し続けるためには人手で評価を続けるのは困難なため、LLMの力を借りて、自動で評価をできるようにしました。
社内文書検索機能（正式版）-RAGの自動評価
社内文書検索機能（正式版）-RAGの自動評価（生成モジュール）
Faithfulness（忠実度）は、生成された回答が検索されたコンテキストにどれだけ忠実かを評価しています。
Answer Relevancy（回答の関連性）は、生成された回答が質問とどれだけ関連しているかを評価しています。
Context Recall（コンテクストの精度）は、Ground Truth(想定された回答)がコンテキストによってどれだけ再現されているかを評価しています。
Context Precision（コンテキストの精度）は、質問に対して、それに関連するコンテキストがどれだけ上位に挙がってきているかを見ています。
Answer Semantic Similarity（回答の意味的類似性）は、最終的な回答結果がGround Truthとどれだけ類似しているかを評価します。
Answer Correctness（回答の正確性）は、生成された回答が与えられたコンテキストに基づいてどれだけ正確かを評価。
正しい回答と、明らかに間違った回答が想定されるケースで比較すると、正しい回答の方において全体的に評価指標が高くなっています。
今後の課題
LLM-as-a-judge:アドホック→バッチによる自動評価
今後の課題については、まずはアドホック→バッチによる自動評価を実現したいです。
1000以上もある社内文書を開発側で1つ1つ評価を整備するのは現実的にも難しいため、今後はユーザー側のオンライン評価と結びつけられる仕組みを作りたいと思っています。その仕組みと紐付けて、オフライン評価もできる環境を整備したいと思っています。あわせて、Langfuseと組み合わせてプロンプト管理を行って、オブザーバビリティを高めていきたいです。
LLMフレンドリーな社内文書の整備
またLLMフレンドリーな社内文書の整備も必要です。
社内文書の中には、社内ツールに関して古いサービスの説明書が混ざっていたり、画像交じりの文書が比較的多く存在するといった問題点が見つかりました。
そのため古いドキュメントに関しては、運用チームと連携をして順次非公開にしたり、不足文書に関しては社内要望を通して担当チームと連携して文書を拡充していきたいと思います。
画像等の入った非構造の文書ファイルに対して
また、画像混じりの文書に関しては、LLMフレンドリーなドキュメントに整備する方針を検討しています。画像を抽出できるようにするよりも、｢○○を説明する画像が存在する｣という旨をドキュメントに追記することで、RAGによりドキュメント参照を誘導できるようにします。まずはここからアプローチすることが最適だと考えています。
また、非構造の文書ファイルについては、OCRが必要なスキャン文書ファイルや、画像やテキストボックスが複雑に混在した文書ファイルにも対応していきます。
Customer Copyright Commitment（CCC）への対応強化
CCCという、MicrosoftがAzure OpenAIの出力コンテンツに関連する知的財産権のクレームからさらに顧客を保護するための取り組みがありますが、これの必須対応策として、モデルが著作権侵害を防ぐよう指示をするメタプロンプトの設定やテスト及び評価レポートの作成、コンテンツフィルターの設定などがあります。注意点としては、(登壇発表時点において)公開日から6ヶ月以内に新しい対応策を実装する必要があることです。
著作権の問題などはどの業界においてもシビアに関わってくると思いますし、弊社においてもこういった環境もより強化して行きたいと思います。
更なる機能拡充
さらなる機能拡充としては、Web検索機能やファイル読み込み機能、コードインタプリタ機能、画像生成機能などを検討しています。
KPIの見直しと効果的なデータ分析
さらに今後は、例えば社員の残業時間の削減率など、より深堀したKPIを策定し、生成AIチャットサービスによる業務効率化を促進していきたいです。
まとめ
- 2024年度上期を通して普及率向上のためにUXを向上させる機能のリリースを進めました
- LLMOpsの体制整備のためにLLM-as-a-judgeのアドホック実行をできるようにしました
- 今後の方針について話しました
Umemotoさん、ありがとうございました！
続いては、Saito Taishiさんの発表です。
LLMを使ってWebスクレイピングやってみた
Saito：「LLMを使ってWebスクレイピングやってみた」というテーマで発表させていただきます。
概要
今回の主題である概要図は以下の通りです。ユーザーからのリクエストを裏側に送り、LLMで考えさせてからレスポンスとして返しましょう、という仕組みになっています。
ユーザーからのリクエストとしては、例えば｢本日のYahooニュースを取得して｣といった大雑把なものを想定しています。そしてLLMのいわゆるエージェント機能を使用してURL情報を取得し、関数を自分なりに作り、レスポンスとして返すことを想定しています。
共有したい３つ
本日共有したいことは以下の3つです。
- LLMと資格情報
- Agent構築
- 実装範囲
LLMと視覚情報
自動運転を開発する上でLLMの活用が注目されている、というニュースを見かけました。例えば以下の画像のような状況に出会ったとき、皆さんはどう対応するでしょうか？
参照：Heron-Bench: 日本語Vision＆Languageモデルの性能評価ベンチマークの公開
参照：LLMがなぜ完全自動運転に必要なのか｜山本一成🚗TURING
1枚目のスライドであれば、例えば｢奥の信号が故障しているのかな？それなら作業員の人に従おう｣といった判断ができると思います。
これまでの自動運転の技術というのは学習しているデータに依存していて、「未知のもの（データ）に遭遇したときには上手く対応ができないのではないか」といった懸念がありました。しかし、LLMは学習データが非常に膨大であるがゆえに推測能力があり、未知のものに遭遇したときも柔軟な対応が可能だという点が注目されています。
LLMを使って自動車を運転するスタートアップは出てきていますが、この開発難易度は桁違いに高いです。そこで、私たちスタートアップがどのような開発領域であれば取り組めるのかと考えたときに、LLMを使ったソフトの操作に開発の余地があると考えました。
開発動機
LLMを使ったソフトの開発について、実際の事例を見てみると、「LLMのGPT-visionモデルを使って64マリオを操作させる」というものがありました。
Agent構築
では、LLMでソフトを操作するときにはどうするのか、という話ですが、個人的にはAgentを構築するのが一番良いと思っています。
Agentとは、ユーザーからのインプット情報に対して、LLMがタスクの判断から実行までを行う機能です。
LLMがユーザーからのインプット情報を元に出力して、｢agent_should_continue｣のところで別のアクションを起こした方が良いのか、またはLLMが受け取った出力をそのままユーザーに伝えるのかを勝手に判断する、という機能です。
コード紹介
今回参考にしたコードはこちらです。興味がある方はぜひ動かしてみてください。
Agentの構築手順
Agent構築の手順としては、①State、②Agent、③Prompt、④Functionの4つを守れば大丈夫です。1つずつ詳しくみていきます。
①ステートの定義
ステートは、LLMに渡す情報を記録するためのクラスとして定義をしています。
pageは現在いるpageのURL情報を格納している変数です。
重要なのはPredictionで、LLMからの回答をそのまま他のNodeに伝える機能があります。そしてimgでは、画像をbase64でエンコードしてLLMに伝えるという作業をしています。
②ノードとエッジの定義
ノードとエッジの定義は、いわゆる関数をどう動かしていくかという順序と分岐を定義します。
③プロント文の作成
④関数の定義（ツール）
実装した際の課題と原因
以下の画像は、｢海外のメディア（TechCrunch）からスタートアップの情報を取得して｣とLLMに投げました。すると、画像の左側にあるカテゴリーの｢StartUP｣というボタンを永遠に押してしまう、という事象が発生しました。
原因はおそらく、画像を読み込ませたときにスタートアップの情報が入っているかどうかを判断していないためだと思います。
そこで｢スタートアップの情報は入っているか｣という質問に対して、yes/noで返すということをAgentの中に組み込む実験をしました。
まずパソコン画面をスクリーンショットさせてLLMに渡し、ユーザーが欲しい情報が入っているか判断をさせます。yesであれば別のAgentに渡してスクレイピング作業を開始し、noであればWebの中で探索をする、といった実装の内容にする予定です。
失敗
失敗した原因としては、まず、GPTモデルに画像を読み込ませるためにはbase64にエンコードする必要がありましたが、トークン数の上限もありできませんでした。また、playwrightというPythonのライブラリを使っていましたが、スクリーンショットの文字化けがひどくて画像を上手く渡せませんでした。そして最後はよく分からないのですが、ページ遷移をする際にランタイムエラーになるときもあれば実行できるときもある、といったことが起こり、かなりの時間がかかったため、今回は失敗に終わってしまいました。
今回の開発を踏まえたまとめ
今回はAgentの構築作業を0→1で行ったために、とても時間が取られてしまいました。
githubにはAgentの構築方法のチュートリアルがあるので、まずはそこから試してみるのも良いと思います。
このようにAgentのNodeとEdgeの関係が見やすく書かれているので、この中から自分でやってみたいタスクを探してカスタムすると、開発スピード的にも良いと思います。
なのでそれらを参考にして組み合わせていけば、基本的なものは実装できるという印象です。
LangGraphによるエージェントの実装方法
- 最初から0→1ベースで作ろうとすると、どのようなステートを作るか悩みます。
- ミニマムの構成は、先ほど紹介した論文の構成を参考にすると上手くいくという印象です。
最後に
- LLMとVisionの領域（VLMと呼ばれる領域？）は個人的に注目している
- LLMの出力をもとにソフトウェアを操作することができる
- 独自でエージェント構築する時は既存のものを参考にしまくる方が良さげ
以上で発表は終わりです。
Saitoさん、ありがとうございました！
続いては、セゾンテクノロジー 有馬さんの発表です。
10個のLLMアプリを開発し、精度と責任の二軸から見えてきた未来
有馬：私からは「10個のLLMアプリを開発し、精度と責任の二軸から見えてきた未来 」というテーマで発表いたします。
私たちはHULFTという製品の開発、販売、サポートをしている企業です。30年間、HULFTの開発やサポートをしている中で、お客様が1万社を超えてきました。その中で、お客様からの問い合わせを受けて回答するといったサポート業務を、生成AIを使ってできないかという取り組みを始めて、現在では本番で活用しています。
また、HULFT Square×生成AIに関しては、直接ユーザー様にご利用いただくようなチャットボットを現在開発中です。
2023年5月 生成AI研究会”LLM Mavericks”を組成
組織体制について、会社全体に生成AIを浸透させ、全員が生成AIに取り組めるようにするためにLLM Mavericksという研究会を組成しました。
当社の生成AIの活用方針について
LLM Mavericksでは10個ほどのアプリケーションを作っていますが、それらのアプリを2軸で評価してみました。
縦軸は精度です。当然、精度は高いほど良く、精度を少しでも上げようと思うとRAGが必要となってきます。しかし全ての精度を高く保つのは無理があるので、LLMの回答を「どう使うか」「何に使うか」が重要となってきます。
私たちは昨年、AOAIを使って社内向けにチャットボットを開発しました。これは利用者が壁打ち程度で、自分の考えを伝えて要約してもらったりヒントを得たりするものです。これは回答の精度はそこそこで良いですし、その回答をどう使うかもあくまで個人利用です。したがって、比較的簡単にユーザーにおすすめできるものですね。
そして次に取り組んだものは社内利用のテクニカルサポートで、HULFT製品のサポートに使うものです。人が介在しながらも、チャットボットを利用した素早い回答を展開しています。チャットボットから得た回答も人のチェックが必要です。もちろん、LLMの回答の精度が高ければそのままユーザーに回答できますが、そのためには「モデルを選びなおしたり」「RAGの精度を上げたり」「プロンプトを変えたり」といった、いろいろな箇所のチューニングが必要となります。しかしチューニングをやるほど期間が長くなるので、得たいものが得られなくなってしまうため、期待値調整が必要になってくると思います。
HULFTテクニカルサポートでのエンジニアの回答作成を支援
アーキテクチャについて下図をご覧ください。
ユーザーからの問い合わせに対して、Claude 3 HaikuとCommand R+という2つのモデルを使っています。
この2つのモデルを使っている理由として、ユーザーからの問い合わせというのは、1つのインシデントに対して1つの質問というのが基本ですが、人間は1つの質問の中に、知りたいことが2つ3つと含まれていることがあります。そういったものをそのまま検索をかけるとなると、変なものをひっかけることがよくあります。そのため、まずはClaude 3 Haikuで質問を分割してから検索エンジンに投げて、その回答をCommand R+で引用をつけて返しています。Command R+を使用しているのは、引用がつけやすいからです。
バックエンドはAWS Lambdaを使用しています。実際にはLambdaからコンテナを起動しますが、質問単位で起動するのでそこまでコストもかかりません。これによって全体のプロセスが3割ほど短くなったり、初めての人であっても回答精度を上げることが可能となっています。
フェーズ2は新たにプロジェクトチームを組成し推進
フェーズ1の社内向けの取り組みから、現在はお客様が生成AIを活用してHULFT Squareを効率的にご利用いただく取り組みを実施しています。
生成ＡＩを使って開発する生成AIアプリ
私はCTOとして開発側も生成AIを使ってほしいと考えているので、私自身がやってみた取り組みをご紹介します。
DeeLのローカル版を作ってみた
既存のOSSをベースにモデルを追加して、DeepLのローカル版を作ってみました。
ベースにしたOSSに足りないモデルを追加し、オンプレミスモデルへのアクセス機能を追加しました。これによって、例えば翻訳など今は必ずインターネットを通さなければならないものも、ローカルだけで動かすことが可能となります。セキュリティに敏感な企業であっても使いやすいものとなります。
今回はCursorというAIコーダーを使いました。
実際にはプログラミングのコードを書くものと、チャットで対話するものがあります。きちんとしたコンテキストで伝えるほど、正しい回答が得られます。
例えば、下画像のようにオープンソースの素のソースコードに対して、｢どこから修正すればよいか｣と聞いてみます。
すると、下画像のように修正すべきファイルとどのように追加すべきかを回答してくれます。
私は今回使ったElectronはそこまで詳しくありませんでしたが、これくらいの変更は容易にできました。問いかけをしながらソースを得て、アプライして反映させ、実現させることができました。
これはシニアの働き方を変えますし、ジュニアのコードへの向き合い方も大きく変えると思っています。
実行に必要なスタック
今回実際にやってみて、ソフトスキルが必要だなと感じました。しかし言語に関して一定の知識があれば、初学者レベルでもサクサク進めることができました。
今回の取り組みで感じたこと
今回感じたのは、CursorというプログラミングのIDに対して、どのように質問をするかという言語の書き方、それをどう読むかという能力は重要だと感じました。また、いずれにしてもTypescriptを動かすので、Node関連やIDEの知識などはとても重要です。AIができるから知識は不要、ということではなく、標準で開発知識を持っている人が新しい言語に取り組む際のハードルは下がった、ということだと思います。
ぜひ、今の自分の状況などを踏まえながら取り組むと、とても楽しいエンジニアライフが送れると思います。最後に、AIはDBレベルでシステムに入ってくると思うので、ぜひ触って欲しいと思います。
また、文章の構成力や読み解く力はますます重要になってくると思います。
それらを身に着けながら、オープンソースを使って改修する。実際に改修して動くととても面白いです。自分のアイデアで動かすことができるので、まさに新時代のプログラミングを楽しんでもらいたいと思います。
発表は以上です。
有馬さん、ありがとうございました！
続いてはQ&Aコーナーです。
Q&Aコーナー
（Q）運用コストに関してうかがえるでしょうか。
Umemoto：運用コストについては、非常にシビアな課題です。特に、LLMのコストがネックになっています。PTU契約が少し高価である点が影響しています。
あとはインフラコストですが、こちらはS1プランなど割と使いやすいプランを利用しています。
有馬：チャットボット的なものであればコストの大半はトークンの量になると思います。無駄なインプット、アウトプットにならないような留意点は必要です。
今なら4o miniなどコストがかなり低いモデルもあるので、まずはやりたいことをやってみるのが楽しいと思います。
（Q）聞き逃していたらすみませんが、Azure Open AIを選定した理由を教えてほしいです
Umemoto：クラウド上で生成AIが使えるようになり始めた頃から、Azure Open AIの導入を始めていました。当時から使えたのがOpenAIであり、Azure AI として整備されていたため、コンプライアンス面でも稟議を通しやすく、利用を始めました。
「ClaudeやGeminiでもいいのでは？」というご指摘はその通りだと思います。今後も、色んな選択肢を検討していく予定です。
（Q）回答モデルと評価モデルで異なるモデルを利用している理由はありますか？
Umemoto：同一モデルを利用すると評価を不必要に良くしてしまうケースがあるからです。そのため、回答モデルと評価モデルを分けているのですが、より客観的に評価するためにAzure OpenAIとGeminiという形で分けて評価
（Q）さいとうさんはスタートアップ企業内での開発ですか？開発体制とか各種技術選定とか、聞いてみたいです。
Saito：開発体制はやりたい人がやるっていう体制です。
本日の発表内容は個人開発になります。入っているコミュニティでキャッチアップした技術を採用しています。
（Q）Difyでノーコードだと厳しいですか？
Saito：「コードを書きたい」と理由でまだ手を出せていませんが、興味はあります！
有馬：Difyでできることも多いと思います。個人的にですがLocal LLMがもう少し使えるようになるとDifyはかなり使えるツールだと思います。クラウドだと他の手段も多いので。
（Q）具体的にどうビジネスに繋げようと考えていらっしゃいますか？
Saito：社内の中にファイルってごまんとある。これをどのようにデータベースに落とし込むかが課題になってくると思います。今後LLMを活用してファイルを推測し処理を進めることで、ビジネスに繋げる可能性があると考えています。
有馬：当社はETL製品を開発していますが、ワークフローの自動生成、レビューなどに取り込んでいきたいと考えています。
まずは、製品向けのＱＡチャットボットの開発を進めています。
（Q）actionゲームじゃなくシミュレーションとかならいけそうですね。
Saito：共有した動画でも述べられていましたが、リアルタイム性の観点からactionゲームをプレイさせれるようになるのは少し先の話かもしれないですね。ただしアルゴリズム変えれば不可能ではないと思います。
（Q）齋藤さん、個人開発なのですか？！外向けサービス？
Saito：最初は個人開発から始めました、会社内でも開発を検討に入れています。
（Q）テクニカルサポート担当者の実務側の手間と加工数は実際に変わりましたか？あと、お客様満足度とかも変わったりしたかも興味あります。
有馬：セールスフォースに記録されている情報を転記して回答を待つだけなので、手間はあまりかかってないと思います。最初のラフ回答の作成速度はかなり早くなりました。
（Q）Lambdaの中で完結しているように見えますがDBもないということですよね、このタイプは初めて見ました
有馬：コンテナで起動させたと説明していますが、これにVectorDBを同梱しています。このVectorDBはオープンソースのものを活用しています。
（Q）各社さんのハルシネーション対策とか、気を付けなければいけない危険な注意点等の対策も聞いてみたいです
有馬：生成されたものを何に使うか次第で変わります。これはコスト（労力と実際のお金）がかかるので。
・関係ないことを返さない
・法律に違反することを返さない
・あきらかな嘘をかえさない
・差別的・暴力的など不適切を返さない
AWS Agent for Bedrockを使い、ある程度抑えられますが、何をどこまでやるか、どこまでの完璧さを求めるかで手法が異なり、それがコストとなります。
（Q）アプリ作っても、数か月でベンダーさん側からさらにエエ感じのサービスでたやん。。。みたいなことありませんか？この辺りどう対応・考えて取り組まれてますか？これは皆さんに聞いてみたい。
有馬：あります。現在の生成AIはそういうことがあるから面白いと思います。１つに時間をかけずにいろんなアプローチを試すことで新しいものが出たときによりよく評価することができます。
今は、 Compass Over Mapsの精神で臨むのが良いと思います。
（Q）あれ？セゾンさん、名前変わりました？
有馬：２０２４年の４月セゾンテクノロジーへと社名変更しています。引き続きよろしくお願いします。
（Q）セゾンテクノロジーさん、LLMのすごいチーム創設した～みたいな記事を見た気がする。
有馬：LLM Mavericsというチームを昨年５月に立ち上げました。
いろいろなアプリケーションを作り、多くのモデルを評価してきました。ＡＷＳの基調講演でも紹介されました。
（Q）HULFTめっちゃなつい
有馬：HULFTは1993年にリリースされたデータ連携ソフトです。2004年にHULFT10がリリースされます。ぜひご期待ください。
（Q）DeepLローカル版面白い、これ需要ありますね
有馬：今後、Localで動くLLMは一般的になると考えます。アプリケーションが生成AIを内包するのは時間の問題と考えます。
また、セキュリティ面からもこの動きは歓迎されると思います。
（Q）LM studioのLOCAL版がまともに動くスペックはどの程度でしょうか？GPUが無いと動かない？CoreUltra搭載ならOK等、助言いただけませんでしょうか？
有馬：自宅ではMac miniで動かしました。これはM2 Proです。
会社では4090で動作させていますが、8Bぐらいのモデルサイズであれば十分な速さとなります。
GPUがない場合ですが、LM Studioはllama.cppでも動作しますが、こちらは未検証です。
（Q）ローカルLLMを使ったアプリ開発には、Mac mini 16GB で十分でしたか？もしくはも追う少しスペックがあったほうが良かったなど、ご感想 をお聞きしたいです
有馬：モデルによりますが、8Bであれば基本的には問題ありません。ただし、それを超えるとモデルのロードができないし、できたとしても使い物になりませんでした。
（Q）各社素晴らしいソリューションを開発されていると思いますが、必要な開発体制を教えていただきたいです。必要なスキルセットなど。
有馬：一定レベルのクラウドスキルは必須です。
スキルとしては、何を目的に生成AIを使うのか？というマインドセットと、楽しむというスキルがあれば、活用、応用という点では可能と思います。
基礎研究周りは数学的な知識が必要です。
（Q）RAGを稼働させていますが、ベクトルストアに非常にコストがかかっています。コストに関して工夫していることはありますか？
有馬：Embeddingにコストがかかる点かと思います。確かに、精度の調整に何度も行うとコストはかかります。
小さく始めるか、OSSのVector DBを使用するなどでしょうか。
（Q）自社内でせっかく開発したけど「使われない…」みたいなことってありましたか？？
Umemoto：社内向けに開発したチャットアプリは、普及率が６０％で、４０％の人には使ってもらえていません。最終的には、１００％の利用を目指していきたいです。
この４０％をどう埋めていこう、というところで、分析チームや推進チームと協力して、要因を調査しています。セグメンテーションを行い、ユーザーをヒートマップで分類し、職種や部署ごとの利用率を分析して戦略を練っています。
Saito：当社はスタートアップで８人くらいしかいないので、使われないツールがあれば、それ自体を切るという判断をすることもあります。
納品したのに使われないということも耳にします。実際に使っているのは、上位２割という状況はあるのかなと思います。残りの８割を諦めるのか、それとも会社全体でコストをかけて教育進めるのかの選択肢になりますが、僕の場合だと２割を最大限に活用する方向にシフトすると思います。
有馬：当然、使われないものもあります。
現状、ユニークな利用率は約５０％くらいです。無駄なコストを垂れ流すようなアーキテクチャにしない対策は必要です。コール単位でコストが発生する仕組みを採用するなどの工夫が大切だと思います。
（Q）LLMアプリ開発ならではの苦労した点があれば各社さん聞いてみたいです
Umemoto：専用のインフラ整備とLLM自体の使用に関する制約。
インフラに関していうと、ファイルアップロードもユースケースとして入ってくる。
Azure、OpenAIに依存しすぎているので、使いたい時にサービスが利用できないケースが発生することもありました。
Saito：生成結果の評価方法に迷った点がありました。また、エージェントの挙動が予測できず、ブラックボックス化されている部分が多かったため、エラーの読み解きに苦労しました。
有馬：利用者からの期待が高まる一方で、コンプライアンスからの「それ、やっていいの？」という声もある。
また、時間をかけて開発したにもかかわらず、新しいサービスが登場して、より簡単に実現できるようになることも苦労の一つです。それがおもしろいのですけど。
いかがでしたでしょうか、レポートの内容は以上です。
次回のイベントレポートもお楽しみに♪
