题目重点：先建立 job category/attribute 本体，再从成员资料做层级多标签预测，并避免把 LR 的二分类形式误作能力边界。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 类别及子属性可多标签：一人可以兼具 Backend 与 Infra；预测要输出证据、置信度和拒答状态。题目没说明是否必须唯一主类别。
- 资料只用有权限的字段，类别本体版本化；新职位/技能不断出现，不能让固定闭集模型永久拒绝更新。
解题路线
- 先由招聘/产品领域定义 category→attribute taxonomy、互斥或可共存关系，以及标注准则；不同层级类别需要稳定 ID、别名和版本。
- 从用户资料提取结构化职位、项目技能与文本 embedding，保留来源与时间。训练样本可由自报信息/人工标注构建，注意自选资料与求职意图不是同义。
- 先预测父类，再在父类候选中预测子属性；或者联合训练并在推断时施加父子一致性，防出现 Backend=true、Developer=false。One-vs-Rest LR 可给每类独立二分类器，softmax LR 适合互斥单标签；如果允许多标签，独立 sigmoid 或多标签模型更自然。
- 阈值按类校准，罕见类可 abstain 并交给人工复核。新职位无法映射时先检索最近类别并看置信/人工标签，再提出新类候选、审核、迁移训练数据和重建索引，不让模型私自写本体。
- 评估父类与子属性分别做 precision/recall、层级一致性、长尾类别与人群切片；线上看搜索/匹配质量及用户纠错，监控本体改版前后漂移。
手动走一遍
用户公开项目写 React 前端与 API 服务：候选父类 Developer，子属性 Frontend/Backend 可同时成立；若只见‘engineer’而无可靠细节，父类可低置信、子属性拒答。新岗位写‘AI Infra Engineer’但本体没有此子类，应先映射相近节点并进入新类审核。
规模与取舍
设用户 U、类别 C、特征维 d，One-vs-Rest 线性预测每用户 O(Cd)，存 C 个权重向量 O(Cd)；检索/深度模型另计。本体更新涉及标签迁移与重训，题目未明确具体类别数。
易错点与追问
容易失分的边界
- 把二分类 LR 说成完全不能处理多分类。
- 把互斥 softmax 用在可同时为 Frontend/Backend 的多标签任务。
- 只预测子类而不保证父类一致。
- 模型凭空新建 taxonomy 节点而不审核。
- 用用户资料推断求职意愿或敏感属性。
继续深挖
- 类别是互斥还是多标签？
- One-vs-Rest 概率和不为 1 如何解释？
- 新 job posting 不属于旧类时如何发现并审核？
- 用户主动纠正标签后如何回填训练？
