今天，我們與 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 問題中清楚地解釋問題和解決方案，肯定會增加您的貢獻被接受的機會

如果您目前正在參與 Hacktoberfest，那麼在 Charabia 的儲存庫中列出的大多數問題都符合該活動的資格！我們也歡迎沒有對應問題的 PR（Pull Requests）— 如果您的貢獻被接受，我們很樂意將其標記為「hacktoberfest approved」。

最後但同樣重要的是：如果沒有社群的精彩意見，我們的工作將無法實現。非常感謝大家的所有努力和慷慨付出！