企业官网建设流程全解析

1. 端侧多模态检索的三道坎：算力、内存与“没网也得能搜”

先讲一个真实需求。某个月相册类应用提了个功能：用户离线状态下拍一张照片，想在本地相册里找出“相似的所有图片”。当时第一反应是——这还不简单？图像检索嘛，拉个通用模型，向量化，建索引，搞定。结果真正落地才发现，端侧多模态检索是个链路上的系统工程，不是“模型量化一下塞进手机”这么轻巧的事。

所谓端侧多模态检索，本质是让手机、平板、嵌入式设备这类资源受限终端，在完全离线或低网络依赖的环境下，完成“文本-图片”“图片-图片”“图片-文本”等多种模态之间的相似性匹配。和云端检索最根本的区别在于：云端可以把整个候选库的图片全部丢给大模型过一遍，反正服务器扛得住；端侧不行，端侧的候选库里可能躺着几十万张图，但算力只有手机上的那几颗核心，内存就那么几百兆，所以你必须在离线阶段就把所有候选集全部向量化，线上只跑一次模型推理加一轮空间索引查询。

这里头有三道绕不过去的坎，我分别展开说。

第一道坎是算力。多模态模型动辄上亿参数，一张图在云端过一遍ViT-L/14要几十亿次计算，手机上根本扛不住。哪怕用轻量级骨干，手机CPU、GPU、NPU各自的算子支持也不一样，有些结构在服务器上很快，挪到端侧直接变龟速。我实测过一个MobileNetV3做视觉编码、FP32精度跑CPU，一张224x224的图要100ms左右，看起来还行，但如果查询阶段要做文本和图像双路推理加后续重排，延迟就超了用户的忍耐阈值。

第二道坎是内存。一个256维的embedding，float32存一份就是1KB。如果一个候选库里有20万张图，光向量就要200MB——注意，这还没算索引结构本身的开销，比如HNSW的邻接图额外还要吃掉30%~50%的内存。模型本身再占一两百兆，普通App根本吃不消，系统直接给你OOM。所以从模型到索引，每一步都在跟内存预算较劲，这不是一句“剪枝量化”能一笔带过的。

第三道坎是离线可用性。端侧场景最大的特点就是你没法保证用户当时有网。离线意味着整个检索流程——编码、索引、召回、重排——必须全部在设备内闭环。云端可以随时切换模型版本、重建索引，端侧则要考虑怎么在App升级时无缝替换模型文件和索引文件，怎么在白天增量更新索引而不过度耗电。这些都不是模型论文里会告诉你的东西，只有真正做成产品才知道有多磨人。

如果说在线端侧多模态检索还有什么隐藏优势，那就是隐私和响应速度。数据不出设备，天然满足隐私合规要求，用户的query不用上传服务器；同时少了网络往返，端到端延迟能做到200ms以内。这也是为什么这两年几乎所有头部相册、电商、笔记类应用都在往端侧检索方向卷。你如果也想做类似的功能，建议一开始就想清楚：你是要做端侧还是云端？这两个方向的技术栈、团队配置、评测方式差异巨大，中途切换代价极高。

2. 骨干网络选型：为什么小模型不是大模型的“缩小版”

选骨干是第一步，也是最容易踩坑的一步。很多团队的做法是：从开源的多模态大模型里拆出视觉塔和文本塔，直接蒸馏到一个小的MobileNetV3和一个小的BERT上。想法没错，但实操里有个隐蔽的坑——大模型的归纳偏置和小模型完全不一样，直接套用小结构，经常会出现“蒸馏完精度不错，一量化全崩”的情况。

2.1 视觉骨干：混合结构比纯卷积或纯Transformer更稳

我对比过三类视觉编码器：轻量卷积（MobileNetV3-Large）、轻量Transformer（EfficientFormer这类移动端友好的ViT变体）、卷积-Transformer混合结构（类MobileViT思路）。数据用的是某开源图文对数据集的一个子集，加自己业务里收集的商品图、风景图。

结论比较明确：纯卷积结构参数少、推理快，但语义表征能力在细粒度检索任务上明显偏弱，尤其遇到“不同款式但外观接近”的商品，召回率掉得很厉害。纯Transformer在小模型上收敛慢，而且很多端侧推理引擎对注意力算子的支持排得靠后，甚至要 fallback 到CPU逐算子跑，速度反而不如卷积。混合结构最均衡——前几层用卷积下采样降低分辨率，中间层用少量自注意力捕捉全局关系，最后接一个池化层输出向量。

我最终选的视觉塔内部代号VisionTiny，约1200万参数，结构是“3个卷积stage + 2个轻量自注意力stage + 1个全局池化”。224x224输入下理论计算量约1.2GFLOPs，INT8推理时在高端手机CPU上能跑到35ms左右，NPU上可以再压到20ms以内。这个算力水平基本是端侧视觉任务的及格线，再重一点就挤压文本塔和索引的预算了。

2.2 文本骨干：别小看“短文本编码”的代价

文本塔往往是被忽略的那一半。很多人觉得文本就是几个词，跑个小BERT就行。但真正用起来才发现问题：用户的自然语言query混乱程度远超预期，口语、错别字、中英混合、表情符号，每种都要处理。而且端侧检索的文本塔大多要处理的是query和商品标题/图片描述之间的匹配，长度通常不超过32个token，但语义要足够精细——比如“黑色圆领短袖显瘦”和“黑色V领短袖宽松”是两件完全不同的衣服。

我选的文本塔内部代号TextTiny，约800万参数，12层Transformer，隐藏维度256。和视觉塔输出维度对齐到同一个空间，都是256维。32个token的文本在CPU上跑一轮约12ms，量化后可以压到5ms。这个延迟基本不构成瓶颈，真正的难点不在推理，而在文本的规范化预处理——稍后在数据部分展开。

2.3 一个容易忽略的选型维度：端侧推理引擎的算子兼容性

这是我在项目中后期才深刻体会到的问题，写出来希望你能提前避掉。同一个模型结构，在不同的端侧推理引擎上表现差异巨大。有些引擎对LayerNorm支持很好，对GELU却要走通用实现；有些引擎的量化算子只覆盖Conv和MatMul，其他一律退到FP32。所以选骨干结构时，一定要先确认目标推理引擎的算子支持列表，尽量让模型只由“Conv、MatMul、Add、ReLU/LReLU、LayerNorm、全局池化”这类基础算子组成。

我在选型时就因为这个问题吃过亏：最早一版视觉塔里带了一个动态卷积模块，精度不错，但跑某个端侧引擎时被拆成一堆Gather和Reduce算子，延迟直接翻倍，后来又改回静态卷积并加了一个轻量SE模块替代。教训很简单：结构先问推理引擎，再谈论文指标。

2.4 Embedding维度的博弈

输出维度也值得单独说。256维是端侧检索的常用折中点——128维内存和索引开销更低，但表征能力在细粒度场景下明显吃紧；512维精度确实更好，但向量索引的体积、查询距离计算的耗时都上去了。以20万候选集为例，256维FP32向量是200MB，索引结构再占60MB左右，刚好能压进大多数App的内存预算；128维能再省一半，但我实测中recall@10会掉2~3个点，换来的成本收益不划算。最终我的方案是256维输出，索引侧再做一层产品量化压缩，后面第五章细讲。

3. 对齐训练：让图片和文本在同一个向量空间“说同一种语言”

骨干选完之后，真正的技术难点才刚开始——怎么让视觉塔和文本塔输出的向量在语义上对齐。这一步做不好，前面选型再完美也是白搭。常见做法是用对比学习做双塔对齐，但具体怎么配训练数据、怎么挖难负样本、温度系数怎么调，每一步都会直接影响最终检索效果，值得单独开一章来讲。

3.1 双塔结构的选择逻辑：为什么检索任务天然适合双塔

检索场景对延迟极度敏感。如果使用单塔跨模态模型——把图片和文本拼成一个输入，过一遍大模型直接输出匹配分——效果当然好，但代价是每个query都要把候选库里的所有pair重算一遍，20万次完整模型推理，端侧想都别想。双塔结构天然适合这个场景：离线阶段把候选集中的所有图片/商品用视觉塔预编码，得到向量库；在线阶段实时把query用文本塔编码，得到一个query向量，然后去向量库做最近邻搜索。整个过程只跑一次文本塔推理加一次ANN检索，延迟可控，这也是业界做端侧检索几乎清一色双塔的根本原因。

双塔的代价是模态间交互信息损失——图像和文本在塔内各自编码，最后只在一个点积/余弦层面对齐。这也是为什么“难负样本挖掘”在双塔训练里那么重要：负样本不够难，模型学到的对齐是粗糙的，很容易出现“图片A和图注B看起来都对，但语义上完全不搭”的幻觉。

3.2 损失函数与温度系数：那些直接影响召回的数字

对齐训练我用的还是经典InfoNCE对比损失，但有两个细节要特别强调。

第一，温度系数。初始按论文习惯设0.07，训完看recall表现一般；降到0.05后，正样本对的相似度分布被拉得更紧，负样本对的相似度被压得更低，最终recall@10提升了约1.8个点。原理不复杂：温度越低，相似度分布越尖锐，模型被迫更精准地区分正负样本。但也不能无脑低，太低容易让训练不稳定，负样本的梯度会爆炸。0.03~0.05之间是个比较稳的区间。

第二，难负样本。In-batch负样本是标配，也就是同一个batch里其他样本的图片/文本互为负样本。但只有in-batch不够，因为大多数负样本跟当前query差距太大，模型很容易学会“一眼假”。我会额外用离线挖掘的难负样本——自己先用当前模型对一批pair打分，挑出那些“相似度很高但语义其实不匹配”的样本，掺进训练集里，比例大概20%。这样做的效果立竿见影，特别是商品检索场景里那些“看着是同类、其实不同款”的困扰，直接被压下去了。

3.3 训练数据的清洗与配比：脏数据会把模型带偏

图文对数据是双塔模型的粮食，但端侧业务数据的脏乱程度远超通用数据集。我这边主要遇到三类问题：

一是图文错配。商品图上印的是A款，标题写的是B款，这种图在电商平台上一大堆。我没法彻底消除，但会做一轮粗过滤：用通用图文匹配模型打分，低于阈值的pair直接丢弃。二是短标题信息量不足。很多图片只有“2024新款连衣裙”这种标题，颜色、版型、材质全没提。对这种样本，我会让标注团队补充结构化标签，作为额外的细粒度正样本。三是query和doc分布不一致。训练集里很多是商品标题对商品图，但线上用户query的口语化程度高得多——“那条夏天穿的碎花裙子”和标题“碎花雪纺连衣裙夏季新款”不是一个写法。我的做法是从搜索日志里捞真实query，清洗后跟点击过的商品构建训练pair，这样模型的线上适应性才够。

数据配比上，我踩过一个大坑：一开始把通用图文对数据和业务数据一比一混合，结果模型在通用检索上表现不错，业务场景的细粒度召回却很平庸。后来调整配比，业务数据占到七成，通用数据占三成当底料，才把业务指标拉起来。原因是通用数据分布太广，每一类的样本密度不足，模型没法学到业务场景里那些细粒度区分线索。

3.4 分阶段训练：先让两个塔各自站稳，再谈对齐

端侧双塔模型的参数量都不大，如果直接从随机初始化开始端到端对比学习，收敛慢且结果不稳定。我采用三阶段训练：

阶段一，视觉塔预训练。在图文对上做对比预训练，不强求对齐文本语义，先把视觉表征学扎实。阶段二，文本塔预训练。在文本语料上做掩码语言建模，顺便做一轮文本增强，把这个塔的语义底层打牢。阶段三，双塔对比对齐微调。固定视觉塔和文本塔的底层大部分参数，只训练对齐层和最后的输出层，用小学习率跑几十个epoch。

这套方案的直观逻辑是：两个塔各自领域的“常识”先学好，再学跨模态的“翻译规则”。直接端到端硬训的话，小模型很容易顾此失彼，这边语义没学透，那边对齐也没到位。我对比过，三阶段训练比端到端训练在最终recall@10上高3~4个点，而且收敛过程稳定得多，不会出现loss剧烈震荡。

除此之外，还有一个值得说的技巧——用更大的开源多模态模型做嵌入蒸馏。具体做法是拿一个大模型对同一批图片和文本各出一个embedding，让我的端侧小模型去回归这个大模型的向量空间，而不是直接学pair匹配信号。这样做的好处是让教师模型的语义知识“压缩”进小模型的特征空间，尤其能补足小模型在通用概念上的短板。蒸馏温度我设为1.0，蒸馏损失和对比损失各占50%权重。实测下来，蒸馏后的模型在未见过的概念召回上明显更稳。

4. 量化与端侧推理优化：从FP32到INT8的完整实战

模型结构定了、训练跑通之后，还不能直接上设备——FP32的模型体积太大，推理速度也不够理想。这一章讲的就是压体积、提速的全过程。这部分我踩的坑最多，也最有分享价值。

4.1 为什么不直接上QAT：PTQ是性价比更高的起点

我最初给自己定了一个原则：能PTQ就不QAT。QAT要用模拟量化算子重新训练模型，不仅训练时间翻倍，还需要精心调学习率和量化感知的蒸馏策略，否则精度损耗反而比PTQ大。相比之下，PTQ只需要喂一批校准数据，记录每层激活值的分布，然后根据分布确定量化Scale和ZeroPoint，成本低很多。

我先是用了通用的均方误差校准方式，在视觉塔和文本塔各选500张代表性图片、500条代表性文本作为校准集。校准集我后来才意识到关键：不能在训练集里随便抽，要覆盖接近线上真实分布的样本，比如暗光图、过曝图、模糊图、长短不一的query，都要均衡放进去。第一次我图省事，从训练集里挑了一批正常光线下的图做校准，结果量化后的模型在夜间场景的检索能力几乎崩掉，后面专门补了这类样本才恢复。这个问题留到第六章再展开复盘。

4.2 哪些层最怕量化：一组反直觉的实验结果

PTQ过程中的经典问题是：均匀量化8bit，按理说精度损失控制在1~2%以内，但实际跑下来发现个别类别的召回直接掉5个点。我在逐层排查量化误差时发现，最敏感的不是视觉塔的卷积层，而是文本塔里那些带LayerNorm的注意力层和最后的输出层。

原因也不难理解：LayerNorm的输出分布是动态的，特征范围变化很大，固定的量化Scale很难同时适配所有输入。输出层则是embedding的“最后冲刺”，量化误差会被直接放大到检索距离计算里，一点精度损失都会导致相似度排序错乱。

我的处理方法是混合精度量化：卷积和MatMul做主量化到INT8，LayerNorm和GELU保留FP16，输出层也保留FP16。这听起来像是“偷懒+无效优化”的妥协，但实际上是个非常实用的工程手段——LayerNorm这类算子只占总计算量的很小比例，保留FP16对速度和内存的影响微乎其微，却能把量化带来的精度损失大幅降低。最终混合精度方案比纯INT8在recall@10上高出约0.9个点，而推理耗时几乎不变。

4.3 推理引擎层面的优化：算子融合与内存复用

量化完模型体积从FP32的约140MB降到INT8的58MB，但推理速度还不达标。下一步是算子融合。端侧推理引擎最常用的优化手段就是把Conv+BN+ReLU融合成一个算子，把Multi-Head Attention里的QKV三个线性层融合成一个大的MatMul，残差连接和Add操作合进去。这些融合能减少算子调度和内存读写的开销，尤其是注意力部分，融合后视觉塔的CPU延迟直接砍掉30%。

还有一个容易被忽略的点是内存复用。双塔模型跑一次推理，中间会生成大量feature map，如果每个算子都重新分配内存，内存峰值会翻好几倍。我的做法是在推理引擎里提前申请好一个“workspace buffer”，让所有中间张量都在这块预分配的空间里复用。这个操作不改变模型结构，却让整体内存峰值从210MB降到了不到140MB，对落地价值非常大。

4.4 端侧实测：各优化阶段的量化效果对比

我拿了一个中端Android设备（某款骁龙7系芯片，8GB内存）做基准测试，把整个优化过程分阶段记录延迟和内存。测试用固定的20个query和5000张候选图，取平均数据：

可以看到，INT8量化在提升速度的同时损失了约1个点的召回率，混合精度能把这1个点几乎找回来，算子融合和NPU进一步把延迟压缩到端侧可用的范围。最终整条链路视觉+文本+检索总计不到80ms，完全达到产品可用水平。

注意：NPU推理有一个额外风险——不同厂商NPU的算子实现差异很大，同一个模型换一台手机可能就触发fallback。所以我在发货前会跑一遍不同设备的算子覆盖测试，确保没有冷门算子。

5. 端侧索引与召回：模型只是上半场，下半场同样决定成败

模型输出embedding只是链路的第一步。真正把20万个向量变成毫秒级召回结果的，是索引和检索策略。这一章讲的是端侧检索最容易被低估的部分——很多做模型的团队在这里栽了跟头，以为用现成的向量检索库就万事大吉。

5.1 向量索引内存和召回率的博弈：从暴力搜索到HNSW

在端侧，最开始我甚至想过暴力搜索——20万个256维向量，逐个算余弦相似度，在高端手机上要300ms，中端手机直接500ms以上，完全不可用。而且这个时间随着候选集规模线性增长，用户的相册到100万张时就彻底撑不住了。

所以我选了HNSW作为基础索引结构。HNSW的原理不展开说了，重点讲参数。M（每个节点的最大连接数）我设为16，efConstruction（建索引时的搜索宽度）设为128。这两个值直接决定了索引的内存和建索引时间：M太小，图连通性差，查询容易走丢；M太大，内存暴涨。efConstruction影响索引质量，太小的efConstruction建出的索引召回会打折扣，但太大建索引的时间几何级增加。我实测下来的平衡点是M=16、efConstruction=128，20万条向量建索引大概40秒，内存开销60MB，query时延约5ms左右，单设备一次全量重建也就在人们等待的可接受范围内。

5.2 PQ量化：把索引体积再压一个量级

HNSW本身还不能解决内存问题，因为20万条FP32向量要200MB，加HNSW结构60MB，总内存260MB，对端侧来说还是太高。第二步就是对索引向量做产品量化（PQ）。

PQ的原理是把256维向量切成8个子空间，每个子空间用256个质心去做编码，每个向量的存储就从256个float变成了8个uint8，体积缩到原来的1/32。配合HNSW，20万条向量的内存降到约35MB，整个检索内存预算肉眼可见地健康了。

但PQ也有代价——代码本训练需要一份有代表性的样本集，如果用随机权重初始化再训练，效果会差很多。我的做法是先用当前模型把所有候选集图向量跑一遍，从里面均匀抽10万个样本训练代码本，再对全部向量做量化。这样每个子空间的质心才能贴合真实数据分布。

这里有个细节：子空间划分不能简单按维度顺序硬切。比如256维的前32维可能包含了颜色信息，后32维包含纹理信息，分布方差差异很大。我试过按照维度方差排序后重新排列再做划分，让各子空间的方差尽量均衡，recall@10直接又涨了0.4个点。这属于典型的“模型侧看不到的优化点”，但实际收益确实存在。

5.3 召回策略：先粗排后精排，别让一次PQ量化毁掉精度

PQ量化有个绕不开的问题：它是近似最近邻查询，不是精确的。Fine，直接拿PQ距离去决定最终top结果，遇到高难度样本时排序会漂。所以我在检索pipeline里加了一层重排环节：

第一步，用PQ量化的索引做粗排，从20万个候选里快速捞出top200。第二步，把这200个候选向量的原始FP32向量预存一份，逐个和query向量算精确余弦相似度，重排选Top50展示给用户。这200次FP32余弦计算很快，大概零点几毫秒，但对精度挽回非常明显。最终线上正确率比纯PQ逼近召回高出约1.2个点。

注意：预存一份FP32原始向量的内存不能省。索引可以压缩，但把原始向量丢掉的话，重排就无从谈起了。不过FP32原始向量可以只用PQ前的FP32，或者用INT8向量存一份，重排精度差异不大，内存再省一半。

5.4 索引的生命周期管理：更新、销毁和版本切换

端侧索引不能像云端一样随时全量重建，要考虑电量、算力和用户体验。我的方案是三层更新机制：

• 冷启动：首次安装App时，下载一份云端预生成的通用索引，覆盖热门类目。
• 增量更新：用户新增图片/商品时，只对新增项单独编码，插入HNSW图，通常是凌晨空闲时段执行，避免掉电或卡顿。
• 版本切换：模型升级后，旧索引和新模型输出不兼容，上新模型时同时提示用户“正在重建索引”，并在地界之下保留旧模型和旧索引一起跑，直到新索引就绪再切换。

这套机制听起来简单，但每个环节都有坑。增量更新时HNSW在整个图上插入节点，如果不控制并发写入，查询会拿脏数据；版本切换时不先验证新索引的覆盖率和召回率就直接替换，用户会瞬间觉得“搜索变差了”。我在正式发布前专门加了一轮“新索引冒烟测试”，用一组标准query对比新旧索引的召回top结果，差异超过阈值就自动回滚，确保搜得比之前更准或者持平。

6. 实测效果与调优复盘：那些文档里查不到的坑

最后一章不写教程了，写点踩坑复盘。多模态检索跑通Demo不难，做到稳定好用真的折磨人，这几个问题是我印象最深的，贴出来给你做参照。

6.1 校准集偏差：为什么夜间场景全崩

第一次PTQ量化时，我随手从训练集里抽了500张正常光线图片做校准集，量化完跑通用测试集，指标只掉了0.2个点，觉得很完美。结果一到用户评测环节，夜间/暗光场景的检索结果一团糟——拍一张夜景图去搜相似图片，返回的全是曝光过度的错误结果。排查了一天才发现，校准集里几乎没有暗光图片，量化Scale被正常光线样本主导，暗光特征被错误地压到量化盲区里。

修复方法很简单：把校准集换成覆盖暗光、过曝、模糊、极低纹理，以及不同色温场景的均衡样本集，重新量化后夜间场景召回恢复如初。这件事给我一个教训——PTQ的校准集不能只追求数量和“代表性”，分布必须覆盖线上真实的长尾场景，尤其是那些模型本来就不太擅长的场景。

6.2 文本截断的隐形坑：搜索词太长导致检索完全跑偏

文本塔的限制长度是32个token，线上真实query经常超长。我一开始的做法是简单截断——超过32个token直接切断。结果出现了一个诡异问题：用户搜“黑色宽松落肩圆领短袖T恤女”，文本塔拿到的其实是更靠中间的一段token，关键词“黑色”“圆领”“短袖”全被截没了，检索结果自然是“宽松T恤”相关，但搜出来的都是蓝色V领长袖。

这个问题排查了很久。后来我把截断策略改为从两头同时保留，优先保住开头和结尾的完整词，并在截断处加一个特殊的截断标记token。另外把长度上限从32调到了48，代价是文本推理延迟从5ms涨到8ms左右，但换来的语义完整度非常值。任何做端侧文本编码的人都应该把query截断当成一个正经的产品需求来设计，而不是代码里随便slice一下。

6.3 PQ子空间划分不均：召回率卡在瓶颈上不去

有一次调完模型，感觉精度该到顶了，但recall@10死活差0.5个点。后来发现是PQ的子空间切分方式太粗暴——按维度顺序硬切256维为8段，结果其中两段方差极低（几乎全是常数值），另外两段方差极高，量化后信息损失严重不均。我改成按维度方差重新排序再做均匀切分后，recall@10直接涨了0.4个点。这种问题是离线评估里不容易暴露的，因为代码本训练和划分本身没有报错，只有精细化排查时才会发现。所以做索引优化时，不要只看最后的整体指标，把各子空间的量化误差单独打印出来看，分布均匀才是健康的。

6.4 离线评估指标和线上体验的落差

最后提醒一句：离线recall指标和线上用户体验不是一回事。我在离线测试集上把recall@10做到78%，用户还是说“搜得不够好”。后来发现原因有两个：一是离线测试集的query都是标准写法，线上用户query口语化严重；二是检索结果“准确但不相关”——返回的图确实是同类物品，但用户想要的是同款同色同角度，模型却没抓住这些细粒度差异。

解决方向是引入真实query做对抗测试，把线上用户反馈的bad case直接沉淀成评测集中的脏样本，定期迭代。同时增加一个短文本摘要/结构化标签辅助模块，把“颜色、风格、材质、版型”这类显式属性在文本塔编码时先抽取出来，让查询侧的语义更结构化。这个模块上线后，用户反馈的bad case数量下降了一半多。

写在最后

做端侧多模态检索这几年，最大的体会是：这活儿三分在模型，七分在链路工程。模型选型、对齐训练、量化、索引、生命周期管理，每一环都在互相牵制——模型小了精度掉，模型大了内存炸；PQ省了内存但召回打折，量化提了速度但夜间场景崩。最终能跑通并且稳定上线，靠的不是某一篇顶会论文的模型结构，而是把整条链路反复打磨到每一个细节都经得起推敲。

如果让我给后来者一个最实际的建议：在你动手训模型之前，先把端侧的硬件平台、内存预算、候选集规模和真实query分布全部摸清楚，把这些约束条件写下来贴在工位上。模型训练永远可以重来，但架构选型和索引方案一旦定了，中间返工的成本是十倍起跳。另外，评测集一定要包含真实用户的查询日志，不要只在干净的数据集上自嗨——端侧检索终归是给人用的，用户的一句“这搜的是什么玩意儿”，比任何离线指标都更有说服力。