企业官网建设流程全解析

做门店数字化改造这几年，我见过太多"模型现场翻车"的名场面。拿一个通用多模态大模型（MLLM）去识别货架上的某个具体SKU，它会非常笃定地告诉你那是一瓶常温水，但实际上那是一瓶气泡饮料；让它读价签上的小字，它把生产日期和保质期混到一块儿；最离谱的一次，让它核对堆头陈列数量，它数出来的数字比实际多出一倍。问题根本不是模型"不够聪明"，而是它压根没在"门店"这种环境里受过系统训练。

这就是我推动 Ostrakon-VL 项目时最想解决的核心问题：把多模态大模型打磨成餐饮零售领域的"专家"，而不是一个什么都会一点、一落地就露馅的"通才"。这篇文章不打算堆概念，我会把从技术选型、数据工程、训练流程、评测体系到部署落地这条链路里的关键决策和踩过的坑，原原本本捋一遍。项目开发过程中踩的坑不少，但回头看的经验都是有价值的，值得认真沉淀下来，这篇就当作一次系统复盘，也希望能给正在做行业大模型落地的同行一些参考。

1. 通用多模态大模型做餐饮零售时，到底哪里不对劲

1.1 视觉感知的颗粒度跟不上门店需求

通用多模态大模型在互联网图文数据上训练，擅长的是"描述画面内容""回答常识问题"。但门店场景里，大部分任务要求的是字段级的精确理解，而不是语义级的概括理解。

价签上的价格是"¥12.50"还是"¥12.90"，差四毛钱就可能引发结算纠纷；生产日期是"20240908"还是"20240809"，数字顺序稍有差错就涉及食品安全合规；冰柜里被霜雾盖住的标签、饮料瓶身被冷凝水模糊的批号，这些都是通用模型训练数据里极少出现的"脏样本"。通用模型见惯了高清、干净、居中的商品图，到了低对比度、小字号、遮挡的实拍场景，性能断崖式下跌是必然的。

一句话概括：通用模型的视觉能力是"看懂图"，门店要的是"看清图里每一个字、每一个数字"。这两种能力的训练目标完全不同，数据分布也完全不同，指望通用模型直接胜任是不现实的。

1.2 业务语言和产品知识是硬缺口

餐饮零售行业有自己的一套"黑话"和知识体系。门店员工说"效期"指的是保质期到期日，"先进先出"是补货原则，"排面"指货架陈列的规范状态。这些词在互联网公开语料里出现频率并不高，通用模型很难准确理解它们的业务含义。

更硬核的是商品知识缺口：某个SKU是冷藏品还是常温品、某款调味酱是否含过敏原、某个品类的典型保质期是30天还是180天、同一品牌不同系列的包装差异在哪里。这些知识散落在商品资料库、供应商手册和门店运营材料里，并不在通用模型的预训练语料覆盖范围内。我问过通用模型"某品牌低温酸奶在0-4度条件下通常保质期多久"，它给了一个模糊的"大约21天"的答案，而实际业务口径是18天。这种偏差在闲聊里无伤大雅，在合规审查里就是事故。

1.3 真实环境的干扰远超实验室想象

实验环境用标准机位、均匀光照、干净背景测出来的效果，到了真实门店基本都要打折重测。日光灯频闪、货架层板遮挡、标签贴歪、金属包装反光、热食区蒸汽、冷链区霜雾，这些干扰因素组合起来，会让同一件商品在不同门店、不同角度、不同时段成像出完全不同的样子。

我们在项目早期犯过一个错误：在样板间里把Demo跑得行云流水，觉得"这事成了"。结果把同样的模型拿到三家真实门店一测，识别准确率掉了将近20个百分点。这个教训让我们从此立下一条规矩：跑通Demo不算成功，能在真实门店五花八门的成像条件下扛住才算。整条技术路线的设计，事实上都是围绕"鲁棒性"和"精确性"两个词展开的。

2. Ostrakon-VL的技术选型：基座模型、视觉编码与"领域专家"定位

2.1 基座模型怎么选：开源权重与训练成本的平衡

项目启动时第一个被反复讨论的问题是：为什么不用公开的通用多模态API，而要自己训练一个模型？答案有三个层面的考量。

数据合规层面：门店摄像头采集的画面里包含顾客走动、员工操作、后台收银等敏感内容，频繁外发给云端API既不可控，也有数据安全风险。

定制空间层面：做领域专家模型需要改数据分布、做偏好对齐、调输出格式，闭源API只能通过提示词做浅层约束，无法触达模型内部。

成本层面：门店摄像头每天产生海量画面，按调用量计费的商业模型在规模化之后成本根本兜不住。所以基座只能选开源权重体系。

选型时我们对比了当时主流的开源MLLM权重，最终决策权重最大的三个因素：中英文能力都要过硬，因为门店标签经常是中英混排；视觉编码器支持高分辨率输入；社区生态完整，方便做后续的量化部署。这里有个实战经验值得分享：挑选开源基座不要只看综合榜单分数，要看它在代理任务上的表现，比如文档OCR、细粒度计数、小字识别。我自己建了一个几十条的"门店小测试集"，把所有候选模型先跑一遍，用分数说话，比看任何榜单都靠谱。

2.2 视觉分辨率与OCR能力的架构取舍

通用MLLM为了控制算力成本，通常会对输入图片做大幅降采样，常见的是224×224或336×336。这个分辨率在识别价签小字、包装成分表、生产日期喷码时是致命的——字根本看不清，再好的语言模型也白搭。

Ostrakon-VL在视觉输入端做了针对性的分辨率增强：对输入图片做区域切分和分块放大，让每个局部块都获得充足的像素密度，同时保留全局图用于理解版面结构。这个设计能有效提升细粒度文字识别能力，代价是视觉token数量显著增加，推理变慢。

我们最后的折中方案是"按任务调分辨率"：交互式任务，比如门店员工拍一张照片问"这个商品过期没有"，用较粗的分块保证响应速度；批处理型任务，比如货架盘点扫描，用最细粒度分块换精度。这个策略在落地阶段帮我们同时保住了体验和效果。

2.3 为什么走"领域专家"路线而不是通用助手

这是项目定位层面最关键的决策。市面上不少团队做行业模型，思路是"做一个更通用的模型，靠堆数据量取胜"。我们的判断完全不同：餐饮零售场景的容错率太低，准确率要逼近99%才有商业价值，而99%的准确率只能靠把模型的注意力收敛到一小簇核心任务上才能逼近。

领域专家路线的含义很直白：模型不需要会写诗、不需要知道各国的首都，但它必须能精确识别几万个食品SKU、看清价签上的每一个字符、对熟食的熟度给出接近老店员水准的判断。术业有专攻，这在AI落地里同样是铁律。通用助手面对一个模糊问题可以绕弯子、给免责声明，但业务系统需要的是稳定、精确、可预测的输出，哪怕代价是牺牲掉一部分"泛能力"。

3. 数据闭环：门店真实数据与合成数据如何配合

3.1 真实数据的采集、脱敏与合规

真实门店数据是项目的地基，也是最难搞的部分。门店合作方要愿意开放场景，采集设备要部署得低调、不能影响正常营业，图像里还可能出现顾客人脸、员工操作、交易小票等敏感信息，合规处理必须彻底。

我们的做法是在合作门店的货架、收银台、后厨操作间部署摄像头，连续采集若干自然周的影像，然后做两阶段脱敏：第一遍用程序自动打码人脸和交易小票上的敏感字段，第二遍由人工抽检确认脱敏效果。所有数据只进入私有训练环境，训练完的中间产物按周期销毁，不进公共存储。这套流程听着繁琐，但涉及真实业务数据时必须守住底线，没有讨价还价的余地。

3.2 用通用大模型"造"领域训练数据

真实数据标注的成本高得惊人。一张堆满几十种商品的货架图，完整的细粒度标注需要半小时以上，人力开销根本撑不起几万条的量级。我们的补充手段是一条合成数据流水线。

先把商品详情页图片和产品资料图整理成标准图库，然后用程序化方式生成任务样本：比如把价签文字用不同字体、字号、透明度合成到各种背景上，批量生成"读价签"训练数据；再比如把单个SKU抠图后随机贴到货架背景里，生成"SKU识别+计数"样本。另外，我们还用通用MLLM对真实门店图片做"弱标注初稿"，再由人工修正，把标注成本压缩了将近一半。

合成数据最大的风险是风格漂移——模型在干净的合成图上表现很好，一到真实光线和噪声环境就失灵。为了对抗这个问题，我们定了一条"三七开"原则：合成数据负责扩充数量，真实数据负责锚定真实分布，两类数据必须在同一个batch里混合训练，谁也不能偏废。

3.3 任务模板体系：把门店问题翻译成模型问题

把五花八门的门店需求变成可训练、可评测的标准任务，是数据工程里最见功力的环节。我们拆出了十几个标准任务模板，核心的几个是：

• SKU识别：输入商品图，输出标准商品名、品牌、类目；
• 价签标签OCR：输入价签图，分别抽取价格、生产日期、保质期、品名；
• 效期核验：输入商品包装图，判断是否临期或过期，并输出判断依据；
• 堆头计数：输入陈列图，统计画面中某类商品的数量；
• 陈列合规：输入货架图，判断排面是否符合先进先出等管理规则；
• 菜品识别与属性抽取：输入菜品图，输出菜名、主要食材、可能致敏原。

每个模板配了独立的提示词模板和JSON输出约束。好处是训练数据的格式高度规范，模型输出能被业务系统稳定解析；坏处是模型在开放式问答上会显得"僵硬"。所以我们在任务数据之外，又混了一部分多轮闲聊式泛化数据，让模型在完成标准任务的同时不至于失去对话能力。

3.4 标注规范和质量控制

标注是数据工程的最后一公里，也是最容易翻车的一环。我们的实践包括三个层面：每个任务模板都编写详细标注手册，附正例和反例截图；实行双层抽检制度，标注员自检之后，质检员按10%比例抽检，抽检不通过就返工重标；对价格、日期这类高风险字段，做双人独立标注加不一致仲裁。

这套制度听着不性感，但它能把标注错误率稳定压在1%以下。数据质量不过关，后面所有训练都是白搭，这一点怎么强调都不过分。

4. 训练全流程：继续预训练、指令微调与偏好对齐

4.1 领域继续预训练：先把行业语言灌进去

训练的第一步不是调多模态能力，而是做文本侧的领域继续预训练，语料包括三类：商品百科和产品资料库，覆盖数万个SKU的品名、规格、储存条件；门店运营手册、食品安全规范、零售管理SOP；行业论坛和问答社区里关于菜品、食材、库存管理的讨论内容。

继续预训练的好处是成本相对可控，只用文本数据，不涉及视觉语言对齐，但收益很直接。做完这一步，模型在"餐饮零售话术"上的接续生成能力明显变好，更重要的是为后续指令微调储备了领域知识底子。如果跳过这一步直接做多模态指令微调，模型很容易出现"会看图但说不清专业名词"的半吊子状态。

4.2 多模态对齐与指令微调

接下来是两阶段的视觉语言训练。阶段A用大量图文配对数据做对齐，让视觉编码器输出的特征与语言模型的嵌入空间更好对接，数据主要是商品图加标题简介、门店场景图加场景描述。阶段B用第3节里的任务模板数据做指令微调，让模型学会"看图之后输出规定格式的JSON"。

训练中一个很实际的坑是损失函数类别不均衡：OCR任务生成的字符序列很长，loss占比天然偏高，容易把SKU识别这类短输出任务压住。我们的解法是按任务分组加权的采样策略——每个任务根据上一轮loss做归一化后再作为采样权重，让"尾巴任务"也能获得足够的训练比重。技巧本身不复杂，但对最终多任务效果的均衡性影响非常大。

4.3 偏好对齐：减少胡编乱造的OCR结果

无论是通用MLLM还是领域MLLM，幻觉都是大问题。门店场景最不能忍的幻觉是"读错数字还一本正经"，这比"识别不出来"更危险，因为业务系统会把错误结果直接当成正确结果处理。

我们引入了一轮偏好对齐训练：构造偏好数据对，对同一张图让模型生成多个回答，人工把"准确且完整"的答案标为优选，把"缺字段或编造数字"的答案标为劣选，然后用DPO方法做一轮轻量对齐，内部权重控制得很小，防止破坏前面阶段学到的指令遵循能力。

效果最明显的变化是：模型在不确定某个字符时，从"硬编一个数字"变成"如实说无法确定，并建议重新拍摄"。这个行为转变在业务侧价值巨大，因为它把模型从"不可信的自动机"变成了"会自我怀疑的助手"。

4.4 训练稳定性与复现性的几个细节

多模态训练的稳定性问题比纯文本训练更突出，踩过几次坑之后总结出几个实测有效的要点：

学习率要设置得比同等规模纯文本模型明显更低，否则视觉编码器容易发生灾难性遗忘；混合精度训练时，视觉编码器部分最好保持高精度权重更新，能有效缓解小数字字段的数值精度损失；checkpoint保存频率要短，多模态训练下loss曲线可能突然出现尖刺，能回滚到尖刺前一版，省下来的重训时间相当可观。

还有一条是对齐阶段的顺序不能乱：先做文本侧继续预训练，再做视觉语言对齐，最后做指令微调。我们曾尝试把文本预训练和指令微调合并执行以节省时间，结果模型学会了输出格式但领域知识明显薄弱，最后只能推倒重来。

5. 领域评测体系：用数据证明"专家"而不是靠感觉

5.1 评测集设计：不能只挑好看的样例

评测集是领域专家模型的质检尺，设计得不好，训练就被带偏。我们搭了一套三层评测体系。

第一层是小而快的回归集，约200条典型样本，每次训练完快速跑一遍，用来发现明显的性能回退。第二层是覆盖12个任务模板、约5000条样本的完整领域评测集，一半来自真实门店采集，一半来自刻意构造的对抗样本，比如贴歪的标签、昏暗灯光下的价签、反光包装的特写。第三层是人工跟测，每周从真实门店新场景中抽30条跑一轮人工打分，防止模型在固定评测集上过拟合出虚高分数。

5.2 指标定义与基准对比

不同任务的指标不能一刀切，这是评测设计里最容易被忽略的。价格和日期属于高风险字段，必须按字段级F1来算；SKU识别关注排序能力，要用Top-1和Top-5；计数任务用平均绝对误差；陈列合规这类主观判断任务则与"督导员判断一致性"挂钩。

和通用MLLM基线对比时，结论并不意外：通用模型在"描述画面内容"这类开放任务上表现尚可，但在"精确读取数值""多物体计数""行业术语输出"上全面落后。差距最大的是价签OCR的字段级F1，通用模型普遍比Ostrakon-VL低了20个百分点以上。这个差距也反向验证了领域专家路线的必要性。

5.3 人工评测与bad case复盘

只看指标会骗人。我们坚持每周做一次bad case复盘，把评测中所有错误样本捞出来人工分类：是OCR漏字、是领域知识错误、还是提示词歧义导致的输出格式错误。一个高频发现是，不少所谓"模型错误"其实出在数据标注端——模型学对了，数据标错了。这类样本修正后重新评测，整体准确率往往能涨一到两个百分点。

这一步的价值是双向的：既磨模型，也磨数据。评测体系的最终目的不是打一个高分交差，而是形成"评测—归因—修正—重测"的飞轮，让数据和模型一起滚起来。

6. 部署落地：量化推理、系统集成与业务兜底

6.1 端云部署取舍与推理优化

部署形态取决于门店的网络和设备条件。有稳定宽带的门店以云端推理为主，模型热更新方便；网络差或者断网时段，边缘端小模型兜底，只上传关键结果。我们在这两条线上都做了实践。

边缘端部署的核心工作是量化。把权重压缩到INT8精度后，模型体积缩减到原来的四分之一左右，单次推理速度明显加快，算力要求也降到了门店边缘设备可以接受的范围。量化带来的精度损失必须用完整评测集复测，我们定的标准是：关键指标下降超过一个百分点就退回高精度方案。另外还专门为了倾斜视角和广角畸变做了数据增强，让模型对非标准机位拍摄的图片也能稳定输出。

6.2 与门店管理系统的集成边界

模型再好，也要嵌进业务流程里才能产生价值。我们把Ostrakon-VL的输出接入了门店现有的管理模块：效期核验结果自动写入货架管理流程，临期商品生成下架或促销任务；SKU盘点结果与库存记录做差异比对，超过阈值自动发送复核工单；价签OCR用于线上菜单和线下价签的一致性巡检。

集成的时候划了一条清晰的边界：模型的输出永远作为"建议"而不是"决策"。所有自动操作前面都加一道规则校验或人工确认环节。原因很朴素——模型在极端场景下（罕见新包装、撕毁一半的标签、全新未录入的SKU）还是会错，业务链路必须能容忍这种小概率错误，绝不能让模型输出直接触发资金操作或安全动作。

6.3 实测中的典型误判与业务兜底

上线后的数据盘点出几类高频误判，写出来给大家做个参考：反光透明瓶身导致OCR把"0"读成"8"，价格字段出问题；多个同系列不同口味的产品相邻摆放，SKU识别互相串味；堆头被顾客的手或身体挡住一部分，计数持续偏低；生鲜熟食的"新鲜度"判断与人工打分差异较大，主观性太强。

针对这些误判，我们做了三层兜底。第一层是置信度阈值，模型输出置信度低于设定值时直接转人工处理，不让低质量结果流入业务流。第二层是多帧融合，让摄像头连拍多帧再做投票或取众数，显著降低单帧偶然误差。第三层是字段级规则校验，OCR出的价格和日期先过正则和范围规则，不符合常识就直接拒绝接收，比如价格超过该类商品合理区间，或者日期格式不符合业务规范。

这套兜底组合上线后，真正抵到业务侧的严重错误比例降了一个数量级。模型依然不是完美的，但业务链路已经不太在意它是不是完美了——因为系统知道怎么和它的不完美共处。

最后再分享一个我的实际体会。做领域专家MLLM，最大的难点其实不在模型本身，而在于能不能把业务场景翻译成一套可训练、可评测、可部署、可兜底的系统工程问题。Ostrakon-VL这个项目走下来，我们反复确认的第一原则是：模型只是整个工程闭环里的一环，数据、标注、评测、部署兜底，哪个环节掉链子，模型再先进也白搭。如果你也在做类似的行业大模型落地，建议从一开始就把这条闭环搭完整，把评测当成头等大事，而不是等训练完了再补课。