9月に入社したエンジニアの藤田と申します。AI・LLM事業部で新卒として働くとどのような業務ができるのか・その魅力をお話しいたします。
AI・LLM事業部が開発するプロダクト「Ai Workforce」
AI・LLM事業部では、主にエンタープライズのお客さま向けに、幅広い業務の効率化を対象としたAIプラットフォーム「Ai Workforce」を開発しています。
実現できること・機能の詳細については、以下をご参考ください。
「AIで特定の業務を自動化できるかどうか」の二極化ではなく人間とAIが協力し合いながら業務を進められる設計が素晴らしい点の一つだと感じており、AIの回答の根拠がファイルのどこにあるかをハイライトしたり、人が業務知識を補完して入力できる機能など、細かな工夫が数多くなされています。
現在の主な業務
「Ai Workforce」は「AIワークフロー」という機能により、多岐にわたる業務の効率化を実現しています。
「AIワークフロー」とは、Ai Workforceにアップロードされたファイルに対して特定の処理を行うためのアルゴリズムを組み合わせたものです。お客さまは業務で用いるファイルをAi Workforceにアップロードするだけで、AIワークフローによる処理が実行され、データの抽出や判別などを自動で行うことができます。
現在の私の業務では、主にお客様ごとにカスタマイズした「AIワークフロー」の構築や、そのための機能開発を行っています。
お客様の業務で実用可能なAIワークフローを作るためには、お客さまの業務を理解してLLMへの指示に落とし込むだけではなく、プロンプトエンジニアリングや前処理の追加・複数のLLMを使用するなど様々な手法を組み合わせる必要もあります。
そのため、お客さまごとにビジネスサイドのメンバーと数人体制のチームを組み、ミーティングにも参加して要件を整理しながらAIワークフローを構築しています。また、AIワークフローに組み込みたい処理がプロダクトになかった場合には自身で実装・開発して組み込んだりしています。
面白さ
LLMという技術に事業として本気で向き合う
LLMを使った取り組みやプロダクト自体は様々なものが日々生まれは消えていっているかと思います。一見できることは多いが、実際使うと質が微妙であったり、社内の検証で終わってしまったり、ChatGPTでええやんとなってしまったり、コストが高すぎたりなど、事業にすることを考えると実際には様々な点で頓挫してしまうことがあるかと思います。
Ai Workforce、AI・LLM事業部はLLMという技術の不確実さや限界・今後の進展・コスト・性質を前提としたプロダクト及び事業であり、それらの制約を踏まえた上で価値を出せると考えているメンバーが揃っており、日々頭を悩ませながら取り組んでいます。LLM特有の問題がいくつも出てきますが、それらを乗り越えて実現したユースケースは今までの技術では実現できなかったものであり、ビジネスの現場で価値を出しているのは非常に面白いのではないかと思います。
プロフェッショナルと働ける
AI・LLM事業部にはCTO経験者や執行役員経験者など、前職で役職に就いていた方が多く在籍しており、日々の議論を通じて多くの学びを得ることができます。ちょっとした雑談でも面白い話が聞けたりして、楽しいです。CTOのわいまつさんとカジュアルにプロダクトの未来の話ができるのもこの事業部の良さだなと感じています。
幅広い業界に触れられる
様々な業界のお客様の業務を実際の作業レベルで知ることができるのも魅力の一つです。AIワークフローに落とし込むためには、業務の詳細な手順を深く理解する必要があり、その中で様々な業界の知識や背景情報を知ることができる面白さがあります。その意味では、プロダクトを作るビジネスとしての面白さだけでなく、コンサルティング業的な面白さも感じられるかもしれません。
実装力を磨く機会
「Ai Workforce」のプロダクト開発においては開発物が多く（めっちゃ多い）、実力がまだ十分でなくても拾えるタスクがたくさんあります。特に、AIワークフローを構築するための機能は改善の余地が多く、その開発タスクを粛々と進めることで実装力を高められる機会があると感じています。また、開発のスピードも速いため、仕様の検討から開発・テストまでの流れを多く見ることができる点も勉強になります。自分はLayerXに入るまでTypeScriptをほとんど書いたことがなかったのですが開発タスクを拾っていく中で身についてきていると感じています。
難しい点
お客様自身も正解がわからないことがある
お客様のユースケースの正解が明確でないことも少なくありません。ワークフローの正解データとなるものが既存業務には存在しないため人手での作成が必要なこともあります。既存業務のアウトプットが不正確であったり、判断基準が経験に基づいており十分に言語化されていないものもあります。その際は理想のアウトプットやルールを今一度言語化するとどうなるか議論したり、人が判断を行う余地を入れるなど、固まった仕様を実装するだけでなく様々な変数を動かしながら作っていく必要があり、難しくもあり楽しくもあります。
LLMの不確実性のハンドリング
LLMのアウトプットは必ずしも安定しないことは身に染みて皆さん感じられているかと思います。AIワークフローにおいても、その不確実性に対処するために、どの部分を人間が行い、どの部分をLLMに任せ、どの部分を他の処理で行うのかを適切に切り分けながら設計しています。一見ルールベースでできるのではと思った処理も、LLMのアウトプットに依存して不正確になるケースもあり、試しながら構築していく姿勢が重要だと感じています。
例えば以下のように資料の特定の文章が階層構造のどこにあるかを判別するケースがありました。階層構造のフォーマットやタイトルの文字列・言語もバラバラの可能性があり、正規表現などでは難しいタスクです。
セクション1
A. タイトル
(1) サブタイトル1
...文章...
(2) サブタイトル2
...文章... <=この文章が、「セクション1のAの(2)」であることを判別したい
B. タイトル
単にLLMに該当箇所を聞くだけでは文章が長くなった際に階層を一つ抜いてしまったり、間違った階層を回答してしまったり、一番細かい階層まで回答してくれなかったりという状態でした。これに対し素朴には「LLMで構造を解析した出力を用いて入力資料の全文を構造化データに変換し、ルールベースで処理する」とよいのではと考えました。以下のようなデータを先に作って、文章の該当する階層をルールベースで特定するイメージです。
```
{
"title": "セクション1",
"sentence": ""
"sub_structure":
[
{
"title": "A. タイトル",
"sentence": "...文章...",
"sub_structure":
[
{"title": "(1) サブタイトル1", "sentence": "...文章...", "sub_structure": []},
{"title": "(2) サブタイトル2", "sentence": "...文章...", "sub_structure": []},
]
}
]
}
短い資料で試したところLLMのアウトプットを用いてこの構造をうまく作ることができていました。しかしながらこの方法も、LLMの出力のブレに依存して敏感に構造も変わってしまうため、実際の資料数サンプルで試すとうまくいかないケースが多かったです。
そこでLLMの出力に依存したルールベースのロジックで決めるのではなく、構造化データはあくまでLLMが回答するための参考情報とする方針に切り替えました。
LLMのタスクを２つ用意し、まず一つ目のタスクでは以下のように文章の構造をネストされた辞書として取り出す。
{"セクション1": {"A. タイトル": {"(1) サブタイトル1": {}, "(2) サブタイトル2": {}}}}
次のタスクでは入力資料と上記の辞書構造を文字列として渡し、文章の該当する階層を答えさせる。かなりシンプルですが、こちらの方法で安定して階層を正確に特定することができるようになりました。
このように、LLMの特性を探りつつ最適な解を見つけていくプロセスも面白さの一部であり、アルゴリズムに対する仮説がうまくいったときは嬉しいものです。
一方で、精度向上にかけられる時間も有限のため、効率的に取り組む必要があります。取り組む姿勢について以下で話していますのでよければご参考ください。
最後に
新卒で同様の環境は他に無いです。興味を持たれた学生の方には是非インターンをお勧めします。情報系や個人開発をしていたとかでなくとも、やっていただきたいことがたくさんあります。（自分は理学系の出身で研究でコードを少し書いていたくらいでした）
興味持たれた方は是非以下のリンクからお話しできますと嬉しいです！
