今天，我们与 Meilisearch 的 Rust 开发者之一 Many 坐下来，聊聊他为改善 Meilisearch 的语言支持，在 Charabia 上所做的工作。 

一些历史背景

尽管 Many 两年前首次接触 Meilisearch 的语言解析，但他直到 2021 年底才开始专注于分词。你可能会问自己：什么是分词？Many 告诉我们，这是索引文档时最重要的步骤之一，简而言之，它意味着将搜索词分解成引擎可以更高效处理的单元。Meilisearch 引擎中负责分词的部分被称为分词器。

Many 认为我们处理不同语言内容的方式效率不高，即使 Meilisearch 已经很好地支持英语和法语等语言，但对于其他语言组却并非如此。Many 解释说，这很大程度上归结于我们在不同语言中的输入方式不同，以及在这些语言中书写时犯错的各种方式。例如，日语或中文中的错别字可能与意大利语或葡萄牙语中的错别字遵循不同的逻辑。

不同的视角

Many 立即发现了一个主要问题：Meilisearch 无法单独掌握世界上所有语言并改进我们的分词器。幸运的是，开源社区是一个多元化且慷慨的群体，来自世界各地的人们精通的语言多得我们数不过来。因此，Many 的重心从直接改进语言支持转移到使贡献变得尽可能简单和轻松。

我们的分词器在改进语言方面有两个主要方面。首先，我们可以致力于 分词，这意味着理解一个词从哪里开始到哪里结束。

“对于英语或欧洲语言使用者来说，这似乎很明显：‘按空格分割就能得到单词！’；但当你遇到像中文这样的其他语言时，这就变得困难了，因为字符之间没有明确的分隔符。”

其次，我们可以致力于 标准化，这包括规范化修改（大写或小写），兼容等效（识别不同形式的相同字符；例如：ツ 和 ッ），以及转写（从一种字母表转写到另一种；例如：西里尔字母转写为拉丁字母）——我们尽可能避免最后一种，因为它经常导致信息丢失。

“这里也是一样，每种语言都有其特殊性，我们必须针对每种语言调整标准化。以大小写为例：每个拉丁字符都有大写和小写两种版本，但这种特殊性并非存在于世界上所有语言！”

那么，Many 的工作与其说是编写大量代码，不如说是研究和理解特定语言的方方面面，以便他能判断一项贡献是否能与 Meilisearch 很好地配合。
他解释道： 

“这一切都归结为传统翻译与信息检索（IR）领域之间的对比。翻译侧重于保留意义，而信息检索可以不那么严格，并考虑到拼写错误等。侧重于信息检索而非翻译，使我们能够提供在翻译工作中可能不相关的搜索选项。” 

如果用户输入“mais”，他们会同时看到“but”和“corn”的结果，因为 Meilisearch 考虑到了用户可能忘记或只是不想在输入时使用正确的重音符号。

因此，每当我们希望改进对某种语言的支持时，这不仅仅是让合适的语言专家为我们的项目做贡献。这还涉及到 Many 方面的大量研究时间投入，以便他能确定对特定语言的分词过程的改变是否会返回更相关的搜索结果。

到目前为止我们致力于哪些语言？

正如您可能在我们关于 v0.29 版本发布的博客文章中读到的，在过去的两个月里，我们在改进对泰语的支持方面做了大量工作。这是我们非常自豪的一项功能，它的实现离不开开源社区。不过，仍有很大的改进空间：Meilisearch 中的泰语分词效果很好，但标准化仍需改进。

我们最近还改进了 Meilisearch 的希伯来语标准化。在此之前，我们在日语分词方面取得了良好进展，但希望进一步完善日语标准化，以便更好地考虑 ツ 和 ッ，或 ダメ 和 だめ 之间的差异。

目前，Many 对中文分词非常感兴趣，这是一种伴随自身一系列挑战的语言。例如，中文根据其使用地点有多种变体：普通话、中国大陆的各种方言用途，以及粤语等。尽管所有这些变体大多共享相同的字符和含义，但它们并非总是以相同的方式使用，可能对应不同的发音，因此并非每个人都以相同的方式输入——所有这些使得在信息检索方面变得非常棘手。目前，我们无法支持相互竞争的标准化，这导致我们根据用户数量最多的方言进行标准化。

未来愿景

目前，Many 的首要任务之一是实现同一语言的相互竞争的标准化（即对同一种语言的多种变体的兼容）。 

他还认为我们支持的语言数量太少，因此一个重要的步骤是制定策略来吸引更多贡献者参与。你可能会问：Many 接下来想关注哪些语言？他告诉我们这是一个复杂的选择：他需要平衡自己的个人偏好、贡献者提出的语言，以及基于语言使用者数量的战略选择。

他解释说，并非所有语言都一样。有些语言更容易处理：例如，像土耳其语这样的黏着语可能会是下一个！Many 保证道：“然而，如果贡献者希望推动他们的语言，我们很乐意考虑他们的建议并重新调整优先级。”

接下来的任务是：解析重音符号、变音符号和其他非间距标记。还记得我们前面提到的“maïs”和“mais”的例子吗？目前，分词器只是简单地移除重音符号，但有些用户可能希望将这些变音符号考虑在内。据 Many 称，实现这一点在技术上并不复杂：简而言之，它需要建立两种不同的标准化过程——一种宽松（忽略重音符号），另一种严格（不忽略任何内容）。挑战在于在不严重降低搜索速度或使索引大小加倍的情况下，将它们集成起来。

我如何贡献？

想帮忙吗？您可以通过多种方式做出贡献，其中许多与编码关系不大。

• 为一个讨论点赞：这有助于 Many 优先处理特定主题或语言。
• 在 GitHub 上创建问题，解释您遇到的与语言相关的问题： 例如，如果您发现 Meilisearch 在搜索特定单词或表达时返回错误结果。
• 对某种语言了如指掌？我们很乐意听取您在创建分词器和标准化器时遇到的挑战和可能的解决方案。
• 提出分词库建议：了解您喜欢并认为对特定语言非常有效的现有工具会非常有帮助。
• 提交 PR 解决您在使用 Meilisearch 特定语言时遇到的问题。提示：在 PR 本身或 GitHub 问题中清晰地解释问题和解决方案，无疑会增加您的贡献被接受的机会。 

如果您目前正在参与 Hacktoberfest 活动，Charabia 仓库中列出的大多数问题都符合该活动的资格！我们也欢迎没有对应问题的 PR——如果您的贡献被接受，我们很乐意将其标记为“Hacktoberfest 已批准”。

最后但同样重要的是：如果没有社区的精彩投入，我们的工作将无法实现。非常感谢大家的所有努力和慷慨！