深入了解一个端到端的机器学习项目，旨在提升 Open Food Facts 数据库的质量。
https://medium.com/@jeremyarancio?source=post_page---byline--d74dfe02e0e4--------------------------------https://towardsdatascience.com/?source=post_page---byline--d74dfe02e0e4-------------------------------- Jeremy Arancio
·发表于Towards Data Science ·阅读时间：13 分钟·2024 年 10 月 6 日
–
使用 Flux1 生成的图像
Open Food Facts 的目标是创建全球最大的开源食品数据库。至今，它已经收录了超过 300 万种产品及其相关信息，得益于社区贡献者的帮助。
营养价值、生态评分、产品来源……各种定义每个产品的数据，为消费者和研究人员提供关于他们所放置在餐盘上的食品的深刻见解。
这些信息由用户和贡献者社区提供，他们通过移动应用积极添加产品数据、拍照，并填写数据库中任何缺失的数据。
使用产品图片，Open Food Facts 通过光学字符识别（OCR）技术提取通常位于包装背面的成分列表。然后对产品成分进行解析并将其添加到数据库中。
产品包装上的成分列表
然而，文本提取过程往往并不顺利……
Ingrédients: Jambon do porc, sel, dextrose, arôme naturels, antioxydant: E316, conservateur: E250
^
这些拼写错误看起来可能微不足道，但当成分列表被解析以提取单个成分时，此类错误会导致无法识别的成分，从而影响数据库的质量。光线反射、包装折叠、低质量图片等因素都使得成分解析过程变得更加复杂。
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/dd0d3821089e8b68007112d12a755161.pnghttps://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/6074f6e9c6d559cc94eab9cbd049ab7f.png
OCR 失败的包装图片示例（来自 Open Food Facts 数据库）
Open Food Facts 多年来一直尝试使用正则表达式和现有解决方案（如 Elasticsearch 的校正器）来解决这个问题，但未成功。直到最近。
感谢人工智能的最新进展，我们现在可以使用强大的大语言模型（Large Language Models），也称为LLMs。
通过训练我们自己的模型，我们创建了成分拼写检查，不仅在这个任务上超越了如GPT-4o或Claude 3.5 Sonnet等专有 LLM，而且还将数据库中未识别的成分数量减少了11%。
本文将带您了解项目的不同阶段，并展示我们如何利用机器学习提高数据库质量。
享受阅读！
定义问题
当一个产品由贡献者添加时，它的图片会经过一系列过程以提取所有相关信息。其中一个关键步骤是提取成分列表。
当一个词被识别为成分时，它会与包含预定义成分列表的分类法进行交叉引用。如果该词与分类法中的某个条目匹配，它就会被标记为成分并添加到产品信息中。
这个标签化过程确保了成分的标准化，且易于搜索，为消费者和分析工具提供准确的数据。
但是，如果某个成分未被识别，过程就会失败。
成分“Jambon do porc”（猪肉火腿）未被解析器识别（来自产品编辑页面）
因此，我们在过程中过引入了一个额外的层次：成分拼写检查，旨在在成分解析器处理之前修正成分列表。
一种更简单的方法是Peter Norvig 算法，它通过应用一系列字符删除、添加和替换操作来处理每个单词，从而识别潜在的拼写纠正。
然而，由于几个原因，这种方法证明对我们的用例不够充分：
-
特殊字符和格式：诸如逗号、括号和百分号等元素在成分列表中具有重要作用，影响产品组成和过敏原标签*(例如，“盐（1.2%）”)。*
-
多语言挑战：数据库包含来自世界各地的产品，语言种类繁多。这进一步使得像诺尔维格的字符基础方法那样的语言无关的方法变得复杂。
相反，我们转向了机器学习的最新进展，特别是大语言模型（LLMs），它们在包括拼写纠正在内的各种**自然语言处理（NLP）**任务中表现优异。
这是我们决定采取的路径。
评估
你无法改善你无法衡量的东西。
什么是好的更正？如何衡量更正者的性能，LLM 或非 LLM？
我们的第一步是理解并分类成分解析器遇到的各种错误。
此外，评估错误是否应该被更正也是至关重要的。有时，试图更正错误可能会适得其反：
flour, salt (1!2%)
# Is it 1.2% or 12%?...
基于这些原因，我们创建了拼写检查指南，这是一套限制更正范围的规则。这些指南将在项目的各个阶段为我们提供帮助，从数据集生成到模型评估。
该指南特别用于创建拼写检查基准，这是一个经过精心策划的数据集，包含大约 300 个手动更正的成分列表。
这个基准是项目的基石。它使我们能够在我们的用例中评估任何解决方案，无论是机器学习还是简单的启发式方法。
它与评估算法一起使用，这是我们开发的自定义解决方案，能够将一组更正转化为可度量的指标。
评估算法
大多数现有的文本相关任务评估算法通过计算参考与预测之间的相似性来评估性能，例如用于语言翻译或总结的BLEU或ROUGE分数。
然而，在我们的案例中，这些指标并不完全适用。
我们希望评估拼写检查算法如何识别和修正成分列表中的正确单词。因此，我们将精确度和召回率指标适配到我们的任务中：
精确度 = 模型正确更正的单词数 / 模型所做的总更正数
召回率 = 模型正确更正的单词数 / 错误总数
然而，我们没有细粒度的视角来查看哪些单词应该被更正……我们只能访问：
-
原始数据：数据库中现有的成分列表；
-
参考数据：我们期望这个列表被更正的方式；
-
预测：模型的更正。
是否有方法计算被正确更正的错误数、拼写检查未能更正的错误，以及最终被错误更正的错误数？
答案是肯定的！
Original: "Th cat si on the fride,"
Reference: "The cat is on the fridge."
Prediction: "Th big cat is in the fridge."
根据上述示例，我们可以轻松地找出应该被更正的单词：The、is 和 fridge；以及哪些单词被错误更正：on 被更正为 in。最后，我们看到添加了一个额外的单词：big。
如果我们将这三组序列配对对齐：original-reference 和 original-prediction，我们可以检测出哪些单词应该被更正，哪些没有被更正。这种对齐问题在生物信息学中是典型的，称为序列对齐，其目的是识别相似性区域。
这是我们拼写检查评估任务的完美类比。
Original: "Th - cat si on the fride,"
Reference: "The - cat is on the fridge."
1 0 0 1 0 0 1
Original: "Th - cat si on the fride,"
Prediction: "Th big cat is in the fridge."
0 1 0 1 1 0 1
FN FP TP FP TP
通过为每一对标注0或1，表示单词是否发生了变化，我们可以计算模型正确修正错误的次数**（真正例 — TP）、错误改变了正确单词的次数（假正例 — FP），以及漏掉应该修正的错误的次数（假负例 — FN）**。
换句话说，我们可以计算拼写检查的精确度和召回率！
我们现在拥有一个强大的算法，能够评估任何拼写检查解决方案！
你可以在项目仓库中找到该算法。
大型语言模型
大型语言模型（LLMs）已被证明在各个行业中处理自然语言任务时提供了极大的帮助。
它们构成了我们必须为使用案例探索的路径。
许多 LLM 供应商在排行榜上炫耀他们模型的表现，但它们在修正配料清单中的错误表现如何呢？因此，我们对它们进行了评估！
我们使用我们的自定义基准测试和评估算法，评估了OpenAI的GPT-3.5和GPT-4o、Anthropic的Claude-Sonnet-3.5以及Google的Gemini-1.5-Flash。
我们提供了详细的指令，以便将修正方向定向到我们的自定义指南。
LLM 在我们的基准测试上的评估（图来自作者）
GPT-3.5-Turbo在指标和人工评审方面都提供了最好的性能，优于其他模型。特别提到的是Claude-Sonnet-3.5，它在修正错误方面表现出色（高召回率），但常常提供额外的无关解释，降低了其精确度。
太好了！我们有了一个有效的 LLM！是时候在应用程序中创建这个功能了！
好吧， 别急…
使用私有 LLM 会带来许多挑战：
-
缺乏所有权：我们变得依赖于供应商及其模型。新版本的模型频繁发布，改变了模型的行为。这种不稳定性，主要是因为该模型设计是为了通用目的，而非针对我们特定的任务，从而使长期维护变得复杂。
-
模型删除风险：我们没有防范措施来应对供应商删除旧模型的情况。例如，尽管 GPT-3.5 是完成此任务的最佳模型，但它正逐渐被更高效的模型替代！
-
性能限制：私有 LLM 的性能受限于其提示。换句话说，我们改进输出的唯一方式是通过更好的提示，因为我们无法通过在我们自己的数据上训练来修改模型的核心权重。
基于这些原因，我们选择将精力集中在开源解决方案上，这将使我们能够完全控制并超越通用 LLM。
训练我们自己的模型
模型训练工作流程：从数据集提取到模型训练（图来自作者）
任何机器学习解决方案都始于数据。在我们的案例中，数据就是经过修正的配料列表。
然而，并非所有的配料列表都是一样的。有些列表没有未识别的配料，而有些则难以阅读，甚至没有必要纠正它们。
因此，我们通过选择包含10%到 40%未识别配料的配料列表找到了一个完美的平衡。我们还确保数据集内没有重复项，并且与基准数据也没有重复，以防在评估阶段出现数据泄漏。
我们使用DuckDB从 Open Food Facts 数据库中提取了 6000 个未修正的列表，DuckDB 是一个快速的进程内 SQL 工具，能够在一秒钟内处理数百万行数据。
然而，这些提取的列表还没有被纠正，手动标注它们将需要大量时间和资源……
然而，我们可以访问已经在相同任务上进行评估的 LLMs。因此，我们提示 GPT-3.5-Turbo，这是我们基准上的最佳模型，按照我们的指南修正每一个列表。
该过程用了不到一个小时，费用几乎为2$。
然后，我们使用Argilla手动审查数据集，Argilla 是一个开源标注工具，专门用于自然语言处理任务。这个过程确保数据集质量足够高，以训练出可靠的模型。
现在我们手头有一个 训练数据集 和一个 评估基准 ，可以用来训练我们自己的拼写检查模型。
训练
对于这一阶段，我们决定使用序列到序列语言模型。换句话说，这些模型以文本作为输入，并返回文本作为输出，适合拼写检查的过程。
有几种模型适合这个角色，例如T5 系列，由谷歌于 2020 年开发，或当前的开源 LLMs，如Llama和Mistral，它们专为文本生成和执行指令而设计。
模型训练包括一系列步骤，每个步骤都需要不同的资源分配，例如云 GPU、数据验证和日志记录。出于这个原因，我们决定使用Metaflow来协调训练，它是一个专为数据科学和机器学习项目设计的管道编排工具。
训练管道的组成如下：
-
配置和超参数是从配置的 YAML 文件导入到管道中的；
-
训练任务通过AWS Sagemaker在云端启动，使用一组模型超参数和自定义模块（如评估算法）。一旦任务完成，模型工件将存储在 AWS S3 桶中。所有训练细节都通过Comet ML进行跟踪；
-
然后使用评估算法在基准上评估微调后的模型。根据模型的大小，这个过程可能非常漫长。因此，我们使用了vLLM，一个旨在加速 LLM 推理的 Python 库；
-
针对基准的预测结果，存储在 AWS S3 中，发送到Argilla进行人工评估。
在多次迭代数据精炼和模型训练之后，我们在拼写检查任务上达到了与专有 LLM 相媲美的性能，F1 分数为0.65。
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/7fdb68e96e8e460f5871149e4f6a61df.pnghttps://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/407f381cc9c76a371fa2ee8a89f453ca.png
LLMs 在我们基准上的评估（图像来源：作者）
该模型是微调后的Mistral-7B-Base-v0.3，可在 Hugging Face 平台上获取，并且是公开可用的，连同其数据集和评估基准。
[## openfoodfacts/spellcheck-mistral-7b · Hugging Face
我们正在努力通过开源和开放科学推动并普及人工智能。
huggingface.co](https://huggingface.co/openfoodfacts/spellcheck-mistral-7b?source=post_page-----d74dfe02e0e4--------------------------------)
此外，我们估计拼写检查减少了 11%的未识别成分，这很有前景！
现在进入项目的最后阶段：将模型集成到 Open Food Facts 中。
部署与集成
我们的模型很大！
70 亿个参数，这意味着在float16格式下运行时需要14 GB内存，还不包括20%的开销因子。
此外，大型模型通常意味着推理期间吞吐量低，这可能使其不适合实时服务。我们需要配备大内存的 GPU 来在生产环境中运行该模型，例如Nvidia L4，其配备了 24GB 的显存。
但在云端运行这些实例的成本相当昂贵……
然而，提供实时体验的可能性，而不需要 24/7 运行 GPU 实例，就是批处理推理。
成分列表定期通过模型进行批处理处理，然后存储在数据库中。这样，我们只需为批处理过程中使用的资源付费！
批处理作业
我们开发了一个批处理系统，通过Google Batch Job高效地处理大规模文本处理任务。
批处理系统（图像来源：作者）
该过程首先通过使用 DuckDB 从 Open Food Facts 数据库提取数据，在不到 2 分钟的时间内处理 43GB 的数据！
提取的数据随后发送到 Google Bucket，触发 Google 批处理作业。
该作业使用一个预先准备的 Docker 镜像，包含所有必要的依赖项和算法。为了优化资源密集型的 LLM 处理，我们重用了 vLLM，取得了令人印象深刻的表现，仅用一块 GPU L4 就能在 20 分钟内修正 10,000 个食材列表！
经过成功处理后，修正后的数据保存在一个中间数据库中，包含 Open Food Facts 中所有模型的预测，由Robotoff提供服务。
当贡献者修改产品详情时，他们将看到拼写检查的修正建议，确保用户仍然是 Open Food Facts 数据质量过程中的关键决策者。
该系统使 Open Food Facts 能够利用先进的 AI 能力来提高数据质量，同时保持其社区驱动的方法。
GCP 中的批处理作业（图片来自作者）
结论
在这篇文章中，我们带您了解了食材拼写检查的开发和集成，这是一个由 LLM 驱动的功能，用于修正 OCR 提取的食材列表。
我们首先制定了一套规则，拼写检查指南，来限制修正范围。我们创建了一个经过修正的食材列表基准，并通过自定义评估算法来评估任何解决方案。
在这种设置下，我们评估了各种私有 LLM，并确定GPT-3.5-Turbo是最适合我们特定用例的模型。然而，我们也展示了依赖私有 LLM 带来的显著限制，包括缺乏所有权和对如此大型模型（1750 亿个参数）进行改进或微调的机会受限。
为了应对这些挑战，我们决定开发我们自己的模型，并在从数据库提取的合成修正文本上进行微调。经过几轮迭代和实验，我们成功地通过一个开源模型达到了良好的表现。我们不仅匹配了私有 LLM 的性能，还解决了我们面临的所有权问题，使我们对模型拥有完全控制权。
我们随后将该模型集成到 Open Food Facts中，使用批处理推理部署，使我们能够定期处理成千上万的食材列表。预测结果存储在 Robotoff 数据库中作为洞察，然后由贡献者验证，将 OFF 的数据质量所有权留给贡献者。
下一步
拼写检查集成仍在进行中。我们正在设计用户界面，以提供机器学习生成的修正建议，并让贡献者接受、拒绝或修改这些修正。我们预计将在年底前完成该功能的完全集成。
用户验证的拼写检查已内置于Hugging Face Space
此外，我们计划通过持续的迭代改进来不断完善模型。通过提高训练数据的质量并结合用户反馈，可以显著提升其性能。这种方法将使我们能够持续微调模型，确保其始终保持高效，并与实际应用场景高度契合。
该模型及其数据集可以在官方Hugging Face 仓库中找到。用于开发该模型的代码可以在OpenFoodFacts-ai/spellcheck的 Github 仓库中找到。
感谢你阅读到这里！我们希望你喜欢这篇文章。
如果你也想为 Open Food Facts 做出贡献，你可以：
-
为 Open Food Facts 的GitHub做贡献：探索与您技能相匹配的开放问题，
-
下载 Open Food Facts 的移动应用：通过扫描条形码，轻松添加新产品或改进现有产品。
-
加入 Open Food Facts 的Slack，并与其他贡献者在 OFF 社区中开始讨论。
我们迫不及待地想看到你加入社区！
不要犹豫，查看我们的其他文章：
[## DuckDB 与 Open Food Facts：掌中最大的开放食品数据库 🦆🍊
利用 DuckDB 的强大功能，探索食品市场中最大的开放数据库。
medium.com](https://medium.com/@jeremyarancio/duckdb-open-food-facts-the-largest-open-food-database-in-the-palm-of-your-hand-0d4ab30d0701?source=post_page-----d74dfe02e0e4--------------------------------)
扫一扫
790
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
