AI901-Foundry#195-2
注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。
前提
ある人材エージェンシーが、応募者から届く履歴書 (PDF / Word / 画像、月 3,000 件、レイアウトはほぼ自由でテンプレート化されていない) から「氏名 / メール / 電話 / 学歴 / 職歴 / スキル」を構造化抽出し、ATS (Applicant Tracking System) に取り込みたいと考えています。要件は構造化抽出精度、Privacy and security (氏名・電話の慎重な取扱)、Foundry の生成 AI との連携可能性です。
解決策
履歴書をすべて Document Intelligence の prebuilt-invoice モデルに送り、VendorName を「氏名」、InvoiceTotal を「年収」と読み替えて ATS に取り込む運用とします。PII 保護や custom 訓練は行いません。
この解決策は目的を満たしますか?
解説
【判定: いいえ】の理由
本提案は prebuilt モデルの目的外利用で、要件のすべてを満たせません。prebuilt-invoice は請求書フォーマット向けに事前学習されたモデルで、履歴書の「氏名 / 学歴 / 職歴 / スキル」のような項目は学習対象に含まれません。VendorName / InvoiceTotal フィールドは請求書ベンダー名 / 合計金額を抽出する目的で訓練されており、これを履歴書の項目に「読み替える」運用は Microsoft Learn の prebuilt モデル仕様と完全に矛盾し、抽出精度はほぼゼロに近い結果になります。さらに PII 保護を行わない設計は応募者の個人情報保護を完全に放棄しており、GDPR / 個人情報保護法 / 採用関連の倫理ガイドラインに違反する重大インシデント リスクを孕みます。custom 訓練を行わないため、自由レイアウトの履歴書に対応する手段が皆無で、立ち上げ前に運用が破綻します。Microsoft Learn は履歴書のような自由レイアウト文書に対しては general document model または custom neural の利用を推奨しており、本提案は Document Intelligence の使い方を根本的に誤解した設計です。
【「はい」が違う理由】
抽出精度 / Privacy and security / モデルの適合性のいずれも要件を満たせず、本シナリオの設計として失敗です。
本提案は prebuilt モデルの目的外利用で、要件のすべてを満たせません。prebuilt-invoice は請求書フォーマット向けに事前学習されたモデルで、履歴書の「氏名 / 学歴 / 職歴 / スキル」のような項目は学習対象に含まれません。VendorName / InvoiceTotal フィールドは請求書ベンダー名 / 合計金額を抽出する目的で訓練されており、これを履歴書の項目に「読み替える」運用は Microsoft Learn の prebuilt モデル仕様と完全に矛盾し、抽出精度はほぼゼロに近い結果になります。さらに PII 保護を行わない設計は応募者の個人情報保護を完全に放棄しており、GDPR / 個人情報保護法 / 採用関連の倫理ガイドラインに違反する重大インシデント リスクを孕みます。custom 訓練を行わないため、自由レイアウトの履歴書に対応する手段が皆無で、立ち上げ前に運用が破綻します。Microsoft Learn は履歴書のような自由レイアウト文書に対しては general document model または custom neural の利用を推奨しており、本提案は Document Intelligence の使い方を根本的に誤解した設計です。
【「はい」が違う理由】
抽出精度 / Privacy and security / モデルの適合性のいずれも要件を満たせず、本シナリオの設計として失敗です。
コメント