一份大模型算法岗的笔试题：给一批政务工单文本，做事项拆分、四要素抽取、四级分类，还要识别”群诉”（同一问题被很多人反复投诉）。题目反复强调一个词——通用性。我理解这道题考的不是你能不能把活干完，而是你怎么把”通用”做进架构里。
把”多解”做成架构，而不是堆工作量
题目里有一问要求”做成多解题”。直觉做法是跑三条冗余流水线，但那是堆工作量，不是通用性。
我的解法是：每个子任务设计成可插拔的 Strategy，规则、向量、LLM 三类方法各自实现一个接口，思路文档里逐个对比权衡、说明默认选哪个、为什么。代码里至少给一个子任务（群诉）保留两套可切换实现。这样”多解”体现在架构抽象加文档对比上，而不是把同一件事做三遍——这本身就是题目要的通用性。
整条流水线是：
加载(列名自适应) → 预处理(剥样板) → 事项拆分(三档策略对比选默认)→ 四要素抽取 → 四级分类(国标锚定+数据涌现的冻结树)→ 群诉识别(点位分块 ∪ faiss向量召回, 双路保recall, LLM裁决)→ 跨厂商交叉验证 → 导出群诉识别：双路保召回
群诉的难点在召回。脱敏把工单里的”区名、门牌号”抹掉了，如果纯按点位 key 分块，会漏掉”地标也被替换”的同点位工单（比如同一个地方被写成两种说法）。所以我没有只靠分块，而是双路：
- 点位分块保精确率（precision）；
- faiss 向量召回扫一遍保召回率（recall）；
- 两路取并集，再交给 LLM 做最终裁决。
分块负责”稳准”，向量负责”不漏”，各补对方的短板。
可插拔的 embedding，和一次设计验证
向量召回需要 embedding，但环境不一定有现成的端点。所以我把 embedding 源做成可插拔：默认走真 embedding API，TF-IDF 加 faiss kNN 作为纯离线兜底。
这个设计很快就被现实验证了价值：主力模型 DeepSeek 没有 embedding 端点，群诉向量召回就只能先走 TF-IDF 兜底——正好说明了”为什么要做可插拔”。后来拿到智谱的 key，有 embedding-3（2048 维）真向量模型，一行配置就切过去了，召回质量直接上一档。把外部依赖做成可插拔，不是为了好看，是因为你事先不知道环境里到底有什么。
跨厂商交叉验证
分类和裁决这种主观判断，单模型容易自说自话。我用两个不同厂商的模型互相印证：主力用 DeepSeek V4 pro，第二判官用智谱 GLM-4.6，报两者的一致率。跨厂商比同厂商不同档位（比如 pro vs flash）更有说服力——真正独立的两个判断一致，才说明结果稳。
规模化：算法岗的硬加分
题目强调通用，那就得考虑规模。10 万条工单时：群诉的成对裁决是 O(n²) 会爆，分类树归纳喂全量摘要会超 context。我把规模化设计写进了文档：向量召回把群诉复杂度从 O(n²) 降到 O(n·k)、分块归纳、增量处理。并用 300×3 的小压测验证流水线在全量上能跑通。对算法岗来说，“能跑通”之外还能讲清楚”上规模怎么办”，是实打实的加分项。
小结
这道题我最在意的是没有被”多解题”带偏去堆工作量，而是把通用性落在 Strategy 抽象、可插拔依赖、规模化设计这些架构决策上。算法岗看的不只是你会调哪个模型，而是你怎么把一个具体任务抽象成一个能扩展的系统。