Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

HR 入职文档处理流程:从使用 Dify Workflow 进行 PDF 分析到 HR 系统集成的实施指南

简介

在新员工入职过程中,人力资源部门需要处理大量的文件。简历、居民记录、个人编号通知卡、银行账户结单、养老金笔记本副本、各种誓言——从这些文件中准确提取必要信息并将其登记到人力资源系统中,每人需要几十分钟到一个小时。 4月份的大批量招聘期间,这项工作密集发生,给人力资源部门造成了瓶颈。

在本文中,我们将介绍如何使用 Dify 的 Workflow 设计和实现一个端到端管道,自动从 PDF/图像格式的加入文档中提取信息,并经过验证和人工验证后将其注册到人力资源系统中。


背景和问题

###入公司办理文件实况

作业详情
文件多样性文本 PDF、扫描 PDF 和照片图像的混合
手写信息的存在地址变更通知和银行账户通知表格包含手写信息
转录错误的风险手动转录可能会导致姓名汉字、帐号和地址错误
个人信息保密处理マイナンバー、帐户信息等存在安全限制。
旺季集中4月份将同时聘用数十名应届毕业生加入公司
文件不完整/不充分如果提交的文件有任何缺陷,您必须将其退回并重新提交。

流水线的优点

项目手工加工Dify管道
每人处理时间30-60 分钟5-10 分钟(包括人工确认)
转录错误率2-5%低于0.5%(经人工验证)
检测文档缺陷的时机输入期间检测到上传后立即自动检测
流程追溯纸质记录所有步骤

整体架构

flowchart TD
    A[書類アップロード<br>PDF / 画像] --> B[ファイル振分けノード]
    B --> C{ファイル形式判定}
    C -->|テキスト PDF| D[テキスト抽出]
    C -->|スキャン PDF / 画像| E[VLM / OCR 処理]
    D --> F[パラメータ抽出ノード<br>構造化 JSON 出力]
    E --> F
    F --> G[フィールド検証ノード]
    G --> H{検証結果}
    H -->|全項目 OK| I[Human-in-the-Loop<br>最終確認]
    H -->|不備あり| J[不備通知<br>再提出依頼]
    I --> K{承認?}
    K -->|Yes| L[人事システム連携<br>HTTP Request]
    K -->|修正| M[修正入力]
    M --> G
    L --> N[処理完了・ログ記録]

节点设计细节

节点1:文件接收(起始节点)

Dify Workflow 的起始节点接受以下输入。

变量名类型必填描述
employee_name文字是的未来雇员姓名
employee_id文字是的员工编号(接受临时编号)
entry_date日期是的预计加入日期
documents文件[]是的连接文档(多个文件)
document_types文字没有每个文件的文档类型(逗号分隔)

节点2:文件格式确定/分发

分发每个上传文件的处理方法。

判定ロジック:
- 拡張子が .pdf でテキスト抽出可能 → テキスト PDF ルート
- 拡張子が .pdf でテキスト抽出不可 → スキャン PDF ルート(VLM)
- 拡張子が .jpg / .png / .heic → 画像ルート(VLM)

节点3:文本提取

对于文本 PDF

使用 PDF 解析器直接提取文本。成本最低,精度最高。

用于扫描 PDF/图像

使用 Dify 的 Vision 兼容模型(GPT-4o、Claude 等)直接从图像中提取结构化数据。使用VLM直接提取相对于传统OCR管道(图像→字符识别→后处理)具有以下优势:

项目传统OCRVLM直接提取
支持表格格式需要单独的结构分析理解并提取表结构
手写字符准确度显着降低可以根据上下文进行估计
复合布局需要布局分析直观地理解和处理
存在印章印记/身份证照片识别错误的原因可以确定哪些因素应该被忽略

节点4:参数提取(LLM节点)

从提取的文本或图像中输出结构化 JSON。

System Prompt:
あなたは HR 書類処理の専門アシスタントです。
以下の入社書類から、指定されたフィールドを正確に抽出してください。

【抽出フィールド】
{
  "personal_info": {
    "full_name_kanji": "氏名(漢字)",
    "full_name_kana": "氏名(カタカナ)",
    "date_of_birth": "生年月日(YYYY-MM-DD)",
    "gender": "性別",
    "nationality": "国籍"
  },
  "address": {
    "postal_code": "郵便番号(XXX-XXXX)",
    "prefecture": "都道府県",
    "city": "市区町村",
    "street": "番地以降",
    "building": "建物名・部屋番号"
  },
  "contact": {
    "phone": "電話番号",
    "email": "メールアドレス",
    "emergency_contact_name": "緊急連絡先氏名",
    "emergency_contact_phone": "緊急連絡先電話番号",
    "emergency_contact_relationship": "続柄"
  },
  "bank_account": {
    "bank_name": "銀行名",
    "branch_name": "支店名",
    "account_type": "口座種別(普通/当座)",
    "account_number": "口座番号",
    "account_holder": "口座名義(カタカナ)"
  },
  "tax_social": {
    "my_number": "マイナンバー(12桁)",
    "pension_number": "基礎年金番号",
    "health_insurance_number": "健康保険証番号"
  }
}

【重要ルール】
1. 書類に記載がないフィールドは null を設定すること
2. 読み取りに自信がないフィールドは
   {"value": "読み取り値", "confidence": "low", "note": "理由"}
   の形式で出力すること
3. マイナンバーは12桁の数字であること。桁数が合わない場合は
   confidence を "low" に設定すること
4. 絶対に推測や補完を行わないこと

valueconfidence(高/中/低)、source_file 分配给每个字段。低置信度的字段被设计为在随后的人机循环中由人类检查。

节点 5:字段验证

对提取的数据执行基于规则的验证。

検証ルール:
1. 郵便番号: XXX-XXXX 形式であること
2. 電話番号: 0X-XXXX-XXXX または 0XX-XXX-XXXX 形式
3. メールアドレス: 有効な形式であること
4. マイナンバー: 12桁の数字であること(※ 重要:原则上不应入 LLM —— 详见后面"マイナンバー处理"章节)
5. 口座番号: 通常 7 桁の数字(**ゆうちょ銀行は「記号 5 桁 - 番号 8 桁」形式で異なる**;ネット銀行も口座番号桁数が異なる場合あり——銀行コードに基づき分岐検証する)
6. 生年月日: **雇用形態に応じた最低就業年齢を満たすこと**(正社員は通常 18 歳以上、アルバイト・高卒採用は中学卒業後の 4 月以降であれば 15 歳から可——労働基準法第 56 条)
7. 必須フィールド: 氏名、住所、銀行口座が全て入力済みであること

Dify Workflow 允许您使用代码节点 (Python/JavaScript) 实现这些验证。

# コードノードでの検証例
import re
import json

def validate_fields(data):
    errors = []
    warnings = []
    
    # 郵便番号チェック
    postal = data.get("address", {}).get("postal_code", "")
    if postal and not re.match(r"^\d{3}-\d{4}$", postal):
        errors.append({
            "field": "address.postal_code",
            "value": postal,
            "message": "郵便番号の形式が不正です(XXX-XXXX)"
        })
    
    # マイナンバーチェック
    my_number = data.get("tax_social", {}).get("my_number", "")
    if isinstance(my_number, dict):
        # confidence が low の場合
        warnings.append({
            "field": "tax_social.my_number",
            "value": my_number.get("value"),
            "message": my_number.get("note"),
            "requires_human_review": True
        })
    elif my_number and not re.match(r"^\d{12}$", str(my_number)):
        errors.append({
            "field": "tax_social.my_number",
            "value": my_number,
            "message": "マイナンバーは12桁の数字である必要があります"
        })
    
    # 口座番号チェック
    account = data.get("bank_account", {}).get("account_number", "")
    if account and not re.match(r"^\d{7}$", str(account)):
        errors.append({
            "field": "bank_account.account_number",
            "value": account,
            "message": "口座番号は7桁の数字である必要があります"
        })
    
    return {
        "is_valid": len(errors) == 0,
        "errors": errors,
        "warnings": warnings,
        "requires_human_review": len(warnings) > 0
    }

节点 6:人在环

在以下情况下请求人力资源代表确认:

触发条件严重性回应
字段 confidence: low 存在突出显示该字段并请求确认
存在验证错误显示错误详细信息并请求更正
必填字段为空请求重新提交丢失的文件
提取マイナンバー/帐号必填机密信息必须始终由人工进行最终检查
姓名中的汉字和假名不匹配中等检查拼写是否正确
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
入社書類処理: 確認が必要です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■ 対象者: 山田 太郎(社員番号: EMP-2026-0501)
■ 入社予定日: 2026-05-01

■ 要確認項目:

  ⚠ マイナンバー: 123456789012
    → スキャン品質が低く、3桁目が不明確です。
       原本を確認してください。

  ⚠ 基礎年金番号: 未検出
    → 年金手帳のコピーが提出されていない可能性があります。

■ 抽出結果(全項目):
  [構造化データを表示]

■ アクション:
  [承認] [修正して承認] [書類再提出依頼]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

###节点7:人力资源系统联动(HTTP Request节点)

将经过验证的数据从 Dify Workflow 的 HTTP 请求节点发送到 HR 系统的 API。由于结构化 JSON 是按原样 POST 的,因此字段映射设计很重要。

链接系统的示例:

系统合作方式报名详情
人力资源大师(COMPANY等)休息 API基本信息/地址/家庭信息
薪资系统(免费人事劳动事务等)休息 API银行账户/社保信息
考勤系统(KING OF TIME等)休息 API员工人数/部门
活动目录 / IdPLDAP / SCIM账户自动创建
Google Workspace / Microsoft 365管理API电子邮件地址/小组分配

安全设计

个人信息的处理

就业文件包含需要特别严格管理的个人信息,例如マイナンバー和银行帐户信息。

⚠️ 法律警告 — マイナンバー处理

マイナンバーは番号法で「特定個人情報」として定義され、漏えい時には刑事罰を含む厳しい処分が科される。本書では以下を強く推奨

  1. 原则不入 LLM:マイナンバー字段在 OCR / VLM 抽出后必须由人事担当が手入力で確認不要将含マイナンバー的画像 / 文本投入云端 LLM API(哪怕“学習しない“設定であっても)
  2. 如确需 LLM 辅助:仅限 self-hosted Dify + 国内 region + 本地 VLM(不出境)+ 强制マスキング(中间 8 桁置换为 ✕)+ 全程監査ログ
  3. プロンプトに「绝对不要推测」だけでは合规要件を満たさない —— 上記 1 / 2 のいずれかが必要

详见経済産業省「マイナンバーガイドライン」+ 個人情報保護委員会「特定個人情報の適正な取扱いに関するガイドライン」。

对策实施方法
通讯加密Dify 与各系统之间的 HTTPS / TLS 1.3
临时数据存储的限制完成工作流程执行后自动删除临时文件
访问控制使用 Dify 工作区权限限制处理人员
审核日志所有操作(上传、提取、确认、注册)均记录在日志中
本地部署如果保密性高,在封闭网络上运行 Dify 自托管版本
マイナンバー的特殊管理优先:人事担当が手入力;如必须 OCR 抽出,仅 self-hosted + マスキング + 監査ログ三件套同时满足

如果由于个人信息保护的原因无法将マイナンバー和帐户信息发送到外部云端,您可以通过在封闭网络上运行 Dify 自托管版本(Docker Compose)并与本地 VLM 结合来完全避免向外部发送数据。


错误处理

可能出现的错误及对策

错误检测方法纠正措施
PDF 已加密解析文件时出错请求解密
图像分辨率低VLM信心普遍较低请求重考/重新扫描
意外的文档类型文档类型确定中“未知”升级至人力资源
人力资源系统API错误通过 HTTP 响应代码检测重试 3 次后存储在保留队列中
提取数据不一致验证节点中检测到不一致发送以供人工确认

实施步骤

期间内容
第一阶段2 周仅用于简历的 PoC。验证文本提取→JSON转换的准确性。
第二阶段2-4 周扩大文件种类(账户通知书、在留卡等)。添加了对 VLM 扫描的支持。
第三阶段1-2个月实施验证节点/人在环。 API与人力资源系统集成。
第四阶段继续开发批处理。监控和提高提取精度。

总结

HR入职文档处理流程的核心不是“AI能读PDF吗?”,而是以可追溯、可重复的方式自动化分析、提取、验证、人工验证、系统注册等一系列流程。 Dify Workflow 提供了一个平台,允许您直观地设计和操作以下所有内容:文件输入接收、使用 VLM/OCR 提取信息、使用代码节点进行验证、使用人机交互进行人工验证以及使用 HTTP 请求节点进行外部系统链接。

以下三个设计原则尤为重要。

  1. 结构化输出:以字段JSON形式输出,而不是自然文本,并分配confidencesource
  2. 需要人工验证:高度机密字段(マイナンバー、帐号)必须始终由人工进行最终检查。
  3. 安全设计:考虑采用自托管版本,并根据个人信息的处理方式限制数据的临时存储。

通过遵循这些原则,您可以创建一个确保准确性和安全性的管道,同时显着减轻人力资源部门在繁忙时期的文档处理负担。