原料商 TDS / MSDS 一键 AI 解析

4 周 里我们做了这些

背景

客户的销售业务高度依赖"对原料规格的快速响应"。一个化妆品品牌方采购想要"皮肤渗透率 < 10% 的水溶性透明质酸钠 ≥ 200 万道尔顿"，销售员要立刻给出符合的产品 + 规格 + 报价。 现状：销售员收到询问 → 翻 SharePoint 找候选 PDF → 一份份打开看 → 找到 3-5 个候选 → 复制粘贴到邮件 → 发出。整个过程 25-40 分钟。当客户同时问 5 家原料商时，谁回得快谁就赢。 更深的推力：**NMPA 88+ 新规已落地**——化妆品原料商以前不规范的 COA / MSDS / SPEC / TDS / 生产工艺 / 质量规格 / 组分表 / 检测报告 / 毒理资料，现在全部统一纳入数字化管理。复配原料报送码取消后，每个复配原料档案要拆解到所有单成分 INCI 各自的报送码 + 限值 + 安全资料。客户意识到再用 SharePoint 文件夹根本撑不住——不是销售效率问题，是合规生存问题。

我们做了什么

总工期 4 周。 第 1 周｜PDF 类型梳理 + 字段定义。588 个 PDF 不是单一格式：TDS（技术规格）/ MSDS（安全数据）/ Spec Sheet（产品手册）/ Test Report（检测报告）4 类。每类的关键字段不同：TDS 看物化指标 + 推荐用量；MSDS 看危险品分类 + 储存条件；Spec Sheet 看 INCI / 包装规格；Test Report 看检测项目 / 结果。最终定 38 个字段（覆盖 4 类共有 + 类型特有），用 Pydantic Schema 定义。 第 2 周｜Gemini Vision 批量提取。用 gemini_lite_model（lite 版本能力够用且成本省 70%），每个 PDF 拆 page-by-page 给 Vision，prompt 严格要求 JSON 输出 + 字段缺失返回 null（绝不允许编造）。批量并发 8 个 LLM 请求。588 个 PDF 实际跑了 18 小时（含失败重试）。同步写入 fct_llm_call_log + LLMLOG 文件。 第 3 周｜INCI 归一 + Python 正则二次验证。提取的 INCI 名走 match_names 函数对齐 bse_inci 主数据，命中率 89%。剩 11% 进人工 review。Python 正则做边界 case：① 浓度字段 "≤ 1.5%" / "≤1.5%" / "<= 1.5wt%" 多种写法标准化为 1.5；② 分子量字段单位识别（道尔顿 / kDa / kg/mol）；③ pH 范围识别。这一步把准确率从 84% 拉到 92%。 第 4 周｜PIM 前端 + 集成到客户 SharePoint。一个简单的搜索界面：物化指标范围 + INCI + 用量 + 储存条件 → 返回符合的产品列表 + 原 PDF 链接。集成到客户 SharePoint 的 SSO 体系（Azure AD），销售员单点登录直接用。

数据结果

上线 6 个月： · 588 PDF 全部入库，38 字段平均准确率 92% · 销售员对客户询价响应时间从 25-40 分钟 → 90 秒 · 月底人工抄数据到 Excel 的工作彻底取消（直接 PIM 导出） · 上线第 3 个月开始，新到的 PDF 通过 SharePoint webhook 自动触发解析（< 5 分钟入库） · 客户销售签单率提升 14%（响应快带来的直接转化） · 客户续签第二年合同 + 加做"客户询价历史分析"模块

复盘 · 哪里做得不够

Vision 模型偶尔会把 % 当成数字看错（"5%" 看成 "50"），头两周这个问题导致 6 份 PDF 数据严重错误，被客户发现差点丢信任。后加了 Python 正则规则强制要求所有数字字段必须能在 PDF 文本里找到原始字符串，否则标 "需要人工核对"。教训：AI 提取的真相是 90% 准确率不够，要做到生产级必须把剩下 10% 用 Python 规则兜回来；同时输出"信心度"标注让客户知道哪些字段不能盲信。