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

一些历史背景

尽管 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 issue 中清晰地解释问题和解决方案，无疑会增加您的贡献被接受的机会。

如果您正在参与Hacktoberfest，那么Charabia 仓库中列出的大多数问题都符合活动要求！没有对应问题的 PR 也受欢迎——如果您的贡献被接受，我们很乐意将其标记为“hacktoberfest approved”。

最后但同样重要的是：如果没有社区提供的宝贵意见，我们的工作将不可能实现。非常感谢大家付出的努力和慷慨！