改进 Meilisearch 的语言支持
Rust 开发者 Many 解释了语言集成在 Meilisearch 中的工作原理,以及如何为我们的分词库 Charabia 做出贡献,无论您的经验水平如何。

今天,我们与 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 上创建一个 issue,解释您遇到的与语言相关的问题:例如,如果您注意到当您搜索特定单词或表达时,Meilisearch 返回了错误的结果
- 像了解自己的手背一样了解一种语言?我们很乐意听取您在创建分词器和归一化器时遇到的挑战和可能的解决方案的看法
- 提出分词库:了解您喜欢并认为对给定语言非常有效的现有工具非常有帮助
- 提交 PR 以解决您在使用 Meilisearch 和特定语言时遇到的问题。提示:在 PR 本身或 GitHub issue 中清楚地解释问题和解决方案肯定会增加您的贡献被接受的机会
如果您现在正在参加 Hacktoberfest
,Charabia 仓库上列出的大多数 issue 都符合该活动的条件!我们也欢迎没有相应 issue 的 PR——如果您的贡献被接受,我们将很乐意将其标记为 “hacktoberfest approved”。
最后但并非最不重要的一点:如果没有社区提供的出色意见,我们的工作是不可能实现的。非常感谢大家的所有努力和慷慨付出!