AI履歴書解析：正規表現、NLP、LLMの精度トレードオフ
履歴書解析の進化（とその足跡）
履歴書解析は本当にひどかったです。数十年間、最良のソリューションはSovrenのような企業を雇用してPDFで正規表現パターンを実行し、name、email、phone、experienceを抽出することでした。パターンはケースの60％で機能しました。予測可能な構造を持つ、よくフォーマットされた履歴書。異常値（型にはまらないレイアウト、国際形式、絵文字、テーブル、ヘッダー）は亀裂を通り抜けました。
このトレードオフは他に代替がないため受け入れられました。採用チームは解決策を構築しました：解析データの手動レビュー、バックエンドの品質チェック、電話番号の検証、および15％の候補者データが傷つけられるという悲しげな受け入れ。
その後、NLP（spaCy、StanfordNLP）はより良いことを約束しました。生テキストの名前付き実体認識、正規表現は不要です。それは機能しました。エンティティ識別タスクの場合。でも履歴書解析はエンティティ識別だけではありません。履歴書は意味論的なドキュメントです：「2020～2022」ヘッダーの下は単なる日付ではなく、それは仕事開始および終了日です。ニュース記事で訓練されたNLPモデルはそのコンテキストをキャプチャしません。
現在、LLM（Claude、GPT）は意味コンテキストを読むことができます。しかし、LLMは確率的です。構造がなければ、彼らは幻想フィールド、職務経歴書を発明し、時々経験セクション全体をスキップします。質問は：LLMを確実に解析させるにはどうしますか？
各アプローチが壊れる場所
正規表現（Sovren時代）：
- 壊れる： 非標準フォーマット（箇条書きではなく水平タイムライン）、異なるフォント内のセクションヘッダー、国際的な名前形式、PDF抽出アーティファクト（余分なスペース、壊れたラインブレーク）。
- 機能する： 形式がよく、単一列、最近の卒業生または企業の背景からの英語の履歴書。
- 問題： もろさ。Canvaからの1つのPDFがパターンを壊します。
NLP（spaCy、StanfordNLP）：
- 壊れる： 意味の理解。「2020～2022」NLPのような日付に見えます。しかし、なぜこの履歴書の上にあるのか？どの職務の下？開始/終了日またはスタンドアロン資格ですか？
- 機能する： ドキュメントが清潔でラベルが明確な場合のエンティティ抽出。
- 問題： セマンティックコンテキストなし。NLPモデルは「Python」が「スキル」の下と「Python コンサルティング会社」の「Python」が（ツール対会社名）とどのように異なるかを知りません。
構造なしのLLM：
- 壊れる： 幻想。「候補者の職務経歴を抽出して」は：
[{ title: "Senior Software Engineer", company: "Google", start: "2018", end: "2022" }, { title: "Principal Engineer", company: "Apple", start: "2015", end: "2018" }]— でも それらのうち1つだけが履歴書にあります。またはモデルのコンテキストウィンドウが切られたために完全なセクションを欠落させます。 - 機能する： オープンエンドの要約と解釈。
- 問題： ガードレールなし。モデルは、もっともらしい音の数据を発明できます。
構造化プロンプト付きLLM（Zod/JSONスキーマ）：
- 壊れる： 複雑なエッジケース（15個の職務を持つ候補者、混合英語/非英語の履歴書、異常な認定形式）。しかし、ほぼ幻想がありません。
- 機能する： スパムではない約95％の履歴書。
- 問題： 事前にスキーマ定義とプロンプト調整が必要です。
構造化プロンプトが実際に解決する内容
構造化プロンプト + 検証（Zod、JSONスキーマ）はLLMをガードレール内に留めるよう強制します：
履歴書データをこのスキーマに抽出します：
{
name: string,
email: string,
phone: string,
experience: [{ title, company, start, end, summary }],
skills: [string],
education: [{ degree, field, school, graduationYear }]
}
ルール：
- フィールドが欠落している場合、ファブリケーション値ではなくnullを返します。
- 日付はYYYYまたはYYYY-MM、ファジー文字列ではない必要があります。
- スキルは述べられたツール/言語であるべき、曖昧な形容詞ではなく。
スキーマ + 検証は幻想をキャッチします。モデルが履歴書リスト4つのジョブ時に6番目のジョブを発明した場合、バリデーターはそれにフラグを立てることができます。start: "early 2020"（有効ではない）を返す場合、スキーマはそれを拒否し、モデルに準拠するように求めます。
これはエラーを排除しません。LLMは「2020～2022」を「2020～2023」と誤読することがあります。しかし、正規表現とNLPができない*種類のエラーを防止します：セマンティック並び替え、文脈抽出、マルチドキュメント解析。
精度トレードオフ
| アプローチ | 精度* | 遅延 | コスト | 堅牢性 |
|---|---|---|---|---|
| 正規表現 | 60～70％ | <100ms | $0.01/履歴書（オンサイト） | もろい |
| NLP | 70～80％ | 200～500ms | $0.02/履歴書 | 中程度 |
| LLM（非構造化） | 80～90％ | 1～3s | $0.10～0.50/履歴書 | 幻想の傾向 |
| LLM + 構造 + 検証 | 92～98％ | 1～3s | $0.10～0.50/履歴書 | 堅牢 |
*精度 = 抽出フィールドが基本の履歴書と一致します（名前、メール、職務日付、スキル）。履歴書のフォーマットと複雑さによって異なります。
各アプローチをいつ使用するか
- 月に50履歴書のスタートアップを採用する： LLM + 構造。コストは無視できるほど、精度は候補者体験のために重要です。
- 月に10,000個の履歴書を持つエンタープライズATS： ハイブリッド。新しい取り込みのためのLLM、でも既存の従業員データベースに対して検証してください。LLMが失敗すると、人間のレビューにフォールバックします。
- 高ボリュームローライティッチソーシング： 独自のPDF解析スタック上の正規表現。20％エラーを受け入れ、下流フィルターを使用してキャッチします。
- 準拠/法律： 自動抽出のみに依存しません。アーカイブの前に常に人間が検証します。
ClarityHireが履歴書解析を処理する方法
候補者が履歴書をアップロードまたは貼り付けると、ClarityHireはClaudeを使用して構造化データを抽出します + Zod検証。抽出には、名前、連絡先情報、職務経歴、教育、スキルが含まれます。その後、候補者は抽出データをレビューして修正してからパイプラインに進みます。LLMの出力をリスク軽減するための人間ループ。
このアプローチは、精度と候補者体験のためのコスト（APIコール）をトレードオフします。候補者は解析データを見て、評価される前にそれが正しいことを知ります。また、「後で誤ったデータを持っている」驚きを防ぎます。オファーレターが名前を綴り間違えるか、HRシステムが彼らが働いていなかった場所を示す場合。