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

一点历史背景

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

Many 觉得我们处理不同语言内容的方式效率不高，而且即使 Meilisearch 在英语和法语等语言方面已经做得很好，但对于其他语言组来说，情况并非如此。Many 解释说，这在很大程度上取决于我们使用不同语言打字的不同方式，以及我们在其中书写时犯错的各种方式。例如，日语或中文中的拼写错误可能遵循与意大利语或葡萄牙语中的拼写错误不同的逻辑。

不同的视角

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

使用我们的分词器改进语言涉及两个主要方面。首先，我们可以处理分段，这意味着理解一个单词从哪里开始，到哪里结束。

“对于英语或欧洲语使用者来说，这似乎很明显：”按空格分割，你就可以得到你的单词了！“但当你面对其他类型的语言（如中文）时，它会变得更加困难，因为字符之间没有明确的分隔符”

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

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

因此，Many 的工作与其说是编写大量代码，不如说是研究和理解特定语言的来龙去脉，以便他可以判断贡献是否能与 Meilisearch 良好地协同工作。
他解释说：

“这一切都归结为传统翻译和称为信息研究 (IR) 的领域之间的对比。翻译侧重于保留含义，而 IR 可以不那么严格并考虑诸如拼写错误的单词之类的错误。与翻译工作相比，专注于 IR 使我们能够提供在翻译工作中可能无关紧要的搜索选项。”

如果用户键入“mais”，他们会看到“but”和“corn”的结果，因为 Meilisearch 考虑到用户可能忘记或根本不想在使用打字时使用适当的重音。

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

到目前为止，我们使用了哪些语言？

正如您可能在我们的 关于 v0.29 版本发布的博客文章 中读到的那样，在过去的两个月中，我们在改进对泰语的支持方面做了大量工作。这是我们非常自豪的一项功能，这要归功于开源社区。但是，仍有很大的改进空间：Meilisearch 中的泰语分词很棒，但规范化仍需要努力。

我们最近还改进了 Meilisearch 的希伯来语规范化。在此之前，我们在日语分词方面取得了良好的进展，但希望改进日语规范化，以更好地解释ツ和ッ或ダメ和だめ之间的差异。

现在，Many 对中文分词非常感兴趣，这门语言本身就带来了一系列挑战。例如，中文有多种变体，具体取决于其使用地点：普通话、中国大陆的各种区域用法和粤语，仅举几例。尽管所有这些变体都主要共享相同的字符和含义，但它们并非总是以相同的方式使用，可能对应于不同的声音，因此并非每个人都以相同的方式键入它们——所有这些都使得 IR 非常棘手。在这一点上，我们无法进行竞争性规范化，这导致我们将规范化基于用户最多的方言。

未来的目标

为同一种语言容纳竞争性规范化（对一种语言的多种变体的容忍度）是 Many 目前的首要任务之一。

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

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

接下来是：解析重音符、变音符和其他非空格标记。还记得我们之前的 “maïs” 和 “mais” 示例吗？在这一点上，分词器只是删除重音符，但有些用户可能希望将这些变音符考虑在内。根据 Many 的说法，实现这一点在技术上不是很复杂：简而言之，它需要建立两个不同的规范化过程——一个宽松的（忽略重音符）和一个严格的（不忽略任何内容）。挑战在于如何在不严重减慢搜索速度或使索引大小翻倍的情况下集成它们。

我如何贡献？

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

• 投票支持讨论：这有助于 Many 确定特定主题或语言的优先级
• 在 GitHub 上创建一个 问题，解释您遇到的与语言相关的问题：例如，如果您在搜索特定单词或表达式时发现 Meilisearch 返回了错误的结果
• 像了解自己的手背一样了解一种语言？我们很乐意听取您在创建分段器和规范化器时对挑战和可能的解决方案的看法
• 提出分词库：了解您喜欢并认为非常适用于给定语言的现有工具非常有帮助
• 提交 PR，解决您在使用 Meilisearch 时遇到的特定语言问题。提示：在 PR 本身或 GitHub issue 中清楚地解释问题和解决方案，肯定会增加您的贡献被接受的机会 

如果您现在正在参加 Hacktoberfest ，Charabia 存储库中列出的大部分 issue 都符合该活动的要求！我们也欢迎没有相应 issue 的 PR - 如果您的贡献被接受，我们很乐意将其标记为“hacktoberfest approved”。

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