ペルシャ語チャットボットは、見た目が似たペルシャ語とアラビア文字系のテキストが別々のUnicode文字列としてプログラムに届くと、誤った質問に答えることがある。イラン・カラジのQatrehでペルシャ語アシスタントを構築したsaman ghが、September 7の記事で報告した。著者は、一般に疑われる小さな知識ベースが原因とは限らないと述べる。同じ見た目の単語でも、比較前には複数の無関係な文字列として届く可能性があるためだ。ゼロ幅非接合子（見えない区切り文字）を含む`چتبات`と、通常の空白を含む`چت بات`はバイト列を共有しないため、入力文と参照文を比較可能な形にそろえない限り照合に失敗する。

記事は、綴り間違いではない一般的なペルシャ語の表記揺れを複数挙げた。ゼロ幅非接合子のUnicode U+200Cにより、`میرود`、`می رود`、`میرود`は3つの異なる文字列になる。ペルシャ語のyeh U+06CCとアラビア語のyeh U+064Aは多くのフォントでほぼ同じに見え、ペルシャ語のkeheh U+06A9とアラビア語のkaf U+0643も同様だ。hehとteh marbutaは`شرکه`を`شرکة`に変え得る。ペルシャ数字U+06F0–U+06F9、アラビア・インド数字U+0660–U+0669、ASCII数字は同じ数を3通りに符号化する。任意の発音区別符号や、装飾的な伸長文字であるtatweelも、貼り付けられたテキストに残り、照合を静かに壊すことがある。

「chatbot」のような通常の語でも、著者によれば少なくとも4つの一般的な表記があり、いずれも正しい。1つの表記だけを認識するシステムでは、4人中3人のユーザーで失敗し得る。JavaScriptの例では、`چتبات`と`چت بات`について`a === b`はfalseを返す一方、`a.length === b.length`はtrueを返す。コードポイントを調べると、ユーザーには見えないU+200Cが現れる。この不具合は検出しにくい。アプリケーションはクラッシュせず、既定の返信を送り、Webサーバーは200レスポンスを記録し、稼働監視は正常のままで、ダッシュボードにも明白なエラーが出ない。

2つ目の失敗は部分文字列照合から生じる。著者によると、Qatrehのシステムはかつてプロジェクト日程の質問を識別するためにキーワード`زمان`（time）を使っていた。しかし企業研修について尋ねたユーザーが`سازمانی`（organisational）を使い、この語に4文字のキーワードが部分文字列として含まれていた。JavaScriptの`.includes()`が誤った意図に一致し、チャットボットはプロジェクトのタイムラインで回答した。提案された修正は単語単位の比較であり、接頭辞照合は、共有される語頭が偶然とは考えにくいほど長い語に限って許可するというものだ。

推奨される正規化パイプラインは6 stepsで、比較前に入力文と参照文の両方へ適用する。発音区別符号とtatweelを削除する。ゼロ幅非接合子と方向制御記号を通常の空白に変換する。ペルシャ数字とアラビア・インド数字をASCIIへ変換する。yeh、alef maqsura、yeh hamzaをペルシャ語yehに統一し、アラビア語kafをkehehに、teh marbutaをhehに、alef系を通常のalefにそろえる。ラテン文字を小文字化する。最後に、文字と数字以外をすべて空白へ置き換え、連続する空白をまとめる。著者は、U+200Cを削除せず空白に変える必要があると強調する。削除すると`چتبات`が`چتبات`になり、なお`چت بات`とは一致しないからだ。

この問題は、店舗、研修センター、工場の顧客がさまざまな端末やキーボード配列から入力するローカル導入でより重要になる。Qatrehは、合成テキストではなく実際のメッセージ流量で評価するとしている。同社の評価では、正規化導入前、通常のペルシャ語質問10件中3件が既定回答に流れた。導入後は10件すべてが正しいトピックに到達した。著者は、大規模言語モデルは綴りの揺れにより寛容だが、検索、フィルタリング、ルーティングなど文字列照合が残る場所では問題を消さないと付け加える。正規化処理は低コストとされ、短い文字列に対する6つの置換で、回答検索を含むサーバー側の総処理時間は10 to 14 millisecondsと測定された。

ペルシャ語チャットボットは、見た目が似たペルシャ語とアラビア文字系のテキストが別々のUnicode文字列としてプログラムに届くと、誤った質問に答えることがある。イラン・カラジのQatrehでペルシャ語アシスタントを構築したsaman ghが、September 7の記事で報告した。著者は、一般に疑われる小さな知識ベースが原因とは限らないと述べる。同じ見た目の単語でも、比較前には複数の無関係な文字列として届く可能性があるためだ。ゼロ幅非接合子（見えない区切り文字）を含む`چتبات`と、通常の空白を含む`چت بات`はバイト列を共有しないため、入力文と参照文を比較可能な形にそろえない限り照合に失敗する。

記事は、綴り間違いではない一般的なペルシャ語の表記揺れを複数挙げた。ゼロ幅非接合子のUnicode U+200Cにより、`میرود`、`می رود`、`میرود`は3つの異なる文字列になる。ペルシャ語のyeh U+06CCとアラビア語のyeh U+064Aは多くのフォントでほぼ同じに見え、ペルシャ語のkeheh U+06A9とアラビア語のkaf U+0643も同様だ。hehとteh marbutaは`شرکه`を`شرکة`に変え得る。ペルシャ数字U+06F0–U+06F9、アラビア・インド数字U+0660–U+0669、ASCII数字は同じ数を3通りに符号化する。任意の発音区別符号や、装飾的な伸長文字であるtatweelも、貼り付けられたテキストに残り、照合を静かに壊すことがある。

「chatbot」のような通常の語でも、著者によれば少なくとも4つの一般的な表記があり、いずれも正しい。1つの表記だけを認識するシステムでは、4人中3人のユーザーで失敗し得る。JavaScriptの例では、`چتبات`と`چت بات`について`a === b`はfalseを返す一方、`a.length === b.length`はtrueを返す。コードポイントを調べると、ユーザーには見えないU+200Cが現れる。この不具合は検出しにくい。アプリケーションはクラッシュせず、既定の返信を送り、Webサーバーは200レスポンスを記録し、稼働監視は正常のままで、ダッシュボードにも明白なエラーが出ない。

2つ目の失敗は部分文字列照合から生じる。著者によると、Qatrehのシステムはかつてプロジェクト日程の質問を識別するためにキーワード`زمان`（time）を使っていた。しかし企業研修について尋ねたユーザーが`سازمانی`（organisational）を使い、この語に4文字のキーワードが部分文字列として含まれていた。JavaScriptの`.includes()`が誤った意図に一致し、チャットボットはプロジェクトのタイムラインで回答した。提案された修正は単語単位の比較であり、接頭辞照合は、共有される語頭が偶然とは考えにくいほど長い語に限って許可するというものだ。

推奨される正規化パイプラインは6 stepsで、比較前に入力文と参照文の両方へ適用する。発音区別符号とtatweelを削除する。ゼロ幅非接合子と方向制御記号を通常の空白に変換する。ペルシャ数字とアラビア・インド数字をASCIIへ変換する。yeh、alef maqsura、yeh hamzaをペルシャ語yehに統一し、アラビア語kafをkehehに、teh marbutaをhehに、alef系を通常のalefにそろえる。ラテン文字を小文字化する。最後に、文字と数字以外をすべて空白へ置き換え、連続する空白をまとめる。著者は、U+200Cを削除せず空白に変える必要があると強調する。削除すると`چتبات`が`چتبات`になり、なお`چت بات`とは一致しないからだ。

この問題は、店舗、研修センター、工場の顧客がさまざまな端末やキーボード配列から入力するローカル導入でより重要になる。Qatrehは、合成テキストではなく実際のメッセージ流量で評価するとしている。同社の評価では、正規化導入前、通常のペルシャ語質問10件中3件が既定回答に流れた。導入後は10件すべてが正しいトピックに到達した。著者は、大規模言語モデルは綴りの揺れにより寛容だが、検索、フィルタリング、ルーティングなど文字列照合が残る場所では問題を消さないと付け加える。正規化処理は低コストとされ、短い文字列に対する6つの置換で、回答検索を含むサーバー側の総処理時間は10 to 14 millisecondsと測定された。