★ FEATURED ARTICLE **摘要**：给 RAG 链路配重排序模型，第一反应是上 HuggingFace 官方的 TEI（Text Embeddings Inference）——一个容器、一条命令、自带批处理。但在这条链路里它没有用上，最后是我自己写了约 40 行的 `transformers + FastAPI` 服务顶上的。放弃 TEI 的原因不是它不好用，而是这个模型从架构上就不在它的支持名单里：它不是常见的分类式 cross-encoder，而是一个用"下一个 token 是 yes 还是 no"来打分的 CausalLM。本文记录这条决策链上的每一步判断，以及落地后实际踩到的三个依赖坑。适合正在搭 RAG、纠结重排序模型怎么部署的工程同学。一、背景：RAG 里最容易被低估的一个组件一条标准的两阶段 RAG 链路长这样：文档解析 → 分块向量化 → 向量库召回 topK → 重排序 → 取 topN 送给大模型向量召回解决"找到一批可能相关的"，重排序（Reranker）解决"在这一批里挑出真正最相关的"。它是召回和生成之间的最后一道把关：召回错了还能靠 Reranker 挽救一部分，Reranker 选错了，生成模型拿到的上下文就是错的，后面什么都白搭。这次要部署的是一个4B 级别的 cross-encoder 重排序模型，官方推荐的数据格式是 yes/no 判别式。二、决策链：三条路，两条走不通2.1 路线一：vLLM 的 `/v1/rerank` —— 环境卡死vLLM 从某个版本起原生支持重排序接口，这是最省心的一条路。但当时的部署环境是Windows 原生——vLLM 官方不支持（这正是上一篇《Windows 上跑推理服务的三个硬限制》讲的那件事）。这条路在动手前就排除了。2.2 路线二：TEI —— 架构不支持TEI 是 HuggingFace 官方的推理服务，一条 Docker 命令起来，自带批处理和量化，看起来是标准答案：docker run --gpus all -p 8080:80 ghcr.io/huggingface/text-embeddings-inference:1.5 \ --model-id reranker-model但它的支持模型名单是按架构白名单的——只接受能被它当作"特征提取模型"来加载的架构。而我们要部署的这个模型，在 HuggingFace 上注册的架构是CausalLM，不在 TEI 的支持列表里。强行指定会得到一个加载失败。2.3 路线三：sentence-transformers —— 也不对口对纯 cross-encoder（比如 bge-reranker 系列），`sentence-transformers` 的 `CrossEncoder` 是标准用法。但这个模型不是那种结构，它根本没有一个能输出分数的分类头。2.4 所以最后走了第四条路
阅读完成 · 觉得有帮助？
