匹配度永远是85%？JD与简历匹配AI，我重做了三次才明白错在哪
给独立开发者和小团队提个醒：简历与JD匹配，是求职平台最容易被低估的AI需求。看起来就是“两段文本算个相似度”，但如果你真这么做了，大概率会在三个月后推倒重来。下面先讲我们踩过的三个坑，再给出现在跑得稳的方案。
一、三个失败样本
样本一：一把embedding打天下。 第一版我们直接把JD和简历全文各做一次向量编码，算余弦相似度，返回85%、72%这样的分数。上线两周，用户反馈集中在两点：所有匹配度都挤在75%-90%之间，没有区分度；分数无法解释，候选人问“为什么给我推荐这个岗位”，运营答不上来。embedding对“精通Java”和“熟悉Java”这种程度副词、对“3年经验要求 vs 5年经验履历”这种数值比较，几乎不敏感。
样本二：让大模型读全文自由发挥。 第二版换成prompt直接把JD和简历塞给大模型，让它输出匹配分和理由。结果每次打分不一致——同一份简历隔天重跑，分数能差15分。更麻烦的是，几百份简历批量跑，token成本直接失控，长简历经常超出上下文被截断，模型只看到了候选人的教育背景就下了结论。
样本三：结构化字段用规则、描述文本用模型，各管各的。 第三版意识到了问题，把薪资、城市、年限这类硬字段用规则过滤，把职责描述交给模型。思路对了，但实现上每类字段接了不同的模型和供应商——一个embedding服务、两家大模型API、一个本地小模型，密钥散落在代码各处，某家供应商限流时整个匹配链路挂掉，排查了两小时才发现是欠费。
二、正确的路径：三层匹配架构
痛定思痛后，我们把方案定为“规则层 → 结构化抽取层 → 语义匹配层”，各层职责单一、可独立测试：
第一层：硬性规则过滤。 城市、薪资区间、学历、工作年限，这些二值判断根本不需要AI，规则引擎处理，快、免费、百分百可解释。这一层能砍掉60%以上的无效匹配请求。
第二层：结构化抽取。 用大模型把JD和简历各抽取成统一Schema的JSON：技能列表（带熟练度等级）、行业标签、职责要点。抽取是比匹配稳定得多的任务，配合输出格式约束和低温度参数，一致性很好。这一步还顺便解决了长文本问题——简历只抽取一次入库，不用每次匹配都读全文。
第三层：维度级语义匹配。 匹配不再产生一个总分，而是按“技能匹配、经验相关性、行业契合”三个维度分别打分，最后加权合成。每个维度有独立的分项说明，用户能看到“为什么”，运营能调整权重应对不同岗位类型。
核心流程清单如下：
1. JD入库 → 规则字段解析 + LLM结构化抽取 → 存入JD索引
2. 简历上传/更新 → 同样抽取为结构化JSON → 存入简历库
3. 匹配触发（用户搜索 / 岗位推荐）：
a. 规则层：城市/薪资/年限硬过滤 → 剩余候选集
b. 召回层：embedding做粗排（注意：只用于召回排序，不产出对用户可见的分数）
c. 精排层：LLM维度级打分（技能/经验/行业）+ 简短理由
d. 加权合成总分 + 降级策略：LLM超时则只返回召回排序结果并标注"初步排序"
4. 结果落库，记录每次打分的模型版本，便于后续回归验证关键实现要点，对应前面三个坑：
- embedding只做召回，不做打分。 用户看到的分数全部来自第三层的维度化打分，有区分度、可解释。
- 抽取与匹配分离，简历只抽一次。 匹配时模型读的是几百token的结构化JSON而不是几千token的原文，成本降了一个数量级，批量匹配才在商业上成立。
- 统一走AI API网关。 这是我们从样本三学到的最贵的一课。
三、为什么统一AI网关能显著降低维护成本
小团队最容易忽视的一点：AI应用的维护成本大头不在模型调用本身，而在“多供应商管理”上。没有统一网关时的典型状态是——三四个供应商的SDK版本各自升级、密钥硬编码在不同服务里、计费账单分散在几个后台、某家限流只能在用户报障后才发现。
接入统一网关后：
- 一套密钥、一套调用方式。 抽取用便宜模型、精排用旗舰模型，只是请求里换一个模型名，不需要为每家供应商写适配代码。
- 故障切换不用改代码。 某个模型限流或宕机，网关层配置降级路由，匹配链路自动切到备用模型，不需要半夜改代码发版。
- 用量统一可观测。 每天多少次抽取、多少次精排、花了多少钱、错误率多少，一个后台看全。对一个按匹配次数计费的产品来说，成本可核算就是活下来的前提。
- 供应商变更的隔离。 今天某家模型涨价或停服，你换供应商的动作是改一行配置，而不是重写一个模块。
粗算下来，我们接入网关后花在“维护AI调用”上的时间从每月两三天降到几乎为零——对三人的小团队，这个差别决定你有没有时间做真正的产品迭代。
四、落地建议
如果你正准备做类似功能，建议的推进顺序是：先只用规则层上线，验证用户是否真的需要AI匹配（很多时候规则已经解决80%的问题）；再加结构化抽取；最后加维度化精排。每一步都可回退、可度量。千万别像我第一版那样，上来就追求“智能匹配”的完整形态。
匹配这件事，用户要的从来不是一个看起来很自信的百分比，而是“这个岗位为什么适合我”的可解释答案。想清楚这一点，架构自然就清晰了。
如果你准备动手，可以试试这个统一AI API网关，注册即用：
https://api.thistoken.ai/register
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。