MixLM：让 LLM 排序又强又快的工程级方案
一句话总结：MixLM 让大模型参与搜索排序不再“贵到用不起”，通过把长文本离线压缩成 embedding token，在线只让 Ranker 看 query + 少量向量，就能把吞吐提升 10×～75×，还保持接近全文本排序的效果。
论文原文
1. 背景：为什么“用 LLM 排序”这么难上线？
很多人做过类似尝试：
- 把 query + 候选 item（比如职位描述、商品详情、文章正文）拼起来
- 丢给 LLM 问：“这个 item 和 query 相关吗？”
- 用 LLM 的 yes/no 或打分当排序依据
这方法确实强，因为 LLM 擅长理解语义、意图、上下文。
但它几乎注定上线困难，原因很现实：
问题 1：输入太长
item 文本经常上千 token（职位描述、商品详情都很长），每个 item 都要重复喂一次。
问题 2：计算量爆炸
Transformer 注意力复杂度 ~ token²
token 一长，成本直接炸裂。
问题 3：线上排序是“一次对几百上千个 item”
搜索排序不是问一次问题，而是：
同一个 query 要对几百～几千个候选 item 打分
所以成本会乘以 item 数量，完全扛不住。
2. MixLM 的核心思想：别让 Ranker 在线读全文
MixLM 其实干了一件非常工程化但很聪明的事：
把 item 的长文本提前离线压缩成少量“向量 token”，在线只喂这些 token 给 LLM。
传统方案（全文本 cross-encoder）
Ranker 输入：
系统提示 + query + item 全文
每个 item 都是一大串。
MixLM（text-embedding mix-interaction）
把排序拆成两步：
Step A：离线 Encoder 压缩 item
用 Encoder LLM 把 item 全文 → embedding tokens（比如 1 个 token）
Step B：在线 Ranker 只看 query + embedding tokens
Ranker 输入：
query 文本 + item embedding tokens
类比：
以前是“面试官每次都从头看完整简历”
现在是“简历提前被浓缩成几行摘要，面试官只看摘要 + 岗位需求”
3. 为什么这种压缩不会严重掉效果？
直觉上你可能会怀疑：
item 全文没了，只剩 1 个 embedding token，Ranker 怎么理解 item？
MixLM 的关键不在结构，而在训练方法：
不是随便做 embedding，而是让 Encoder 和 Ranker 在强监督下共同训练，并强制对齐。
他们用了一个非常“老师带学生”的训练 pipeline。
4. 训练策略：三阶段老师-学生体系（最精华的部分）
MixLM 的训练可以理解为：
先培养一个“超级懂业务的大老师”，再让学生模型继承能力，最后再学会用 embedding 版本输入。
Stage I：先教小模型“怎么思考”（领域推理微调）
他们先训练一个 7B judge 模型，让它对 query-item 打 0～4 分，并写推理理由（类似 CoT）。
然后用它去蒸馏一个 0.6B 小模型：
让小模型学会 judge 的“思考方式 + 打分倾向”
这一步的意义是：
让 Ranker 先具备领域推理能力，否则后面训练会很难。
Stage II：训练一个效果极强的“全文本 Teacher Ranker”
接着用 Stage I 的小模型，喂入完整文本训练 cross-encoder 排序器：
输入：
系统提示 + query + item 全文
输出：
yes/no 概率
它效果很强（NDCG@10 0.9432），但太慢不能上线。
于是它变成“teacher”。
Stage III：真正训练 MixLM（embedding 输入版）
这一步才是 MixLM：
- Encoder：负责 item 全文 → embedding tokens
- Ranker：负责 query + embedding tokens → relevance score
并且用三种损失把它拉住：
- SFT（软标签监督）：对齐 7B judge 的打分倾向
- Distillation（蒸馏）：对齐全文本 teacher 的输出分布
- Self-alignment（自对齐）：强制 “embedding 输入” 和 “全文本输入” 在 Ranker 内部表征一致
这一步非常关键：
不是让 Ranker 自己适应 embedding，而是用强约束避免它“脑回路跑偏”。
5. 系统工程：不止模型结构，吞吐靠工程榨出来
MixLM 另一大亮点是：它不是停在论文结构，而是把系统做到了生产级。
关键工程点 1：共享 query 前缀（prefix KV cache）
同一个 query 对几百个 item：
- query 部分完全一样
- 只需要算一次 prefix KV cache
- 后面 item 只算 suffix
这能省掉巨量重复计算。
关键工程点 2：多 item 一次性打分（multi-item scoring）
把多个 item suffix 串起来，做 attention mask 阻止跨 item 信息泄露。
这样 GPU batch 利用率更高。
关键工程点 3：接口直接支持“文本 + embedding”
他们把 embedding 作为 gRPC 请求字段传给服务端：
避免 server 重复算 embedding，也方便 embedding 缓存
6. 效果怎么样？（论文最硬的结果）
Offline 指标（排序质量）
- Full-text teacher：NDCG@10 = 0.9432（最强但慢）
- MixLM：NDCG@10 = 0.9239（略低但很接近）
- embedding retrieval：0.8380（明显差）
- summarized+pruned：0.9218（接近 MixLM）
结论：MixLM 基本保住了 cross-encoder 的交互能力。
Online 线上指标（工业价值）
- 吞吐：22,000 items/s/GPU（H100，500ms 延迟预算）
- 相比 full-text LLM：75.9× 提升
- 相比 summarized-text：10× 提升
- LinkedIn 全流量 A/B：DAU +0.47%
0.47% 可能看着不大，但在 LinkedIn 这种体量上非常可观。
7. 这篇论文最值得借鉴的点
我认为它最大的价值是：给了一个“LLM 排序可落地”的标准模板。
关键 takeaway
1）不要让 LLM 在线读长文本
把长文本变成可预计算的压缩特征（embedding tokens）
2）embedding 不等于“直接用向量”
要让 Encoder 和 Ranker 联合训练，并且对齐内部表征
3）真正的吞吐来自系统工程
KV cache、batch、prefix sharing、服务栈优化缺一不可
8. 局限与适用场景
局限
- 需要大量数据、强 teacher/judge
- pipeline 复杂，工程门槛高
- token 压缩太狠时（1 token）可能丢细粒度语义
适用场景
非常适合：
- 搜索排序（job/product/doc）
- 推荐排序（feed、内容）
- 广告候选重排
- 任何 item 文本长、候选多的 rerank 场景
9. 结语
过去业界对“LLM 排序”的普遍结论是：
效果好，但太贵，上不了全量。
MixLM 的贡献在于证明了另一条路：
LLM 排序不是只能做小流量实验，它可以通过结构 + 蒸馏 + 系统优化变成工业级能力。
如果未来搜索/推荐要全面 LLM 化，MixLM 这种“模型 + 训练 + serving 一体化设计”的路线，很可能会成为主流范式。