前置き・前提

• 最近の知見をベースにした整理記事
• 記事テーマは言わずもがな生成AIを用いた（用いたい）プロジェクトが増えていることに起因
• 過去数年前のAI導入したいブームと温度感は近しいものがある
• ただし、導入にあたって扱うもの（特にモデルや精度感）が違うこともあり、過去と同じ感覚で進める事柄もあれば、結構違う観点もある
• 今回はプロジェクトを管理する目線から、直近の知見も踏まえて要素を整理・洗い出しておきたい
• （いつもの如くディスクレーマーですが、個人の意見が含まれます）

過去ブームと変わらない事柄・マインド

そもそも導入が必要か疑う

• このマインドは過去から全く変わらずという感じ
• 過去もそうだったが、「とりあえず流行っているから、上司から言われたから~」などよく合ったケース
  • その流れでPoC(概念検証)をしましょうの流れがベースだった
• 今回の生成AIでも基本的には同じ
  • 例えばRAGのケース、現時点の業務でシステム検索する持ち合わせてない中で、いきなりRAG導入を検討する場合、本当にRAG必要ですか？シンプルな全文検索ができるようになれば、一旦解消しないですか？的な観点
  • さらにChatGPTといった手軽さ・簡易さの刷り込みにより、検証も容易にできるのでは？というハードル底上げもよく理解しておくべきポイント

最期は力業でいく可能性あり

• NLP分野において、古典的なタスクでも汎用的なタスクでもそれなりにプロンプトを使って成果を出せてしまうのは本当にスゴイところ
• ただし、複雑なタスクやマルチモーダル要素がある、かつシステム側での制御やユーザー側での行動制御でも難しい場合において、これまでと同じく力業で精度をカバーするシーンが存在する
• その場合、LLM自体の精度を向上させるというよりかは「組み合わせやアンサンブル」が近しい
• つまり、これまでのDSやMLの知識を振り絞って対応することになるので、生成AIに特化した話だけで済むわけではないことが多いとは思う

過去ブームと変わった事柄・マインド

PoCと言うべきか

• これはメタい感じもあるが、検証はやるけど概念検証ではないイメージ
• 計画がしっかりしており、今のモデルでやれることが事前に落ちている（他PJから横展開されている場合や計画者が手元でしっかり調査している場合など）であれば、検証を実施する意味合いも変わってくる
• 感覚としては50%以上の確率で本番として実現されるぐらいの気持ちでもいいのでは
  • 過去は数サイクルのPoCが続いて結局本番で実現されないことも多々あった
• つまり、早い段階から運用（特に評価）のことは考えておくべき

精度やモデルを追わない（追いすぎない）

• 上記に関連する話だが、もし解決すべきタスクが「業務改善」の範疇であり、実のフローに対して置き換えが発生するものに関しては、超えるべき「精度」を設定することが可能となる
• 過去でいくと、その数値を目標としてPoCを行うことになる
• 精度を追いかけるというのは必要なことであるが、現在のご時世としては決められた期間の中で、スナップショットでの検証も重要
• 具体的には、クローズドなモデル（代表的にはGPT、Claude、Geminiなど）のアップデートが早すぎるのと、この先プロバイダがさらに増えるかもしれないということ
• 精度は今後も上がる前提、かつコストは（おそらく）安くなる前提でモノゴトを考えて、選択肢を持ちすぎない、エンドレスに検証を続けすぎないことが大事

モデルよりUI/UXの話が多くなる

• 検証の具体化が進むにつれて、より白熱するのは「UI/UX」側
  • 意図としては、課題に対してそれなりに精度が出ている状態であれば、ユーザーにアウトプットをサジェストするフローを再考する部分に目がいく
  • 精度が高くなればなるほど、ユーザーとLLMの接点は増やしたくなるので導線はより複雑になるイメージ
• このタイミングで誰がUI/UXの話をするのかが結構重要
  • 検証においてはPMやMLエンジニア/データサイエンティストがメイン
  • システムエンジニアやデザイナーはこれまで登場する機会少なかった
• つまり、検証における体制や相談できる体制にも先回りしておく必要あり

受け入れのはハードルは下がる、ただ定性評価は重要度を増す

• 本番導入に当たっての受け入れハードルは高くない
  • 理由としてはChatGPT等のチャットやりとりの日常普及率が様様なため
  • （チャットでなくても、UI/UXがLLMありきのフローで整理されており、フローが現工程より大幅に増えてなければ、特に特段問題にもならない気がする）
• それよりか重要な点は、生成する最終的な出力が「モデル&プロンプト」次第になる場合の評価
  • 誰が評価をできるのか問題が確実に出てくる
  • 事前にネゴシエーションできていればOKであるが、大方それなりの文章量（プロンプトや過程、最終出力も踏まえると）を見てもらうことになるので、この点は押さえておく
  • 過去はここまで進むことが残念ながら少なかったため、違いとして現れているのかもしれない

さいごに

• 今回は直近のナレッジから、進め方や考え方をメインに書き出してみました
  • （特にPoCとは区別した言い方があれば嬉しいっすね～）
• マインドも一部であり、今後さらに事前に理解すべきポイントも言語化していきます
  • 本番導入における実運用やアーキテクチャパターン・検討も出していければ

宣伝

• 今日記載した内容に関連した内容で自社セミナーをやります
• もう少し具体的な内容とアプローチ方法や事例をお伝えできればと思っていますので、お気軽にどうぞ