当前位置: 首页 > article >正文

leboncoin:微调如何击败RAG

在leboncoin——法国最大的分类广告平台我们每天帮助数百万用户出售他们的物品。广告发布是我们市场的核心这是供应进入平台的关键时刻。当有人列出一部iPhone出售时我们会要求他们填写属性品牌、型号、存储和颜色。这些属性驱动搜索过滤器帮助买家找到他们想要的东西。挑战是什么填写所有这些字段需要时间。这就是认知团队的用武之地。我们是一个专注于通过构建ML和GenAI驱动的服务来使广告创建更快、更顺畅的产品和ML团队以减少卖家工作量并提高广告质量。为了应对这一挑战我们早在2020年就开发了一个机器学习模型一个基于字符n-gram2-5 gram的文本分类器使用简单的神经网络架构标题文本 → CountVectorizer字符n-gram→ Dense(32) → Dropout → Dense每个属性它的优雅之处在于其简单性将标题转换为稀疏的n-gram向量嵌入到32维空间中然后独立地对每个属性进行分类。该模型快速、服务成本低廉在数百万广告上训练并每天重新训练。对于以文本为主的属性它效果显著。如果有人写iPhone 13 Pro 256GB字符n-gram会捕获iPho、“Phon”、“hone”、“13 P”、“Pro”、“256G”、“GB”——这些信号足以可靠地提取品牌Apple、型号iPhone 13 Pro和存储256GB。但颜色是另一回事。我们生产模型在颜色属性上的准确率可以做得更好。标题通常根本没有提到颜色“出售我的iPhone完美状态”或使用模糊的术语“Pacific Blue” vs “Sierra Blue”都是蓝色但具体是哪个。信息就在图像中。人类可以看照片并立即看到手机是蓝色的。但我们的基于文本的模型看不到图像。那时我们决定尝试视觉语言模型。假设很简单如果我们将标题和图像都提供给模型我们应该得到更好的预测特别是对于颜色等视觉属性。1、为什么选择Qwen3-VL-8B我们选择Qwen3-VL-8B作为基础模型认为它是当前最先进的开源VLM。使用该模型的决定基于三个主要因素**法语支持**对于处理我们的广告至关重要。**资源效率**它可以在带有4位量化的单个A10G GPU上运行这是AWS上负担得起且广泛可用的实例。**原生支持结构化提取**由vLLM原生支持引导式JSON解码对我们的用例至关重要。我们还与Claude Haiku 4.5进行了基准测试。我们的基础Qwen实验匹配或超过了专有API证实了领域适应对于此特定任务比原始模型能力更重要。2、现实世界的复杂性多类别、多任务预测在深入我们的实验之前让我向您展示广告参数预测在规模上的实际含义。这不是一个玩具问题。我们支持16个类别每个类别有不同的属性和标签空间高复杂度品牌密集型类别 ------------------------------------------------------------------- | 类别 | 属性数量 | 复杂性说明 | ------------------------------------------------------------------- | 服装 | 6 | 仅品牌就有1,500个 | | 鞋子 | 5 | 700品牌尺寸依赖关系 | | 手机 | 4 | 700型号品牌→型号依赖关系 | | 配饰 | 5 | 200品牌 | ------------------------------------------------------------------- 中等复杂度 --------------------------------------------------------------- | 类别 | 属性数量 | 复杂性说明 | --------------------------------------------------------------- | 婴儿用品 | 3 | ~200品牌 | | 手表 | 4 | 100奢侈和大众市场品牌 | | 家用电器 | 3 | ~75品牌产品类型 | --------------------------------------------------------------- 较低复杂度仍是多标签 -------------------------------------------------------------------- | 类别 | 属性数量 | 说明 | -------------------------------------------------------------------- | 玩具 | 多个 | 品牌较少 | | 自行车 | 多个 | 属性依赖关系 | | 家具 | 多个 | | | 装饰品 | 多个 | | | 电子游戏 | 多个 | | | 游戏机 | 多个 | | --------------------------------------------------------------------总计16个类别中的200唯一属性数千个可能的标签有些类别简单自行车3个属性中的20个标签。其他类别是噩梦服装仅品牌就有1,500个还没算颜色、尺寸、类型…。然后还有依赖关系。在手机中有效型号取决于品牌- 如果phone_brand Apple则phone_model是{iPhone 13, iPhone 13 Pro, iPhone 14, ...}之一42个型号 - 如果phone_brand Samsung则phone_model是{Galaxy S23, Galaxy S24, ...}之一80型号 - 总计24个品牌 × 不同型号 700有效组合但任何给定品牌只有约30个有效这就是我们正在应对的机器学习现实一个多类别、多任务、多标签分类问题具有复杂的层次依赖关系和庞大的标签空间。3、精确匹配我们如何衡量成功以%计在整篇文章中我们使用精确匹配所有属性正确因为部分预测仍需要手动校正。逐属性准确率可能会产生误导在服装上59%的准确率仅转化为6.5%的精确匹配意味着93.5%的预测仍需要用户干预。精确匹配是衡量用户体验的更好指标。在接下来的6周里我们用Qwen尝试了三种不同的方法。以下是有效的方法、无效的方法以及我们为什么希望先尝试微调。4、V0 —— 天真方法把所有东西都放进提示中我们的第一次尝试是最明显的。我们有一个强大的视觉语言模型Qwen3-VL-8B。我们有包含所有有效属性值的标记数据。为什么不直接告诉模型所有选项让它选择我们构建了一个简单的提示系统获取广告标题和图像将每个属性的所有有效值注入提示中要求模型提取正确的值提示看起来像这样你是一个从广告中提取产品属性的助手。 给定这个广告 标题iPhone 13 Pro 256GB excellent état 图像[image1.jpg, image2.jpg] 提取以下属性。仅使用提供的列表中的值。 phone_brand有效值Apple, Samsung, Xiaomi, Huawei, OnePlus, Google, Sony, LG, Nokia, Motorola, OPPO, Vivo, Realme, Honor, Asus, ZTE, Alcatel, Blackberry, HTC, Lenovo, Meizu, Nothing, Fairphone, ... [24个品牌] phone_model有效值iPhone 13, iPhone 13 Mini, iPhone 13 Pro, iPhone 13 Pro Max, iPhone 14, iPhone 14 Plus, iPhone 14 Pro, iPhone 14 Pro Max, iPhone 15, iPhone 15 Plus, iPhone 15 Pro, iPhone 15 Pro Max, Galaxy S23, Galaxy S23, Galaxy S23 Ultra, Galaxy S24, ... [742个型号] phone_memory有效值16GB, 32GB, 64GB, 128GB, 256GB, 512GB, 1TB [8个值] phone_color有效值Noir, Blanc, Bleu, Rouge, Vert, ... [16种颜色] 返回包含提取值的JSON对象。对于手机提示中有790个标签。也许还可以管理。但对于服装呢提示需要列出1,500个服装品牌。不可能。4.1 发生了什么一切都出错了。对于手机等简单类别类别17结果平庸29.5%的精确匹配意味着所有属性正确。这比我们的生产模型37%还差。但对于复杂类别结果是灾难性的-------------------------------------------------------------------------- | 类别 | 属性 | 标签 | V0 提示 | 出了什么问题 | -------------------------------------------------------------------------- | 服装 | 6 | 1600 | 0.0% | 仅品牌就有1500个 | | 装饰品 | 4 | 75 | 0.0% | 模型被选项混淆 | | 玩具 | 3 | 36 | 5.0% | 数量少但仍然失败 | | 儿童家具 | 3 | 237 | 5.6% | 200个婴儿用品品牌 | --------------------------------------------------------------------------零。在服装上模型在200个样本中无法完全正确地做出一个预测。4.2 为什么失败了1. 提示长度爆炸对于服装我们有6个属性需要预测- 品牌1,500标签 - 类别16标签 - 颜色21标签 - 服装类型4标签 - 服装尺寸59标签仅列出品牌名称就会消耗约15,000个token。尽管Qwen3-VL-8B支持128K上下文窗口但我们发现模型很难从1,500个相似的品牌名称中选出正确的选项。大量的选择导致了混淆和幻觉。2. 相似选项混淆了模型当给模型500个手机型号时它开始在相似名称上犯错- iPhone 13 Pro vs iPhone 13 Pro Max - Galaxy S23 vs Galaxy S23 vs Galaxy S23 Ultra - Xiaomi 13 vs Xiaomi 13 Pro vs Xiaomi 13 Ultra模型会选择看起来合理但不完全正确的选项。3. 不理解依赖关系这是一个微妙但关键的问题属性之间存在依赖关系。如果phone_brand Apple则phone_model必须是42个Apple型号之一iPhone 13, iPhone 13 Pro, iPhone 14...。 如果phone_brand Samsung则phone_model必须是80个Samsung型号之一Galaxy S23, Galaxy S24...。有24个品牌每个品牌有自己的有效型号列表总计700个手机型号。但我们简单的提示只是将所有700个型号列在一起。模型有时会预测brand Apple和model “Galaxy S23”这是纯粹的幻觉。或者它会选择一个该品牌不存在的型号。服装更糟糕。clothing_type上衣、下装、套装、其他决定了有效的clothing_st尺寸/样式值。此外大量的品牌标签需要模糊匹配策略在标题中进行类似正则表达式的词搜索以找到最接近的品牌匹配因为我们无法枚举所有有效组合。4.3 我们学到了什么**教训1**将所有标签倒入提示中无法扩展。模型会不堪重负。**教训2**没有显式的依赖关系处理模型会做出不一致的预测。**教训3**仅靠提示工程无法解决复杂的结构化提取问题。我们需要更聪明的方法。5、V1 - 复杂RAG带依赖关系处理的级联2步预测V0失败是因为我们一次向模型抛出所有东西。显而易见的解决方案将问题分解成更小的部分。我们设计了一个带显式依赖关系处理的级联2步预测系统**第1步**首先预测父属性如品牌**第2步**使用父预测过滤有效的子选项如型号然后预测这些选项这需要构建几个组件1. 依赖关系配置我们映射了所有属性之间的父子关系。// 手机类别24个品牌 → 742个型号 { dependencies: [{ master: phone_brand, dependent: phone_model, mapping: { apple: [iphone11, iphone11pro, iphone11promax, iphone12, iphone12mini, iphone12pro, iphone13, iphone13mini, iphone13pro, iphone13promax, iphone14, iphone14plus, iphone14pro, iphone14promax, iphone15, iphone15plus, iphone15pro, iphone15promax, iphone16, iphone16pro, ...], // 42个Apple型号 samsung: [galaxys23, galaxys23plus, galaxys23ultra, galaxys24, galaxys24plus, galaxys24ultra, galaxyzflip5, galaxyzfold5, ...], // 80个Samsung型号 xiaomi: [xiaomi13, xiaomi13pro, xiaomi14, ...], // ... 24个品牌总计742个型号总计 } }]} // 服装类别更复杂 { dependencies: [ { dependent: clothing_brand, strategy: fuzzy_match, // 无法枚举1,503个品牌 short_list: [nike, zara, kiabi, levis, adidas, hm, decathlon, shein, ralphlauren, lacoste, ...] // 使用模糊匹配和常见品牌短列表 }, { master: clothing_type, dependent: clothing_st, mapping: { /* 4种类型 → 59种尺寸 */ } } ] }不仅仅是配置它是编码为数据结构的领域知识。而且必须为16个类别维护有些类别有多个依赖链。2. 两步推理管道# 简化的级联预测流程 async def predict_with_cascade(ad_title: str, images: list[str], category: str): # 第1步获取父属性 parent_attrs get_parent_attributes(category) # 例如 [phone_brand] parent_prompt build_prompt( ad_title, images, attributesparent_attrs, valid_valuesget_all_values(parent_attrs) # 较小的列表 ) parent_predictions await model.predict(parent_prompt) # 结果{phone_brand: Apple} # 第2步获取带过滤选项的子属性 child_attrs get_child_attributes(category) # 例如 [phone_model] # 关键见解基于预测的品牌过滤有效型号 filtered_values filter_by_parent( child_attrs, parent_predictions # 现在只显示Apple型号 ) child_prompt build_prompt( ad_title, images, attributeschild_attrs, valid_valuesfiltered_values, # 只有约50个Apple型号而不是500 contextparent_predictions # 告诉模型品牌是Apple ) child_predictions await model.predict(child_prompt) # 结果{phone_model: iPhone 13 Pro} # 合并结果 return {**parent_predictions, **child_predictions}3. 动态模式生成最后我们还构建了一个模式生成器为依赖字段创建带有oneOf分支的JSON模式def build_schema_with_dependencies(category: str, parent_values: dict): 生成只允许有效组合的JSON模式。 schema {type: object, properties: {}} for attr, parent in get_dependencies(category): parent_value parent_values.get(parent) if parent_value: # 只包含对此父级有效的子值 valid_children dependency_config[attr][parent_value] schema[properties][attr] { type: string, enum: valid_children } return schema架构V1系统看起来是这样的这是一项重大的工程工作 — 约300行依赖配置系统 — 约400行级联预测器 — 约250行动态模式构建器 — 约150行值映射 — 加上测试、边缘情况处理和文档大约3周的工作。5.1 发生了什么好消息V1比V0好得多。----------------------------------------------------- | 类别 | V0 提示 | V1 复杂RAG | 改进 | ----------------------------------------------------- | 手机 | 29.5% | 38.5% | 9.0% | | 服装 | 0.0% | 10.5% | 10.5% | | 装饰品 | 0.0% | 13.5% | 13.5% | | 玩具 | 5.0% | 29.0% | 24.0% | | 电子游戏 | 67.0% | 86.4% | 19.4% | -----------------------------------------------------我们从0%到在困难类别上实际工作。级联方法解决了依赖问题。不再有Apple品牌Galaxy型号的胡言乱语。但也有代价1. 延迟翻倍两次推理调用意味着双倍的时间第1步约300ms第2步约300ms总计约600ms 开销对于实时API来说这很痛苦。2. 维护噩梦每次有新手机型号发布我们都必须更新依赖配置。三星发布了新的Galaxy更新配置。苹果宣布了iPhone 16更新配置。而且配置必须完美。如果我们忘记将某个型号添加到三星列表中系统就永远不会预测它即使模型在标题中清楚地看到了Galaxy S24。3. 到处都是边缘情况如果第1步预测错了品牌怎么办 现在第2步使用了错误的过滤列表。错误会级联。只有一个型号的品牌呢它们仍然需要两步吗循环依赖呢是的有些类别有循环依赖。每个边缘情况都需要特殊处理、更多代码和更多bug。4. 仍然没有击败生产环境令人沮丧的是即使有所有这些复杂性V1在平均水平上只匹配了我们的生产模型。我们在某些类别上击败了它电子游戏86.4% vs 82%但在其他类别上输了手表17.5% vs 25.5%。所有这些工程我们大致是打平了。5.2 我们学到了什么**教训4**级联预测解决了依赖问题但以延迟和复杂性为代价。**教训5**基于配置的方法创造了维护负担。每个新产品都需要手动更新。**教训6**3周的工程来匹配不是击败现有解决方案ROI不好。我们需要更简单的东西可以自动学习依赖关系。6、V2 —— 简单的解决方案如果只是微调呢在构建级联系统数周后我们有了一个认识模型不需要我们告诉它iPhone是Apple制造的。它可以从例子中学习。想想看。在我们的训练数据中每次模型看到iPhone 13 Pro标签都写着品牌Apple型号iPhone 13 Pro。每次它看到Galaxy S24标签都写着品牌Samsung型号Galaxy S24。给模型展示数千个这样的例子它就会学到这个模式。不需要配置文件。不需要依赖解析器。不需要两步骤联。品牌和型号之间的关系不是我们需要工程化的。而是模型可以学习的东西。6.1 我们尝试了什么所以我们决定使用LoRA和Unsloth构建微调管道1. 数据集准备我们从数据库中采样了真实广告 — 16个类别 — 每个类别约200个例子 — 每个例子标题、图像、真实属性我们将它们格式化为法语的聊天风格对话{ messages: [ { role: system, content: Tu extrais les attributs produits à partir du titre et de limage. Réponds en JSON valide uniquement. }, { role: user, content: [ {type: image, image: image_base64_data}, {type: text, text: Catégorie: Téléphones\nTitre: \iPhone 13 Pro 256GB Bleu Pacifique excellent état\\n\nExtrais: phone_brand, phone_model, phone_memory, phone_color} ] }, { role: assistant, content: {\phone_brand\: \Apple\, \phone_model\: \iPhone 13 Pro\, \phone_memory\: \256GB\, \phone_color\: \Bleu\} } ] }2. LoRA微调我们使用Unsloth进行高效微调from unsloth import FastVisionModel from trl import SFTTrainer, SFTConfig model, tokenizer FastVisionModel.from_pretrained( Qwen/Qwen3-VL-8B-Instruct, load_in_4bitTrue, # 适合单个A10G GPU ) model FastVisionModel.get_peft_model( model, r16, # LoRA秩 lora_alpha32, # 缩放因子 target_modules[ # 要适配哪些层 q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj ], ) trainer SFTTrainer( modelmodel, train_datasettrain_data, eval_datasetval_data, argsSFTConfig( num_train_epochs3, per_device_train_batch_size2, gradient_accumulation_steps8, learning_rate2e-4, warmup_steps50, eval_strategysteps, eval_steps100, save_strategysteps, save_steps100, load_best_model_at_endTrue, ), callbacks[EarlyStoppingCallback(early_stopping_patience3)], )训练时间单个A10G GPU约1小时。就是这样。没有依赖配置。没有级联逻辑。没有值映射器。3. 带引导式解码的推理对于服务我们使用带有JSON模式约束的vLLMfrom openai import AsyncOpenAI client AsyncOpenAI(base_urlhttp://localhost:8000/v1) response await client.chat.completions.create( modelfine-tuned-qwen, messages[ {role: system, content: system_prompt}, {role: user, content: user_content_with_images} ], extra_body{ guided_json: json_schema_for_category # 枚举约束 } )引导式解码确保有效的JSON输出值来自我们的枚举列表——99%以上的有效响应率。架构组件1个模型 推理调用1次 配置文件0 维护需要时重新训练6.2 发生了什么结果让我们惊讶------------------------------------------------- | 类别 | 复杂RAG | 微调V2 | 差值 | ------------------------------------------------- | 手机 | 38.5% | 49.5% | 11.0 | | 家用电器 | 62.0% | 72.0% | 10.0 | | 服装 | 10.5% | 16.5% | 6.0 | | 玩具 | 29.0% | 40.0% | 11.0 | | 自行车 | 14.0% | 26.5% | 12.5 | | 平板电脑 | 50.5% | 57.5% | 7.0 | | 游戏机 | 86.4% | 87.5% | 1.1 | -------------------------------------------------微调在16个类别中的10个中获胜。而且胜利是显著的通常有10%的改进。结果表----------------------------------------------------------------------- | 类别 | 生产 | Haiku | V0 | V1 RAG | V2 FT (Δ vs V1)| ----------------------------------------------------------------------- | 手机 | 37.0% | 27.0% | 29.5% | 38.5% | 49.5% (11.0%) | | 家用电器 | 67.0% | 29.0% | 50.0% | 62.0% | 72.0% (10.0%) | | 服装 | 6.5% | 6.0% | 0.0% | 10.5% | 16.5% (6.0%) | | 婴儿用品 | 29.5% | 16.0% | 39.5% | 42.5% | 44.5% (2.0%) | | 装饰品 | 18.0% | 14.0% | 0.0% | 13.5% | 17.0% (3.5%) | | 玩具 | 46.5% | 18.0% | 5.0% | 29.0% | 40.0% (11.0%) | | 手表 | 25.5% | 7.0% | 19.0% | 17.5% | 17.5% (0.0%) | | 电子游戏 | 82.0% | 83.0% | 67.0% | 86.4% | 80.0% (-6.4%) | | 自行车 | 32.5% | 13.0% | 13.5% | 14.0% | 26.5% (12.5%) | | 儿童房家具 | 27.3% | 19.0% | 5.6% | 22.4% | 26.6% (4.2%) | | 平板电脑 | 40.5% | 51.0% | 12.0% | 50.5% | 57.5% (7.0%) | | 游戏机 | 80.5% | 85.4% | 79.0% | 86.4% | 87.5% (1.1%) | ----------------------------------------------------------------------- | 平均值 | 34.9% | 24.3% | 22.4% | 34.6% | 37.7% (3.1%) | -----------------------------------------------------------------------图例 V0 天真提示所有标签在提示中1周工程 V1 复杂提示级联2步3周工程 V2 微调1小时训练1周工程 (X.X%) 与V1复杂RAG的差值6.3 为什么微调赢了1. 依赖关系是学习的不是配置的模型看到了数千个iPhone与品牌Apple一起出现的例子。它学到了这个模式。我们不需要告诉它。当V2看到一个带有iPhone 15 Pro Max的新广告时它会自动预测品牌Apple即使我们从未在任何配置中明确列出该型号。2. 单次推理调用V1需要两次调用父→子。V2只需要一次。约40%更快。3. 没有配置漂移当三星发布新手机时V1需要配置更新。V2只需要在下一个训练批次中看到该手机的例子这会随着用户列出新产品而自然发生。4. 模型学习视觉模式这是微妙的一点。V1的级联系统在根本上仍然是基于文本的图像作为上下文。V2是在标题图像→属性上端到端训练的。微调后的模型学会了真正看图像。对于颜色属性我们最初的动机这产生了巨大的差异。6.4 我们学到了什么**教训7**微调可以隐式学习依赖关系。不需要工程化它们。**教训8**1小时的训练可以替代3周的架构。**教训9**简单的解决方案往往胜过聪明的工程。7、工程投入比较老实说每种方法的成本是多少-------------------------------------------------------------- | 方法 | 工程时间 | 代码量 | 维护 | 准确率 | -------------------------------------------------------------- | V0 天真提示 | ~1周 | ~200行 | 低 | 22.4% | | V1 复杂RAG | ~3周 | ~1100 500c | 高 | 34.6% | | V2 微调 | ~1周 | ~1300行 | 低 | 37.7% | --------------------------------------------------------------V2需要与V1类似的代码数据集准备、训练循环、推理但是 — 没有依赖配置文件 — 没有级联编排逻辑 — 没有值映射层 — 没有两步推理的边缘情况处理而且关键是没有持续的配置维护。8、何时使用每种方法微调并不总是答案。以下是我们的框架使用天真提示V0当你在原型设计且需要快速得到结果时标签空间小每个属性50个选项你没有训练数据使用复杂RAGV1你需要可解释性“模型因为检索到的例子Y而选择了X”无法获得训练数据标签每天都在变化重新训练不可行你负担不起GPU训练使用微调V2你有标记的训练数据我们有6个月的标记广告准确率是优先考虑的你想要更简单的部署和维护你可以定期重新训练每月、每季度属性之间存在依赖关系对于我们的用例——具有稳定但庞大标签集和大量训练数据的结构化属性提取微调是明显的赢家。9、为什么生产模型在某些类别上仍然获胜查看我们的结果有趣的是生产的n-gram模型在某些类别上仍然击败了我们的微调VLM--------------------------------------------- | 类别 | 标签 | 生产 | V2 FT | 获胜者 | --------------------------------------------- | 电子游戏 | 88 | 82.0 | 80.0 | 生产 | | 手表 | 184 | 25.5 | 17.5 | 生产 | | 玩具 | 36 | 46.5 | 40.0 | 生产 | | 家具 | 80 | 23.0 | 19.5 | 生产 | ---------------------------------------------为什么简单的字符n-gram分类器在这些类别上能胜过8B参数的VLMn-gram模型的秘密武器结构化文本上的模式匹配生产模型使用带有字符n-gram2-5的CountVectorizer进行结构化文本上的模式匹配在具有可预测标题格式的类别中证明非常有效。例如在电子游戏类别88个标签中结构化标题如FIFA 24 PS5 neuf sous blister允许模型捕获PS5、“FIFA”、24和neuf等n-gram准确识别游戏机品牌、型号和游戏类型。模型的数百万个学习模式立即将PS5等术语与Sony关联起来高效处理有限的品牌和型号集合。同样在手表类别184个标签中品牌密集的标题如Montre Rolex Submariner homme automatique产生品牌指示性n-gram“Rolex”、“Subm”可以在138个常提到的手表品牌中立即识别品牌和类型通常不需要图像。VLM何时获胜视觉信息和庞大的标签空间微调的VLM在n-gram模型挣扎的地方表现出色**手机**V2获胜49.5% vs 37.0%790个标签。视觉区分处理颜色、型号变体如Pro/Pro Max相机布局并克服了标题中742个相似字符模式的混淆。**家用电器**V2获胜72.0% vs 67.0%129个标签。品牌标志Dyson、Samsung、LG和产品类型在视觉上通常比描述更清晰。**服装**V2获胜16.5% vs 6.5%1,600标签。n-gram在这里失败。颜色和风格休闲、正式几乎总是视觉的标志识别了许多1,500个标题中没有的品牌。**自行车**V2略输26.5% vs 32.5%20个标签。视觉分类通过车架几何形状确定自行车类型VTT、公路、城市有时从车架确定尺寸。10、见解文本密度 标签空间大小我们可以根据两个因素粗略预测哪个模型会获胜根据文本密度和标签空间选择正确的模型示例 “FIFA 24 PS5 neuf” → N-gram所有信息都在文本中标签空间小 “Montre Rolex Submariner” → N-gram品牌在标题中标签适中 “iPhone bon état” [图像] → VLM颜色/型号在图像中742个型号可选 “Robe été” [图像] → VLM品牌/颜色在图像中1,500个品牌混合机会这种分析暗示了一种潜在的混合方法 — 对于文本密度高的类别电子游戏、手表、游戏机使用快速、廉价的n-gram模型 — 对于视觉信息重要的低文本密度类别服装、手机、电器使用VLM基于类别的路由器可以获得两全其美在文本足够时使用n-gram速度在图像重要时使用VLM准确率。11、下一步是什么这还不是最终的生产模型。我们一直在将微调的VLM与内部的多模态变压器架构进行挑战该架构融合了文本n-gram和视觉嵌入它实际上表现得非常好。简单微调VLM与定制轻量级融合模型之间的战斗仍在进行中。请继续关注下一篇博文我们将深入比较这两种方法并揭示哪种方法进入了生产环境。关键要点从简单开始但要准备好尝试微调。我们的V0是正确的第一个实验。但我们应该在构建V1的复杂性之前尝试微调。依赖关系可以学习而不是工程化。1小时的训练教会了模型500行配置试图编码的内容。复杂架构有隐藏成本。V1有效但维护负担不可持续。训练数据 聪明的提示。模型从10K例子中学到的比从我们精心设计的提示中学到的多。简单的解决方案往往获胜。V2的架构装在一个盒子里。V1的有七个组件。V2赢了。最好的代码往往是你不写的代码。有时最聪明的工程决策是让模型学习而不是试图通过架构来教它原文链接leboncoin微调如何击败RAG - 汇智网

相关文章:

leboncoin:微调如何击败RAG

在leboncoin——法国最大的分类广告平台,我们每天帮助数百万用户出售他们的物品。广告发布是我们市场的核心,这是供应进入平台的关键时刻。当有人列出一部iPhone出售时,我们会要求他们填写属性:品牌、型号、存储和颜色。这些属性驱…...

SpringCloud实战:Resilience4j断路器与舱壁隔离的深度解析

1. Resilience4j断路器实战指南 第一次接触Resilience4j断路器是在去年双十一大促期间,当时我们的订单服务突然出现大面积超时,导致整个电商系统几乎瘫痪。后来分析发现是支付服务响应缓慢,但订单服务仍然持续调用支付接口,最终拖…...

Pixel Dimension Fissioner生产环境实践:日均万次调用下的稳定性与GPU优化策略

Pixel Dimension Fissioner生产环境实践:日均万次调用下的稳定性与GPU优化策略 1. 项目背景与挑战 Pixel Dimension Fissioner是一款基于MT5-Zero-Shot-Augment核心引擎构建的高端文本改写工具,其独特的16-bit像素冒险工坊设计风格为用户提供了全新的交…...

OFA图像英文描述模型在微信小程序开发中的应用:智能图片标注实战

OFA图像英文描述模型在微信小程序开发中的应用:智能图片标注实战 为微信小程序添加智能图片理解能力,让用户上传的每张图片都能自动生成准确的英文描述 1. 项目背景与需求场景 在跨境电商和旅游导览这类小程序里,用户经常需要上传商品图片或…...

Golang实战速成:从零构建高并发微服务

1. 为什么选择Golang构建高并发微服务 第一次接触Golang是在2014年,当时团队需要重构一个日活百万的推送系统。用Java写的旧系统在高并发场景下频繁GC卡顿,而改用Go后,不仅吞吐量提升了3倍,内存占用还降低了60%。这段经历让我深刻…...

Pixel Dimension Fissioner可部署方案:私有化部署保障企业文案数据安全

Pixel Dimension Fissioner可部署方案:私有化部署保障企业文案数据安全 1. 企业数据安全新选择 在数字化内容创作时代,企业文案数据安全已成为不可忽视的核心需求。Pixel Dimension Fissioner(像素语言维度裂变器)作为基于MT5-Z…...

Cosmos-Reason1-7B处理长文本技术详解:上下文窗口管理与关键信息提取

Cosmos-Reason1-7B处理长文本技术详解:上下文窗口管理与关键信息提取 你是不是也遇到过这样的烦恼?面对一份几十页的技术报告或者一份复杂的法律合同,想要快速找到某个关键条款或者理解其中的核心结论,却不得不花上大半天时间从头…...

Win7虚拟机下UltraISO找不到虚拟光驱?3步搞定镜像加载问题

Win7虚拟机下UltraISO虚拟光驱识别难题的深度解决方案 在虚拟化技术广泛应用的今天,许多开发者依然需要在Windows 7虚拟机环境中处理ISO镜像文件。UltraISO作为老牌光盘映像工具,其虚拟光驱功能在物理机上表现稳定,但在VMware虚拟机环境中却常…...

Arduino嵌入式日志框架:零堆分配与编译期裁剪设计

1. 项目概述ArduinoLog 是一款专为 Arduino 及兼容嵌入式平台设计的轻量级 C 日志框架,其核心目标是在资源受限的微控制器环境中提供高可控性、零动态内存分配、低运行时开销的日志能力。它并非简单封装Serial.print()的工具,而是借鉴 log4j、log4cpp 等…...

TGX嵌入式图形库:轻量级2D/3D帧缓冲渲染引擎

1. TGX图形库概述 TGX(Tiny Graphics eXtended)是一个专为资源受限嵌入式平台设计的轻量级C图形库,其核心目标是在32位微控制器上实现高性能2D/3D图形渲染,同时保持极低的内存占用与确定性执行时间。与传统GUI框架不同&#xff0…...

Mirage Flow 在计算机网络教学中的应用:模拟协议交互与故障排查

Mirage Flow 在计算机网络教学中的应用:模拟协议交互与故障排查 计算机网络这门课,教起来挺费劲的。我见过不少学生,对着课本上TCP三次握手的示意图,眉头紧锁,嘴里念叨着“SYN, SYN-ACK, ACK”…...

Qwen3-14B-Int4-AWQ入门:Visio技术架构图自动生成与说明文档撰写

Qwen3-14B-Int4-AWQ入门:Visio技术架构图自动生成与说明文档撰写 1. 引言:架构师的绘图烦恼 每个技术架构师都经历过这样的痛苦时刻:面对复杂的系统设计,需要在Visio中手动绘制数十个组件和连接线,调整布局到深夜&am…...

避坑指南:为什么你的xxxConfig.cmake总让find_package失败?这些细节90%的人会忽略

避坑指南:为什么你的xxxConfig.cmake总让find_package失败?这些细节90%的人会忽略 在CMake生态中,find_package机制是模块化构建的基石,而xxxConfig.cmake文件的质量直接决定了第三方集成的成败。许多开发者投入数小时调试构建失败…...

Hunyuan-MT-7B-WEBUI优化升级:CPU/GPU推理配置建议与性能调优指南

Hunyuan-MT-7B-WEBUI优化升级:CPU/GPU推理配置建议与性能调优指南 1. 引言:为什么需要性能调优? 在机器翻译的实际应用中,我们常常面临一个关键问题:如何在有限的硬件资源下获得最佳的翻译性能?Hunyuan-M…...

DigiPIN嵌入式地理编码库:轻量级WGS-84到10字符坐标转换

1. DigiPIN 库概述:面向嵌入式地理编码的轻量级坐标转换引擎DigiPIN 是一个专为资源受限嵌入式平台设计的轻量级地理编码库,其核心功能是将标准 WGS-84 坐标系下的经纬度浮点数值(double类型)精确、可逆地编码为印度邮政&#xff…...

CYBER-VISION零号协议快速入门:Ubuntu 20.04系统下的环境部署详解

CYBER-VISION零号协议快速入门:Ubuntu 20.04系统下的环境部署详解 最近有不少朋友在问,怎么在Ubuntu系统上快速把CYBER-VISION零号协议跑起来。这个开源模型在视觉理解方面表现挺不错的,但第一次部署可能会遇到些小麻烦,比如驱动…...

3分钟快速上手:用AI为你的音频视频自动生成精准字幕的完整指南

3分钟快速上手:用AI为你的音频视频自动生成精准字幕的完整指南 【免费下载链接】openlrc Transcribe and translate voice into LRC file using Whisper and LLMs (GPT, Claude, et,al). 使用whisper和LLM(GPT,Claude等)来转录、翻译你的音频为字幕文件。…...

嵌入式轻量级菜单框架设计与实现

1. 菜单框架设计原理与工程实现在嵌入式人机交互系统中,液晶显示屏(LCD)作为最基础的用户界面载体,其UI开发长期面临结构松散、逻辑耦合、复用性差等工程痛点。传统做法往往采用硬编码方式逐页绘制界面、逐键处理事件,…...

OmenSuperHub:硬件控制的开源解决方案

OmenSuperHub:硬件控制的开源解决方案 【免费下载链接】OmenSuperHub 项目地址: https://gitcode.com/gh_mirrors/om/OmenSuperHub OmenSuperHub是一款专为惠普暗影精灵系列笔记本设计的开源硬件控制工具,旨在解决传统Omen Gaming Hub存在的三大…...

gte-base-zh模型部署常见问题:403 Forbidden等错误排查与解决

gte-base-zh模型部署常见问题:403 Forbidden等错误排查与解决 部署和调用模型时遇到错误,就像开车时突然亮起的故障灯,让人瞬间紧张。尤其是当你满怀期待地准备测试一个文本向量化模型,却迎面撞上冷冰冰的“403 Forbidden”时&am…...

电商人必看!RMBG-2.0一键抠商品图,1秒换透明底

电商人必看!RMBG-2.0一键抠商品图,1秒换透明底 1. 为什么电商人需要RMBG-2.0? 每天处理上百张商品图是电商运营的日常。传统抠图方法要么费时(Photoshop手动抠图),要么粗糙(在线工具边缘锯齿&…...

Ostrakon-VL-8B开箱体验:对比本地部署与云平台一键部署的复杂度

Ostrakon-VL-8B开箱体验:对比本地部署与云平台一键部署的复杂度 最近想试试这个叫Ostrakon-VL-8B的模型,听说它看图说话的本事挺厉害。作为一个普通用户,我的第一反应就是把它装在自己电脑上跑跑看。但很快我就发现,事情没那么简…...

Bonezegei_SoftSerial:嵌入式软件串口的工程化实践与稳定边界

1. 项目概述Bonezegei_SoftSerial 是一个面向嵌入式平台的轻量级软件串口(Software UART)实现库,专为资源受限或硬件 UART 资源不足的场景设计。其核心目标并非替代硬件 UART,而是在特定约束条件下提供可预测、可配置、工程可用的…...

OpenClaw 是什么?普通人的 AI 贴身助理

你有没有想过,有一个 24 小时在线、随叫随到、什么都会的私人助理?OpenClaw 正在让这件事变成现实——而且它就运行在你自己的电脑上。先说一个真实的场景 早上 8 点,你还没起床,手机上发了一条消息:“帮我看看今天有没…...

Arduino电压基准库:精准测量Vcc实现ADC自校准

1. 项目概述VoltageReference是一个专为 Arduino 平台设计的轻量级电压基准库,其核心目标是精确获取 MCU 供电电压(Vcc)的真实值,并以此为基础提升模拟量采集的绝对精度。该库不依赖任何外部硬件连接,完全利用 Atmel A…...

李慕婉-仙逆-造相Z-Turbo 黑马点评项目AI升级实战:智能推荐与评论情感分析

李慕婉-仙逆-造相Z-Turbo 黑马点评项目AI升级实战:智能推荐与评论情感分析 不知道你有没有遇到过这种情况:打开一个点评类应用,首页推荐的店铺好像总是那么几家,推荐的“理由”也千篇一律,写着“人气爆棚”、“口味正…...

如何快速解锁加密音乐:终极免费工具完全指南

如何快速解锁加密音乐:终极免费工具完全指南 【免费下载链接】unlock-music 在浏览器中解锁加密的音乐文件。原仓库: 1. https://github.com/unlock-music/unlock-music ;2. https://git.unlock-music.dev/um/web 项目地址: https://gitcod…...

Phi-3-mini-128k-instruct安全部署:访问控制与API密钥管理

Phi-3-mini-128k-instruct安全部署:访问控制与API密钥管理 把AI模型部署上线,让它能对外提供服务,这只是第一步。接下来,一个更现实、也更关键的问题就摆在了面前:怎么保证这个服务是安全的? 想象一下&am…...

别再被‘几核几线程’忽悠了!聊聊超线程技术到底怎么用,以及什么时候该关掉它

超线程技术实战指南:如何根据需求智能开启或关闭 1. 超线程的本质与日常影响 每次选购电脑或升级硬件时,"几核几线程"的参数总是让人眼花缭乱。商家喜欢用"4核8线程"这样的标注吸引眼球,但实际使用中,超线程技…...

浸没式液冷储能:数据中心如何用‘液体泡澡’省下百万电费?

浸没式液冷储能:数据中心如何用‘液体泡澡’省下百万电费? 当数据中心的电费账单成为运营成本中的"头号杀手",一场关于热管理的技术革命正在悄然发生。想象一下,将服务器浸泡在特殊液体中,就像给电子设备做S…...