LLMを活用したアノテーション基準書作成支援
はじめに
シェルパ・アンド・カンパニー株式会社 AI事業部の赤部です。
今回は、社内で開発・使用しているアノテーション基準書作成支援ツールを紹介します。
シェルパでは、企業が投資家向けに開示している非財務情報（ESG情報）を分析し、開示内容の改善支援を行なうSmartESGというサービスを開発しています。ESGはEnvironment (環境), Social (社会), Governance (企業統治) の3つの柱から成りますが、各柱の項目は多岐に渡ります。例えば、一言で「環境」といっても、生物多様性、温室効果ガス、廃棄物などの分野がありますし、それぞれ目標はどうなのか、どの程度実現しているのかなど、投資家が知りたい情報は多様です。SmartESGではそれらを網羅し、顧客企業では何が発信できていて、何が発信できていないのかを可視化しています。
基準の明確化の必要性
どのような予測タスクにも言えることですが、あるラベルが与えられたとき、人によってそのラベルの解釈が異なるようなことがあっては困ります。ESGの分野で言えば、例えば「大気汚染物質の排出削減」というラベルが与えられたとき、前年からの削減率を記載していれば十分なのか、それとも現在の排出量も記載していなければならないのか、といった基準は明確でなければなりません。
シェルパでは、社内のESGの専門家がESG項目の定義やアノテーションの基準書を作成しているのですが、人間が行なう以上、どうしても考慮から漏れてしまうものがあります。そのような漏れがあると、例えばその基準に従ってデータセットを作ったときに、考慮されていなかった基準を確認するためにアノテーション作業が途中で止まってしまったり、人によって異なる基準でアノテーションしてデータセットの品質が低下するなどの問題が発生してしまいます。また、専門家の人数には限りがあるため、大規模なデータセットを作る場合はどうしても非専門家の力も借りる必要がありますが、専門家が作った基準書を非専門家が容易に理解できるとも限りません。
アノテーション基準書のLLMによる評価
LLMを用いると、プロンプトで与えた指示に従った出力を得ることができます。そこで、LLMを非専門家のアノテーターと捉え、アノテーション基準書に基づいたLLMによる予測を行い、その結果に基づいてアノテーション基準書を修正することで、基準書における考慮漏れを防いだり、非専門家であっても容易に理解できる基準書を作れないかと考えました。
これを実現するためには、アノテーション基準書といくつかの事例をLLMに入力し、期待される予測結果と実際の予測結果を比較できるツールが必要です。アノテーション基準書を作成するのはESGの専門家であって、必ずしもITの専門家ではないため、コマンドラインを叩くようなツールを提供することは現実的ではありません。
弊社では以前から基準書の管理にGitHubを利用しており、GitHubであればITの専門家でなくても少ない学習コストで利用できることを確認しています。そのため、GitHubのPull Requestのコメント欄に所定の形式のコメントを投稿することで予測を実行できるようにしました。
先に完成形のスクリーンショットを示します。
ここで登場する LAND_MANAGEMENT とは、企業が所有する土地の管理に関する情報が資料に記載されているかどうかを表すESG項目です。Expected 欄は期待される予測結果、Actual 欄は実際の予測結果が示されています。
使い方は以下のとおりです。
ESGの専門家がGitHub上で各ラベルのアノテーション基準書を作成し、同時に、そのラベルの該当例と非該当例を用意する。
Pull Requestを作成し、そのコメント欄に /check [ラベル名] と入力する。
Pull Requestされているアノテーション基準書に従って該当例と非該当例の予測が行われ、同時にその理由が出力される。
ESGの専門家は予測結果と期待される結果の差異に基づいて定義の修正を行なう。
Markdownを用いた基準書フォーマット
アノテーション基準書に書かれている文言を機械的に読み取るには、基準書を所定のフォーマットに従って作成する必要があります。一方で、技術者でなくても記述できるフォーマットである必要があります。
そこで、Markdownをベースとしつつ、以下の文書構造を決めました。
アノテーション基準書の例です。
---
title: LAND_MANAGEMENT
caption: 土地の所有・管理
---
## 判断基準
土地の所有または管理に関する記載がある。以下は具体例である。
...（略）...
## 該当例
### 該当例1
**該当理由:** 組織が所有している森林の面積についての記載があるため該当。
### 該当例2
> 当社は...適切に処理してまいります。
**該当理由:** 組織が所有・管理している土地における事業撤退に伴い（跡地）、汚染土壌について適切に処理・修復していく旨の記載があるため該当。
## 非該当例
### 非該当例1
**非該当理由:** 本レポート発行にあたりFSC認証紙を使用しているとの記載はあるが、組織が所有・管理している土地に対するFSC認証取得率またはFSC取得割合が記載されていないため非該当。
ここで「該当理由」「非該当理由」という項目がありますが、これらは人間向けの参考情報として載せているものであり、あくまで「判断基準」の欄に記載された情報に基づいて正しく予測できるかを確認します。
アーキテクチャ
上図は全体のアーキテクチャです。
Cloud Run の設定
Cloud Run には予測用のAPIを持ったWebアプリケーションを立てておき、専用のサービスアカウントに対してアクセス権を付与しておきます。認証には Workload Identity Pool を使用し、GitHub の特定のリポジトリからトークンを事前に保存しておくことなくアクセスできるようにします。 GitHub Actions 側では google-github-actions/auth を使用し、都度 ID token を取得するようにします。設定方法の詳細は以下の記事が詳しいです。
GitHub Actions の設定
Pull Requestのコメント欄で /check から始まるコメントが入力された際に、 GitHub Actions が実行されるように設定します。 /check の検出には slash-command-action を使用しています。
slash-command-action は /check 以外の通常のコメントが入力された際にエラーとなるのですが、エラーが通知される設定にしていると煩いため、 slash-command-action に continue-on-error: true を設定し、以降のステップでは if: steps.command.outputs.command-name として通常のコメントに対してスキップされるようにしています。
予測サービスの実装
予測サービスは、
アノテーション基準書をAPIで受け取る
Markdownをパースして事前に用意されたテンプレートに埋め込んでプロンプトを合成する
Geminiにプロンプトを入力し、結果を受け取る
という単純なものです。弊社では様々なサービスを既にRustで実装していることもあって知見があるので、本サービスもRustで実装しました。Web APIの実装には axum を使用し、Markdownのパースには markdown-rs を使用しています。プロンプトは後で容易に修正できるように、テンプレートファイルとして別に用意しておき、handlebars-rust でパースして基準書の文言を挿入しています。
予測は2段階で行なうようにしています。まず1段目では、基準書に従って与えられた文書の説明文を出力させます。2段目では、1段目で得られた説明文から該当・非該当の2値の出力をさせます。1段目で先に該当・非該当といった結論を出力させてしまうと、以降の説明がそれに引っ張られてしまうため、なるべく結論が出力されないようにプロンプトを組んでいます。
以下にテンプレートの例を示します。 glossary の箇所には、基準書内で用いられている専門用語の説明文を用語集から持ってきて挿入しています。
あなたは企業活動の環境への影響を分析するアナリストです。
今回の業務では、ある企業が発行する文書の「{{caption}}」について説明を行います。
「{{caption}}」の定義は次のとおりです:
=====
{{definition}}
=====
{{glossary}}
以下にユーザから文書が与えられます。その文書の「{{caption}}」に関する記述を簡潔に説明してください。
あなたは企業活動の環境への影響を分析するアナリストです。
今回の業務では、「{{caption}}」について、ある企業の発行する文書に該当するかチェックを行います。
「{{caption}}」の定義は次のとおりです:
=====
{{definition}}
=====
{{glossary}}
以下に、ある文書の「{{caption}}」についての説明が与えられます。定義に該当するならYES、該当しなければNOと出力してください。
本ツール導入の成果
弊社では、前述のように大量の分野からなるESG項目の基準書作成やデータセットの作成を行っており、データセットの作成を外部のアノテーション会社に依頼することもあります。以前は基準が明確でないためにアノテーションのやり直しや確認のためのコミュニケーションが頻発し、その度に基準書を修正するということが発生していました。また、作成した基準がLLMで期待通りに解釈できるかを確認するために、技術者が動いていました。
しかし、本ツールの導入によって、ESGの専門家と技術者の双方に大きな恩恵がありました。まず、実際にツールを使用しているESGの専門家のコメントを紹介します。
基準が曖昧だったり分かりにくい場合は、期待と異なる予測結果が返されるので、修正箇所の特定が容易に行える。
専門知識があると、説明を忘れてしまったり、説明が甘くなってしまう場合がある。また、1人で定義を作成していると、1つの流れに凝り固まってしまう場合がある。しかし、機械による客観的な判断が入ることで、1人では気付かなかった問題点に気付くことができる。
人ではなく機械がコメントをするので、遠慮せずに何度でも気軽にコメントを求めることができる。
人間相手にコメントを求めていると、その人間がだんだん学習してしまい評価がブレてしまうことが懸念される。しかし、機械であればブレずに一定の基準でコメントを返すことが期待できる。
定義に入れるべき内容だけでなく、省くべき内容も明確になる。
また技術者目線では、基準書作成における単純なサポートの業務は大幅に減り、手法の提案や評価といった、より本質的な業務に専念できるようになりました。
まとめ
本記事では、社内で開発・使用しているアノテーション基準書作成支援ツールを紹介しました。アノテーション基準の作成やデータセットの作成は、弊社に限らず多くの企業や研究機関で非常に重要な業務になっていると思います。そのような仕事をしている方にとって、本記事が少しでも参考になればと思います。
シェルパ・アンド・カンパニー株式会社では、自然言語処理・機械学習のエンジニアや、インターンシップの募集を行っています。応募をお待ちしております。
次は、デザイナーの大澤さんです！お楽しみに⛰️🧗