ベトナム語 生成AIの精度｜崩れるのはモデルではなく前処理

ベトナム語 生成AIの精度が出ない、という相談は、たいていモデルの話として持ち込まれます。日本語や英語では期待どおりに動くのに、ベトナム語だけ精度が落ちる。多くの現場はそこでモデルを乗り換えますが、たいてい直りません。壊れているのはモデルではなく、その手前にある文字と語の処理だからです。この記事ではベトナム語の処理を4つの層に分け、どの層を直せば何が良くなるのかを用途別に整理します。

ベトナム語 生成AIで「精度が出ない」と言われるとき、実際に起きていること

ベトナム拠点で最初に上がってくる報告は、だいたい次の3つの形をしています。

• 社内文書を検索させても、あるはずの文書が出てこない。日本語で同じ質問をすると出てくる
• ベトナム語の日報や検査記録を集計させると、合計が現場の実感と合わない。同じ設備の記録が2つに割れている
• 翻訳や要約は動くが、訳が硬い、固有名詞が変わる、社内で使っている言い回しにならない

いずれも「常に間違える」のではなく「たまに間違える」形で出ます。ここが厄介なところです。常に落ちるなら設定を疑いますが、たまに落ちるものは再現手順が書けません。再現手順が書けない不具合は、原因の特定を飛ばして「モデルの実力不足」という説明に落ち着きやすくなります。

そこでモデルを乗り換えます。より新しいモデル、より大きいモデル、ベトナム語対応をうたうモデル。ところが症状は同じ形で残ります。検索が当たらない件数が少し減ることはあっても、当たらない文書は当たらないままです。

理由は単純で、モデルは処理の一番下流にいるからです。上流で壊れた文字列や、上流で不適切に切られた語は、そのままモデルへの入力になります。入力が壊れていれば、どんなモデルでも同じ場所でつまずきます。乗り換えても直らないのは、直すべき場所に手が入っていないからです。

そしてベトナム語には、日本語や英語を扱っているときには表面化しない事情が2つあります。1つは、見た目が同じで中身が違う文字列が量産されること。もう1つは、空白があるのにそれが語の境界ではないこと。 この2つは、どちらもモデルの手前で起きます。

この記事では、ベトナム語の処理を文字・語・トークン・意味の4層に分けます。層に分ける目的は、どの症状がどの層の問題なのかを切り分けて、直す順番を決められるようにすることです。順番を間違えると、費用と時間の大半が最後の層に吸われます。

ベトナム語の処理は4層に分かれる — 文字・語・トークン・意味

ベトナム語の文書が生成AIに渡るまでに、4つの層を通ります。上流から順に、文字層、語層、トークン層、意味層です。

この4層には、実務上いくつか性質の違いがあります。

上流ほど、一度作れば効き続けます。 第1層の正規化は、一度入口に置いてしまえば、その後に増える文書にも自動で効きます。対して第3層のモデル利用料は使った分だけ発生し続けます。

上流ほど、壊れたときの影響範囲が広くなります。 第1層が壊れると、検索も集計も要約も同時に外れます。第4層が弱いだけなら、影響は生成文の質にとどまります。

そして上流ほど、症状がモデルのせいに見えます。 第1層と第2層の失敗は「たまに」の形で出るため、原因が特定されないまま下流に責任が転嫁されます。

ここで、この4層をタイ語に当てはめた場合との違いを先に押さえておきます。タイ語では、語と語の間に空白が無いことが問題でした。機械が「無い区切りを自分で作る」必要があるからです。ベトナム語は逆です。空白はあります。ただし、その空白は語の境界ではなく音節の境界です。 ベトナム語の正書法は、語ではなく音節の間に空白を置くため、複数の音節が組み合わさって1つの語を構成している場合でも、文字列の上では空白で分断されています。つまり機械がやるべきなのは「区切りを作る」ことではなく、「すでにある区切りのうち、どれが語の境界でどれが語の内側かを判定して束ね直す」ことになります。同じ4層モデルをタイ語に当てはめた整理はタイ語で生成AIの精度が出ないときに壊れている場所にまとめてあります。層の構造は共通ですが、第2層でやる作業の中身は反対向きです。

この違いは実装にも効きます。タイ語では「切りすぎ・切らなすぎ」が症状として出ますが、ベトナム語では空白をそのまま語の区切りとして扱ってしまうことが症状の出発点になります。空白で区切るだけの処理は、どんな言語でも動いてしまうため、誰もそこを疑いません。これがベトナム語で原因の特定を遅らせる最大の理由です。

第1層 文字層 — 見た目が同じで中身が違うベトナム語

第1層でやることは一つだけです。同じ意味の文字列を、同じバイト列に揃える。

ベトナム語はラテン文字で書かれます。この事実が油断を生みます。ラテン文字なら英語と同じように扱えるはずだ、という前提が置かれるからです。しかしベトナム語の文字には、母音の種類を示す記号と、声調を示す記号が付きます。そして記号の付いた文字は、コンピュータの内部で複数の表し方を持ちます。

Unicodeには正規化形式という考え方があります。NFC（正規合成形式）は、分解された文字列を単一のコードポイントで表される合成済みの文字に置き換えたものです。NFD（正規分解形式）は逆に、合成済みの文字を基底となる文字と結合文字の列に分解したものです。ベトナム語の声調記号付きの文字は、NFDでは複数のコードポイントに分解されます。

つまり、画面上はまったく同じに見える1つの単語が、片方の文書ではNFCで、もう片方の文書ではNFDで保存されている、ということが普通に起こります。人の目には同じ文字列です。コンピュータにとっては別の文字列です。

VietUnicodeのFAQは、この形式の違いが実際に何を引き起こすかを説明しています。要約すると、結合分音記号が基底となる文字から意図せず分離してしまうことがあり、その隙間に別の文字が誤って入力されると、たとえば tháng という語が than´g のような形で表示されてしまう、という現象です。また、同じFAQは文字列長の扱いについても触れています。「ệ」という1文字は、NFDでは2つから3つのコードポイントとして数えられ、NFCでは常に1つとして扱われます。文字数の判定が、保存形式によって変わるということです。

この「文字数が形式で変わる」という性質は、実務では地味に効いてきます。入力欄の文字数制限、帳票の桁揃え、チャンク分割の長さ計算。いずれも文字数を前提にしているので、NFCとNFDが混ざった状態では結果が揃いません。

さらにベトナム語には、声調記号をどこに置くかという表記の揺れがあります。旧字体は声調記号を語の中心に近い位置に置き、新字体は主母音の上に置きます。hóa と hoá、hủy と huỷ。これらは同じ語ですが、文字列としては別物です。公式の教科書は新字体を採用している一方で、日常の書き言葉では旧字体が好まれる傾向があるとされます。つまり社内文書には、両方が混ざります。

現場でどう見えるか。 設備マスタとベトナム語の日報を突き合わせると「該当なし」が出ます。担当者が画面上で両方を見比べても、まったく同じ文字列に見えます。そこで「システムの検索がおかしい」という話になり、検索エンジンの設定やモデルの話に流れていきます。実際には、片方がNFDで保存されていただけ、あるいは声調記号の位置が旧字体と新字体で違っただけ、ということが起こります。

第1層の直し方は、機能としては地味です。取り込みの入口を一本にして、そこで必ず正規化を通す。具体的には、Unicode正規化形式をNFCに統一すること、声調記号の位置の表記を新字体か旧字体のどちらかに寄せること、旧エンコーディングから来た文字列を検出して変換すること、英数字の全角と半角や大文字と小文字を揃えること。これだけです。

重要なのは置き場所です。正規化処理を検索側にも集計側にも要約側にもばらばらに書くと、どれか一つを直したときに他が揃わなくなります。入口で一度だけ通し、それより下流は正規化済みの文字列しか扱わない、という約束にしておくほうが後の運用が楽になります。

第1層が固まっているかどうかは、目視ではなく数で確認できます。同じはずの語が何通りの文字列に割れているかを数える。この件数が減っていく間は、まだ第1層の作業が残っています。

第2層 語層 — 空白はあるのに、それは語の境界ではない

ここがベトナム語の生成AIで最も重要な層です。

ベトナム語の正書法は、語ではなく音節の間に空白を置きます。そして、複数の音節が組み合わさって1つの語を構成することが多くあります。たとえば「学生」を意味する語は2つの音節から成り、文字列の上では空白で分けて書かれます。書き手にとっては1つの語ですが、機械が空白で区切ると2つの単位になります。

英語と同じ感覚で「空白で切ればよい」と考えると、ここで最初の断層が生まれます。空白で切る処理はエラーを出しません。動いてしまいます。ただし、切られた結果は語ではなく音節です。この状態で検索インデックスを作り、チャンクを分割し、キーワードを照合し、精度を評価すると、それらは全部「音節の単位」で動くことになります。

ベトナム語の自然言語処理では、この音節を語に束ね直す処理を分かち書き（word segmentation）と呼びます。ベトナム語を扱うシステムは、明示的にせよ暗黙にせよ、必ずどこかでこの判断をしています。空白をそのまま境界として使う、という判断も判断のうちです。

問題は、この束ね方に依存している処理が一つではないことです。

• 検索のインデックス作成は、束ねられた語を単位に作られる
• RAGのチャンク分割は、語や文の境界を手がかりに区切る
• キーワード一致や辞書照合は、束ねられた語と辞書の語を突き合わせる
• 精度の評価も、束ねられた単位で正解と比較する

つまり、束ね方が変われば、この4つが同時に変わります。逆に言えば、束ね方が悪ければ4つが同時に壊れます。しかも壊れ方が均一ではないため、症状は「検索が当たったり当たらなかったりする」という形になります。

この層の重要性は、ベトナム語向けに作られたモデルの側からも確認できます。VinAI Researchが公開しているPhoBERTのREADMEには、入力テキストはすでに分かち書きが済んでいなければならない、という趣旨の注意が大文字で書かれています。原文は “INPUT TEXT MUST BE ALREADY WORD-SEGMENTED!” です。PhoBERTの事前学習データは、VnCoreNLPのRDRSegmenterで声調の正規化と分かち書きを済ませたものであり、下流タスクでも同じ分かち書きツールを使うことが推奨されています。

ここが実務上の要点です。ベトナム語向けに作られたモデルほど、前処理を前提にしている。 前処理を通さずに投入すると、そのモデルが本来持っている性能は出ません。そして出なかった結果を見て「このモデルはベトナム語に弱い」という評価が下されます。評価しているのはモデルではなく、自社の前処理です。

ベトナム拠点の文書で束ね方が崩れやすいのは、社内固有名詞のところです。設備名、部品名、社内略号、ライン名。これらは一般的な辞書に載っていません。辞書に無い語は、音節に分かれたまま扱われるか、近い語の組み合わせとして誤って束ねられます。束ね方は前後の文脈によって変わるので、同じ設備名が文書によって別の単位に割れます。

現場でどう見えるか。 同じ設備の日報が、集計上2つの設備として並びます。担当者は「1台しかない設備が2行ある」と報告しますが、原因は設備マスタでもデータ入力でもなく、文書を語に束ねた時点で名前が2通りに割れていたことです。

第2層の直し方は、社内固有名詞の辞書を作って分かち書きに読ませることです。これは技術の作業というより、現地スタッフと一緒に語彙を洗い出す作業になります。そして設備や部品が増えるたびに追加が必要なので、一度きりでは終わりません。

多言語のナレッジ検索をどう組み立てるかは、工場のナレッジ検索をRAGで作るときの進め方でも扱っています。ベトナム語を含む検索を設計するときは、この第2層をどこで担保するかを先に決めておくと後戻りが減ります。質問側と文書側で別々の処理を通していないか、という確認を最初に入れてください。

分かち書きの精度をどう読むか — ベンチマークと実データで数字が変わる理由

ベトナム語の分かち書きには、公開されたベンチマークがあります。数字だけを見ると、この問題はすでに解決済みに見えます。実際には、そう読めない事情があります。

まず公式のベンチマークです。VLSP 2013 のテストセット（2120文）において、VnCoreNLPの分かち書きモジュールであるRDRsegmenterはF1で97.90%を記録しています。同じベンチマークでの現時点の最高水準は、UITws-v1のF1で98.06%です。この数字だけを見れば、ベトナム語の分かち書きは実用上ほぼ解決している、と結論したくなります。

一方で、別のベンチマークでは大きく違う数字が出ています。Vietnamese Universal Dependencies Treebank（800文超）を使った独立の比較では、underthesea が80.04%、VnCoreNLP が78.37%、PyVi が57.88%という結果が報告されています。

ここで最も重要なことわりを先に置きます。この2組の数字は評価データが異なるため、同一条件の比較として読むことはできません。 97.90%と78.37%を並べて「実データでは20ポイント落ちる」と言うのは誤りです。テストセットが違えば、文の長さも、語彙の分布も、正解の定義も違います。同じツールの性能が下がったことを示す数字ではありません。

それでも、この2組の数字を並べる価値はあります。分かち書きの精度は、評価データ次第で大きく変わるという事実が読み取れるからです。そしてこの事実こそが、実務で押さえるべき点です。

読み違えを避けるために、3つの点を整理しておきます。

1つめ。公式ベンチマークの高い数値は、ツールの上限を示すものであって、自社文書での性能ではありません。 ベンチマークのテストセットは、一般的な文書から作られています。自社の日報や検査記録に出てくる語彙とは分布が違います。

2つめ。誤りは均等に散らばりません。 辞書や学習データに含まれる一般語はよく束ねられ、含まれない語で崩れます。そして社内文書に出てくる重要語は、たいてい含まれていない語です。設備名、部品名、略号、社名。つまり自社の文書で最も当てたい語ほど、既定のままだと落ちやすいという構造になります。公開ベンチマークの数値を自社の精度としてそのまま使えない理由はここにあります。

3つめ。どのツールを選ぶかより、どの辞書を持つかのほうが効きます。 上の数字はツールどうしの比較ですが、自社文書での差は、ツールの違いよりも固有名詞辞書の有無で大きく動きます。ツール選定に時間をかけるより、辞書を作るほうが先です。

実務的な結論はシンプルです。既定の分かち書きをそのまま使うと、自社語彙のところで落ちる。だから辞書を足す。そして足した効果は、自社の文書で測る。これが第2層の作業内容です。

第3層 トークン層 — 汎用トークナイザとベトナム語の相性

第3層は、テキストをモデルが数える単位に分ける層です。この層は精度そのものより、費用と入る量に効きます。

汎用の大規模言語モデルが使っているトークナイザは、学習データの分布に合わせて作られています。英語が多くを占めるデータで作られたトークナイザは、英語を効率よく短いトークン列に変換します。一方、そうでない言語では、1つの語が複数のトークンに分解されやすくなります。ベトナム語は声調記号付きの文字を多用するため、この影響を受けやすい言語です。

具体的な数字としては、GPT-4のバイトレベルBPEトークナイザがベトナム語で英語の2.5倍のトークン数を要する、という報告があります。ただしこの数値には、引用の経路について注記が必要です。この2.5倍という数字は、Petrov らの2023年のNeurIPS論文（Language Model Tokenizers Introduce Unfairness Between Languages）の分析結果として、それを引用する後続論文（arXiv 2606.15044）が記載しているものです。本記事はPetrov論文自体の表を直接確認したうえで書いているわけではありません。 引用の際は、この経路も一緒に伝えてください。

もう一点、混同を避けておきます。この2.5倍は「汎用のGPTトークナイザで、ベトナム語と英語を比べた倍率」です。タイ語の記事で扱った倍率は「同じタイ語の文書を、汎用トークナイザとタイ語専用トークナイザで処理した場合の効率差」であり、比較の軸がまったく違います。言語間の比較と、トークナイザ間の比較を同じ表に並べてはいけません。 並べた瞬間に、どちらの数字も意味を失います。

この差が実務で効いてくる場面は2つあります。

請求。 従量課金のモデルでは、トークン数がそのまま金額に乗ります。文書量の多い用途、たとえば数年ぶんの検査記録を毎日読ませるような使い方では、この倍率がそのまま運用費の差になります。

コンテキストに入る量。 同じ文脈長の枠に、何ページぶんのベトナム語文書を入れられるかが変わります。RAGでは、検索で拾った文書をモデルに渡します。トークン効率が悪いと、渡せる文書の数が減ります。渡せる文書が減れば、答えの根拠が薄くなります。この経路で、第3層は間接的に精度にも触れてきます。

ただし第3層は乗数であって、原因ではありません。第2層が壊れていて検索が正しい文書を拾えていないなら、その文書を効率よく詰め込んでも答えは良くなりません。トークナイザの選定は、上流が固まった後の最適化として扱うのが順番として自然です。

第4層 意味層 — ここで初めてモデルを選ぶ

第4層は、渡された文字列をどう解釈し、どう生成するかの層です。ここに属する症状は次のようなものです。

• 訳が硬い、直訳調になる、社内で使っている言い回しにならない
• 指示に従わない。形式を指定しても守らない
• 出典に無い内容を書く
• 敬称や丁寧さの度合いが揃わない。相手や場面に対して表現が浮く

第4層の問題かどうかを見分ける方法があります。同じ入力を人が手で整えて渡し、それで直るなら、それは上流の問題です。 検索で拾った文書を人が選び直したら正しく答えられるなら、悪いのは第2層の検索側です。表記の揺れや正規化形式の不一致を人が直したら通るなら、第1層です。人が整えた入力でも同じように崩れるなら、そこで初めて第4層の話になります。

この切り分けを先にやらずにモデルを比較すると、比較の結論が信用できなくなります。上流が揺れている状態で2つのモデルを比べると、差が出た理由がモデルの違いなのか、たまたま拾った文書の違いなのか区別できないからです。

ベトナム語の場合、この切り分けにもう一段の注意が要ります。前の節で見たとおり、ベトナム語向けに作られたモデルには分かち書き済みの入力を前提にしているものがあります。前処理を通さないまま比較すると、前処理を前提にしていないモデルのほうが良い数字を出すことがあります。これはモデルの実力の差ではなく、前処理の有無の差です。比較する全モデルに同じ前処理を通すこと、そして各モデルが要求する前処理の条件を先に読むこと。この2つを守らない比較は、結論が反転します。

第4層で判断材料になるのは、自社の評価セットでの実測値です。公開ベンチマークの順位は候補を絞る材料にはなりますが、自社の文書と自社のタスクでの順位とは一致しないことがあります。

ベトナム語に強いモデルの現在地 — PhoGPT、Viettel、SEA-LION

ベトナム語に力を入れているモデル群について、確認できている範囲を整理します。確認できていないことは、確認できていないと書きます。

いくつか補足します。

PhoGPTのパラメータ数は、名称と実数が違います。 名称はPhoGPT-4Bですが、論文が記載しているのは37億（3.7B）パラメータです。社内の比較資料で「4B」とだけ書くと、他社モデルとの規模比較がわずかにずれます。細かい話に見えますが、規模とコストの見積もりを並べる場面では効いてきます。語彙数20480、コンテキスト長8192という値も、他のモデルと並べるときの前提になります。

Viettelの発表は、報道ベースであることに注意してください。 2026年6月4日に1200億パラメータのモデルが発表されたという情報は、ベトナムのメディア報道によるものです。Viettel自身の技術文書で確認したものではありません。したがって本記事では、このモデルの性能やベンチマーク順位については何も書きません。「発表された」という事実以上のことは、一次情報が出てから判断してください。

SEA-LIONの順位は自社発表です。 SEA-HELMで55モデル中5位、200Bパラメータ未満のオープンモデルの中では1位、という記載はAI Singapore自身によるものです。ベンチマークを提供している側が自社モデルの順位を発表している構図なので、そのまま社内資料に「客観評価」として載せるのは避けてください。候補を絞る入口として参照し、最終判断は自社の評価セットで、という使い方が安全です。

SEA-HELMの評価対象数は、選択肢の広さを示します。 2026年8月5日時点でオープンウェイト61モデル、クローズドウェイト9モデルが評価されています。ベトナム語を扱える候補は、すでに絞り込みが必要な数だけあるということです。裏を返せば、候補を絞る基準を持たないまま比較を始めると終わりません。

モデル選定で先に決めるべきなのは、順位ではなく制約条件です。文書を社外に出せるか。モデルを自社環境に置く必要があるか。応答速度の要求はどうか。ベトナム語だけでなく日本語と英語も同じ枠組みで扱う必要があるか。ここが決まれば候補は数個に絞れます。そこから先は評価セットでの実測です。

用途別に、どの層を直せば効くのか

ここがこの記事の中心です。同じ「ベトナム語の精度が出ない」でも、用途によって支配的な層が違います。 支配的な層を外して手を入れると、費用をかけたのに症状が変わらないという結果になります。

以下、6つの用途それぞれについて詳しく見ます。

社内ドキュメント検索（RAG）— 第2層が支配的

RAGは、質問に関係する文書を検索で拾い、その文書をモデルに渡して答えさせる仕組みです。この構造上、検索が外した文書について、モデルは何もできません。拾えなかった文書は存在しないのと同じです。

ベトナム語のRAGで検索が当たらない原因の多くは、第2層にあります。質問文の束ね方と、文書側の束ね方が一致していない。とくに社内固有名詞が両側で別々の単位に割れると、一致するはずのキーワードが一致しません。

ここでタイ語との違いをもう一度確認しておきます。タイ語では、区切りが無いところに機械が区切りを作る必要がありました。ベトナム語では、すでに空白で区切られているものを、どこまでが1語かという基準で束ね直す必要があります。 作業の向きが逆なので、タイ語で使った設計をそのまま持ってくると噛み合いません。とくに「空白で分割する」という既定の処理は、ベトナム語では何のエラーも出さずに動いてしまい、しかも結果は音節単位です。エラーが出ないぶん、タイ語よりも発見が遅れます。

効く層 は第1層と第2層です。文字を揃え、語を束ねる。ここを直すと、当たらなかった文書が当たるようになります。第3層は「渡せる文書の量」に効くので、根拠の厚みが増します。

ほとんど効かない層 は第4層のモデル差し替えです。モデルを替えても検索結果は変わりません。答えの言い回しが変わるだけで、「その文書が見つからない」という症状は残ります。

最初に手を付ける層 は第2層です。社内固有名詞の辞書を作り、質問側と文書側で同じ分かち書きを通す。これだけで当たり方が変わります。

チャットボット — 第2層で拾い、第4層で答える

社内向けの問い合わせボットは、2つの層に同時にまたがります。前半は「何を聞かれているか」を拾う処理で、これは第2層の影響を受けます。後半は「どう答えるか」で、こちらは第4層です。

ベトナム語のチャットボットで多いのは、同じ質問を別の言い方でされると拾えなくなるという症状です。問い合わせの文は日報より短く、口語で、声調記号の入力揺れも混ざります。短い文ほど、束ね方の失敗が結果に直撃します。加えて、スマートフォンからの入力では声調記号が落ちた表記で送られてくることもあり、第1層の吸収範囲を決めておく必要があります。

効く層 は第2層と第4層です。第2層で問い合わせ語彙の辞書を持ち、第4層で答え方の型を整える。ほとんど効かない層 は第3層で、1件あたりの文が短いためトークナイザの差が金額にも文脈長にも大きく響きません。最初に手を付ける層 は第2層、それも実際に来た問い合わせから語彙を集めることです。

多言語のチャットボットを費用と工程の面から整理したものは、多言語チャットボットを社内に入れるときの費用と進め方にまとめています。言語ごとに担保する層が違うので、そこを設計に織り込んでおくと運用が安定します。

議事録と文字起こし — 第1層と第4層

ベトナム語の会議を文字にする用途では、まず音声からテキストが起こされ、その後に要約や決定事項の抽出が乗ります。

効く層 は第1層と第4層です。文字起こしの直後は、表記が揺れた状態のテキストが出ます。人名、設備名、社名が同じ会議の中で複数の綴りになる。ベトナム語では、声調記号の有無と位置が揺れの主な発生源になります。ここを第1層で揃えないと、後段の要約で同じ人物が2人として扱われたり、決定事項が別々の項目として並んだりします。第4層は、話者の区別と要約の質に効きます。

ほとんど効かない層 は第3層です。ただし第2層は「効かない」とまでは言えません。議事録を後で検索する運用にするなら、その時点で第2層が効いてきます。文字起こし単体では第2層の影響は小さく、検索や集計を乗せた瞬間に効いてくる、という順序で理解しておくと判断を誤りません。

最初に手を付ける層 は第1層、それも会議に出てくる人名と設備名の声調記号表記の統一です。

帳票OCR — 第1層が支配的

納品書、検査成績書、作業指示書。紙やPDFからデータを取る用途です。ここは第1層がほぼすべてと言っていい領域です。

読み取った直後のテキストには、NFCとNFDが混在し、声調記号の位置が新旧の字体で揺れ、古い書式から来た文字列では旧エンコーディング由来の文字化けが混ざります。この状態で基幹システムに投入すると、ロット番号が一致しない、取引先名が別会社として登録される、といった不具合が並びます。

効く層 は第1層です。正規化形式の統一、声調記号表記の統一、旧エンコーディングの検出と変換。加えて、読み取りそのものの精度は第4層のモデル側の話で、OCRを扱えるモデルを使うかどうかの判断がここに入ります。

ほとんど効かない層 は第2層です。帳票の項目値は、そもそも語に束ねる必要がないものが多い。品番や数量を分かち書きしても得るものはありません。項目名の照合に語の一致を使う場合だけ、部分的に第2層が絡みます。

最初に手を付ける層 は第1層、それもNFC統一と声調記号の位置ゆれの吸収です。この2つは症状が分かりやすく、対策も定型化できるため、着手の順番として先に置く価値があります。

翻訳 — 第4層が支配的

日本語からベトナム語、ベトナム語から日本語への翻訳は、ここで挙げた6つの用途の中で最も第4層に寄った用途です。訳文の自然さ、用語の一貫性、敬称や丁寧さの度合い。これらはモデルの解釈と生成の質で決まります。

効く層 は第4層です。用語集を持たせる、文書の種類ごとに指示を変える、モデルを比較する。第1層も効きますが、役割は入力の清掃です。正規化形式が混ざったまま渡すと、モデル側の扱いが安定しません。

ほとんど効かない層 は第2層です。翻訳では文全体を渡すので、自前の分かち書きを噛ませる必要は基本的にありません。ここに工数を割いても訳文は良くなりません。ただし、分かち書き済みの入力を前提にするモデルを使う場合は例外です。使うモデルの要件を先に読んでください。

最初に手を付ける層 は第4層、それも用語集と文書クラスの整理です。契約書と作業手順書と社内連絡を同じ設定で訳すと、どれかが必ず浮きます。

分類と集計 — 第1層と第2層

ベトナム語の日報や不具合報告を、カテゴリ別に集計する用途です。ここは第1層と第2層の合わせ技で決まります。

集計は、キーになる語が一致するかどうかで結果が変わります。設備名が2通りの文字列に割れていれば集計は2行に分かれ、束ね方が不安定なら同じ不具合が別カテゴリに入ります。効く層 は第1層と第2層です。ベトナム語では、第1層の割れ方が「NFC対NFD」と「新字体対旧字体」の2軸で起きるため、同じ語が3通り以上に割れることもあります。

ほとんど効かない層 は第4層です。モデルを替えても、入力の段階で同じ設備が2つに割れている事実は変わりません。分類の判断そのものをモデルに任せる設計であっても、入力の揺れは吸収してくれません。

最初に手を付ける層 は第1層、それも集計のキーになる語のNFC統一です。設備名、ライン名、不具合の種別。この3つを揃えるだけで、集計結果が現場の実感に近づきます。

用途をまたいで言えることは一つです。表の「最初に手を付ける層」の列を見ると、モデル選定を初手に置くべき用途は翻訳だけで、残る5用途はいずれも第1層か第2層から着手する形になります。チャットボットと議事録は第4層も併走しますが、それでも先に触るのは上流です。「まずモデルを替える」という初手は、6用途中5用途で順番を外しています。

ベトナム語特有の5つの落とし穴

ここまでの層の議論を、具体的な症状に落とします。ベトナム拠点の文書でつまずきやすいのは、次の5つです。

声調記号の位置ゆれ — 同じ語が2通りの表記で存在する

ベトナム語の声調記号は、置く位置に2つの流儀があります。旧字体は声調記号を語の中心に近い位置に置き、新字体は主母音の上に置きます。hóa と hoá、hủy と huỷ。同じ語ですが、文字列としては別物です。公式の教科書は新字体を採用する一方、日常の書き言葉では旧字体が好まれる傾向があるとされています。

現場でどう見えるか。 完全一致の検索が通りません。重複判定が効かず、同じ品目が2件として登録されます。キーワード集計では、同じ語が2つの行に分かれて出ます。担当者は画面上で同じ語を見ているので、システムの不具合として報告します。

どの層か。 第1層です。どちらかの表記に寄せる規則を決め、入口で変換します。どちらに寄せるかは、既存システムに入っているデータの多数派に合わせるのが現実的です。

Unicode正規化の不一致 — 見た目が同じで中身が違う

NFCとNFDの違いです。合成済みの文字として1つのコードポイントで保存されているか、基底となる文字と結合文字の列に分解されて保存されているか。ベトナム語の声調記号付きの文字は、NFDでは複数のコードポイントに分解されます。

現場でどう見えるか。 検索窓に手で打った語が当たらないのに、文書からコピーして貼ると当たります。あるいはその逆です。文字数の判定もぶれます。VietUnicodeのFAQが挙げているとおり、「ệ」はNFDでは2つから3つのコードポイントとして数えられ、NFCでは常に1つです。入力欄の文字数制限や帳票の桁揃えが、保存形式によって違う結果を出します。

どの層か。 第1層です。入口でNFCに統一します。統一先をNFCにするかNFDにするかは技術的にはどちらでも構いませんが、片方に決めて全経路で守ることが要点です。決めていないことが問題であって、どちらを選んだかは問題ではありません。

IME合成の崩れ — 入力の途中で文字が分離する

ベトナム語の入力にはTelexやVNIといった方式が使われます。これらの入力方式は、同じキー入力から合成済み（NFC）のテキストも、分解済み（NFD）のテキストも出力しうるとされています。どちらが出るかはソフトウェアによって変わります。

さらに、アプリケーション側が結合文字を1文字にまとめる処理を正しく扱えないと、表示が崩れます。2026年には、実運用のツールで「ư」と入力すると「u ư」のように文字が分離・重複して表示される不具合が報告されています。開発者向けのコマンドラインツールで起きた事例ですが、原因はIMEの合成処理をアプリ側が正しく扱えていないことにあり、業務システムの入力欄でも同じ構造の問題が起こり得ます。

現場でどう見えるか。 現地スタッフから「この画面だけ文字がおかしくなる」という報告が上がります。他の画面では正常なので、システム全体の問題としては扱われず、個人の環境の問題として放置されがちです。そのまま入力されたデータが蓄積すると、後から検索も集計も当たらないレコードが増えます。

どの層か。 第1層です。ただし入口での正規化だけでは足りず、入力欄そのものの挙動を実機で確認する工程が要ります。現地スタッフが実際に使う端末とブラウザで、声調記号付きの語を手入力して保存し、保存されたバイト列を確認する。この確認を導入時のチェック項目に入れてください。

旧エンコーディング由来の文字化け — 過去文書を取り込むときに出る

ベトナム語には、Unicode以前に使われていた8ビットのレガシーエンコーディングがあります。TCVN3、VNI、VSCII。これらは標準的なASCIIのキーに声調記号付きの文字を独自に割り当てる方式で、専用のフォントが無い環境では文字化けを起こします。主要なブラウザは、Windows-1258を除くこれらの8ビットエンコーディングのサポートを2014年に打ち切りました。

現場でどう見えるか。 古い作業標準書、過去の検査記録、稼働年数の長い基幹システムから出力したCSV。これらを現行システムに取り込むと、ベトナム語の部分だけが意味不明な記号列になります。あるいは、一見読めているのに検索に一切当たらない、という形で出ます。後者のほうが厄介です。誰も文字化けだと気づかないまま、そのデータが検索対象に入り続けます。

どの層か。 第1層です。取り込みの前に、元データのエンコーディングを判定して変換する工程を挟みます。判定は自動化できますが、変換結果は現地スタッフの目視確認が要ります。機械的な変換では、どのエンコーディングとして解釈するかを誤ったときに、それらしく読める別の文字列ができてしまうためです。

音節と語の境界の未処理 — 空白をそのまま境界にしている

5つめが、この記事の中心にある問題です。分かち書きをせずに検索、チャンク分割、キーワード一致を組むと、複数の音節から成る1つの語が、別々の単位として扱われます。

現場でどう見えるか。 検索が「たまに」外れます。2音節の語の片方だけが一致して、関係のない文書が上位に来ます。集計では、本来1つの項目が複数に分かれます。そして最も厄介なのは、この処理はエラーを一切出さないことです。空白で分割する処理は正常終了します。ログにも何も残りません。動いているように見えるので、原因の候補として最後まで挙がりません。

どの層か。 第2層です。分かち書きの処理を明示的に置き、質問側と文書側で同じものを通す。そして社内固有名詞の辞書を持たせる。この3点を設計に書いておくことが、後から効いてきます。

ベトナム語の評価データを作る — 「精度」を語れるようにする最短手順

ここまでの話は、すべて「測れる」ことが前提です。測れないまま層を直すと、直したのか直っていないのか分かりません。

ベトナム語の評価データを作る手順は、次のとおりです。

• 対象タスクを1つに絞る。検索なら検索だけ、翻訳なら翻訳だけ。複数を1つの評価セットで測ろうとすると、どの層の改善が効いたのか読めなくなる
• 実際の社内文書から標本を取る。作文した例文を使わない。作文した例文はNFCに揃った新字体で書かれるので、第1層の問題が最初から消えている
• 正解を現地スタッフと決める。何をもって正解とするかは、日本側だけでは決められない。とくに翻訳と分類では、現地の業務感覚がないと正解が定まらない
• 判定基準を先に文章で書く。「自然な訳」では測れない。用語集どおりか、数値が保持されているか、指定の形式か、といった判定可能な条件に落とす
• 版を切って固定する。評価セットを途中で足したり直したりすると、前回との比較ができなくなる

ベトナム語で特に注意すべきなのが、2つめの項目です。評価用の例文を日本側で作ると、その例文はきれいなベトナム語になります。 NFCに揃い、声調記号の位置も統一され、旧エンコーディング由来の文字化けもありません。そのデータで測ると、第1層の問題は最初から存在しないことになります。そして実運用に載せた瞬間に、消していたはずの問題が全部出てきます。標本は必ず、実際に現場で作られた文書から取ってください。

そして、ベトナム語の評価で特に効くのが誤りに層のラベルを付けることです。間違えた事例ごとに、第1層由来か、第2層由来か、第4層由来かを記録します。

これをやると、次に手を付ける層がデータで決まります。誤りの多くが第2層由来なら、モデルを比較しても意味がないと分かります。誤りが第4層に集中してきたなら、そこで初めてモデル選定に費用を使う価値が出ます。ラベルの無い評価は「全体で何割合っている」という数字しか出さないので、次の行動を決められません。

ベトナム語ならではのラベルとして、第1層をさらに2つに分けておくと役に立ちます。正規化形式の不一致によるものと、声調記号の位置ゆれによるもの。この2つは対策が違うので、まとめて数えると打ち手が決まりません。

評価セットの規模については、ここでは件数を示しません。適切な件数は、対象タスクと誤りの起き方によって変わり、一般化できる数字を一次情報で確認できていないためです。実務的には、現在把握している失敗の型をすべて含むという基準で作り始め、新しい型の失敗が出るたびに追加していく形が回しやすくなります。

費用を5層に分解する

ベトナム語の生成AIの費用は、モデル利用料だけではありません。むしろモデル利用料以外の部分が、あとから予算を圧迫します。

先に一つ整理しておきます。ここでの費用の5層は、前半で説明した処理の4層と番号は似ていますが、同じものではありません。 対応関係は次のとおりです。

• 費用の第1層は、処理の第1層（文字層）を作る費用
• 費用の第2層は、処理の第2層（語層）を作り、維持する費用
• 費用の第3層は、処理の第3層（トークン層）に比例する利用料
• 費用の第4層は、処理の第4層（意味層）を測るための評価データの費用
• 費用の第5層は、4つの層すべてにまたがる運用の費用

この記事では金額を書きません。用途、文書量、対象言語の数、社内文書の状態によって幅が大きく、一般化できる相場を一次情報で確認できていないためです。代わりに、費用の性質の違いを押さえてください。

一度きりの費用と、続く費用の区別。 第1層は作り切りに近い費用です。第2層と第5層は続きます。第3層は使った分だけ発生します。この区別をせずに初期見積だけで判断すると、半年後に運用費で驚くことになります。

第3層には乗数が乗ります。 前述のとおり、GPT-4のバイトレベルBPEトークナイザはベトナム語で英語の2.5倍のトークン数を要すると報告されています（Petrov らの2023年の論文の分析結果として、それを引用する後続論文が記載している数値です）。従量課金では、この差が金額に直接効きます。文書量の多い用途では、毎月の運用費の差として出ます。ただしこれは英語との比較であって、トークナイザどうしの比較ではありません。見積の根拠として使うときは、何と何を比べた倍率なのかを必ず添えてください。

最も飛ばされやすいのは第4層です。 評価データの構築は成果物が地味で、直接何かが動くわけではないため、予算からまず削られます。しかしここを飛ばすと、その後の議論がすべて印象論になります。「新しいモデルにしたら良くなった気がする」から先に進めません。

第5層は半年後に効いてきます。 辞書は放置すると古くなります。新しい設備が入り、新しい略号が生まれ、そのたびに分かち書きの精度が静かに落ちていきます。誰が、どの頻度で、何を見て辞書を更新するのか。ここを決めていないと、時間が経つほど稼働前の状態に近づいていきます。

ベトナム語で追加になる費用が1つあります。 過去文書の旧エンコーディング対応です。これは第1層に含まれますが、対象文書の量によっては第1層の中で最も大きな項目になります。しかも一度きりの費用なので、初期見積に載せておかないと途中で追加になります。過去文書を検索対象に含めるかどうかを、見積の前に決めてください。

ベトナム拠点で追加になる3つの論点

日本国内で生成AIを入れる場合と比べて、ベトナム拠点では次の3つが追加で乗ります。

AI法がすでに施行されている

ベトナムでは、Law on Artificial Intelligence No.134/2025/QH15 が2025年12月10日に国会で可決され、2026年3月1日に施行されています。 施行日より前から稼働しているAIシステムについては猶予期間が定められており、一般の分野で12か月、医療・教育・金融の分野で18か月とされています。いずれも施行日からの起算です（施行日から12か月後は、暦日ベースではおおむね2027年3月頃にあたります）。

ここで押さえておくべきなのは、タイとベトナムで段階が違うことです。タイの人工知能法はドラフトの段階にあり、成立も施行もしていません。ベトナムは施行済みです。ASEAN全域で共通の運用を組もうとすると、この段階差が最初の分岐点になります。「まだ決まっていないので様子を見る」という判断は、タイでは成り立ちますが、ベトナムでは成り立ちません。

新規導入の場合は、猶予期間の議論が要らないぶん設計が楽になります。最初から要件を織り込めるからです。逆に、すでに動いているシステムがある場合は、猶予期間の起算日と対象範囲を早めに確認してください。ベトナムでのAI導入と法制度の関係はベトナムでAIを導入するときに押さえる論点でも整理しています。

法令の具体的な適用範囲と義務の内容は、案件ごとに現地の専門家に確認してください。本記事は、施行済みであるという事実と猶予期間の月数までを扱う範囲にとどめます。

辞書と評価データに現地スタッフの関与が要る

第2層の辞書は、技術者だけでは維持できません。設備名や略号の正しい表記を知っているのは現場です。ベトナム語の場合、さらに「どちらの声調記号表記を正とするか」の判断が入ります。これは技術的な正解が無く、現地の慣習と既存データの分布で決まります。

同じことが第4層の評価データにも当てはまります。何をもって正解とするかは、日本側だけでは決められません。とくに分類と翻訳では、現地の業務感覚がないと正解が定まりません。

必要なのは、誰が、どの頻度で、どの入力を見て辞書を更新するかを業務として定義することです。新しい設備が入ったときの手続きに「辞書への追加」を含めておく、といった形で既存の業務フローに埋め込むのが現実的です。ここを決めないまま稼働させると、精度が下がっていることに気づく仕組みも同時に無いことになります。

既存システムとの接続で文字化けが必ず出る

ベトナム拠点では、稼働年数の長い基幹システムや、現地で作られた業務システムが動いていることがあります。これらが旧エンコーディングでデータを保持している場合、現行システムへの統合時に文字化けの対応が必ず発生します。

ここで見落とされやすいのは、文字化けが「読めない形」で出るとは限らないことです。誤ったエンコーディングとして解釈された結果、一見ベトナム語として読める別の文字列ができることがあります。この状態のデータは、目視のチェックを通過してしまいます。そして検索にも集計にも当たらないレコードとして蓄積されます。

対策は、統合の前に元データのエンコーディングを特定し、変換後のサンプルを現地スタッフに読ませることです。読めるかどうかではなく、元の文書と同じことが書いてあるかを確認してもらってください。

最初の90日で何をするか

順番を間違えないための、90日の進め方です。

• 第1日から第30日 — 対象文書を1種類に絞り、第1層の正規化だけを作ります。NFCへの統一と、声調記号表記の統一。同時に「同じはずの語が何通りに割れているか」を数えます。この件数が、第1層の進捗を測る指標になります
• 第31日から第60日 — 第2層です。社内固有名詞の辞書を現地スタッフと作ります。そして分かち書きの結果を目で確認する回を必ず入れます。数値だけ見ていると、辞書に無い語がどう束ねられているかが見えません
• 第61日から第90日 — 第4層の評価セットを作り、モデルを2つ比べます。モデル比較は最後です。 第1層と第2層が固まる前に比べても、差がモデル由来なのか入力由来なのか読めません

この90日で意図的に外しているものがあります。第3層のトークナイザ最適化です。第3層は費用の最適化としては効きますが、精度の問題の切り分けには寄与しません。最初の90日は、症状の原因を特定して潰すことに使い、費用の最適化は運用が回り始めてから着手するほうが、判断材料が揃います。

もう一つ。対象文書を1種類に絞るのは、範囲を狭めるためではなく、原因を見えるようにするためです。日報と検査記録と契約書を同時に扱うと、それぞれ別の壊れ方をするので、どの対策が何に効いたか分からなくなります。1種類で型を作れば、2種類目からは同じ型を当てはめられます。

第1日から第30日の期間について、ベトナム語では1つ追加の作業があります。対象文書がNFCとNFDのどちらで保存されているかを、経路ごとに調べることです。同じシステムでも、Webの入力欄から入ったデータと、ファイルの取り込みから入ったデータで形式が違うことがあります。経路の一覧を作る作業自体は1日で終わりますが、これをやらないと正規化を置く場所を決められません。

よくある失敗5つと回避策

モデルを先に替える

ベトナム拠点での相談で、最もよく見る形です。「ベトナム語の精度が出ない」という報告に対して、最初の対応がモデルの乗り換えになる。本記事の用途別の表のとおり、モデル選定を初手に置くべき用途は翻訳だけで、残る5用途は上流から着手する順番になります。

回避策。 症状が出た事例を手元に集め、人が入力を整えて渡したら直るかどうかを確認します。直るなら上流の問題です。この確認に特別な準備は要らず、モデルを調達する前に実施できます。

空白で区切って、それを語だと思っている

ベトナム語に固有の失敗です。ラテン文字で書かれ、空白で分かれているため、英語と同じ処理がそのまま通ってしまいます。エラーは出ません。結果として、検索も集計も音節の単位で動きます。

回避策。 設計レビューで「ベトナム語のテキストをどこで語に束ねているか」を1問だけ確認します。答えが出てこない、あるいは「空白で分割している」という答えなら、そこが原因の候補です。この確認は実装を読まなくてもできます。

分かち書き済みの入力を要求するモデルに、生のテキストを渡す

ベトナム語向けに作られたモデルには、入力が分かち書き済みであることを前提にしているものがあります。PhoBERTのREADMEには、入力テキストは分かち書き済みでなければならないと明記されています。この条件を読まずに生のテキストを渡すと、性能が出ません。そして出なかった結果を見て、そのモデルの評価が下がります。

回避策。 モデルを候補に入れる時点で、要求される前処理の条件をREADMEや論文で確認し、比較表の項目に入れます。比較する全モデルに同じ前処理を通すこと、そして各モデルの要求条件を満たしていることを、比較の前に確認します。

評価セットを作らずに進める

「新しいモデルにしたら良くなった気がする」で意思決定が進む状態です。良くなったのか、たまたま試した質問が良かったのかを区別できません。

回避策。 評価セットを作るまではモデルの比較をしない、と決めます。評価セットが無い段階でできるのは、上流の層の整備だけです。そして評価用の文書は、日本側で作らず現場の文書から取ります。

正規化処理をあちこちに書く

検索側にも集計側にも要約側にも、それぞれ別の正規化コードがある状態です。NFCへの統一を1か所直しても、別の経路では古いままになります。ベトナム語では、正規化形式と声調記号表記という2つの軸があるため、経路が増えるほど組み合わせの不一致が増えます。

回避策。 取り込みの入口を一本にして、そこだけで正規化します。下流は正規化済みの文字列しか受け取らない、という約束にします。

よくある質問（FAQ）

ベトナム語 生成AIは日本語より精度が落ちるのですか？

用途によります。翻訳や要約のような第4層中心の用途では、モデル側のベトナム語の扱いに差が出ます。一方、検索や集計で「日本語より落ちる」と感じられるものの多くは、第1層と第2層の整備状況の差です。日本語の文書では既に表記が揃っていて、ベトナム語の文書ではNFCとNFDが混ざり、声調記号の位置も新旧が混在している、というだけのことがあります。同じ条件に揃えて比べないと、モデルの言語能力の差なのか、前処理の差なのかは判別できません。

ベトナム語に強い生成AIはどれですか？

確認できている範囲では、VinAI Research の PhoGPT-4B がベトナム語専用のベースモデルとして公開されています。正確には37億（3.7B）パラメータで、1020億トークンのベトナム語コーパスで事前学習され、語彙数20480、コンテキスト長8192です。チャット版の PhoGPT-4B-Chat もあります。東南アジア言語向けには AI Singapore の SEA-LION があり、SEA-LION v4 は SEA-HELM で55モデル中5位、200Bパラメータ未満のオープンモデルの中では1位と自社発表しています。また2026年6月4日には、Viettel AI が1200億パラメータのベトナム語モデル VT-Super-120B-A12B を発表したと報じられていますが、これはベトナムメディアの報道ベースであり、性能については一次情報が確認できていません。どれが自社に合うかは、自社の評価セットで測るのが唯一確実な方法です。

ベトナム語の分かち書きは自前で用意する必要がありますか？

分かち書きの仕組み自体を自作する必要はありません。VnCoreNLP や underthesea といった既存のツールがあります。自前で用意すべきなのは辞書のほう、それも社内固有名詞の辞書です。設備名、部品名、略号、ライン名。これらは一般的なツールの辞書に載っていないため、既定のままでは音節に分かれたまま扱われるか、誤って束ねられます。ここは自社でしか作れません。加えて、使うモデルが分かち書き済みの入力を要求するかどうかを先に確認してください。PhoBERT のように明示的に要求しているモデルがあります。

ベトナム語のRAGで検索が当たらないのはなぜですか？

多くの場合、第2層に原因があります。ベトナム語は空白で区切られていますが、その空白は音節の境界であって語の境界ではありません。空白をそのまま語の区切りとして扱うと、検索は音節の単位で動きます。質問文と文書側で束ね方が一致していなければ、一致するはずのキーワードが一致しません。次いで第1層で、NFCとNFDの不一致や声調記号の位置ゆれが一致を妨げます。モデルを替えても検索結果は変わらないため、この症状に対するモデル乗り換えは効きません。

ベトナム語の生成AIは費用が高くなるのですか？

トークン数の面では、汎用のトークナイザを使う場合に不利が出ます。GPT-4のバイトレベルBPEトークナイザはベトナム語で英語の2.5倍のトークン数を要すると報告されています。ただしこの数値は、Petrov らの2023年の論文の分析結果として、それを引用する後続論文が記載しているものであり、本記事は元論文の表を直接確認したわけではありません。従量課金では、この差が金額に効きます。加えて実務では、モデル利用料よりも辞書整備と運用の費用のほうが後から効いてくることが多く、ベトナム語では過去文書の旧エンコーディング対応が初期費用として乗ることもあります。費用の議論は、モデル利用料だけで組み立てないほうが安全です。

ベトナム語の精度はどうやって測ればよいですか？

実際の社内文書から標本を取り、現地スタッフと正解を決め、判定基準を文章で先に書いて、版を固定します。日本側で作文した例文は使いません。作文した例文はNFCに揃った新字体で書かれるため、第1層の問題が最初から消えてしまうからです。そして誤りごとに、第1層由来か第2層由来か第4層由来かのラベルを付けます。ベトナム語では第1層をさらに、正規化形式の不一致によるものと声調記号の位置ゆれによるものに分けておくと、打ち手が決まりやすくなります。このラベルがあると、次に手を付ける層がデータで決まります。

まとめ

ベトナム語で生成AIの精度が出ないとき、壊れているのはモデルではなく前処理です。この記事の要点を整理します。

• ベトナム語の処理は、文字層、語層、トークン層、意味層の4層に分かれる。モデルは第4層にあり、そこだけ替えても上流の壊れは残る
• 第1層は、見た目が同じで中身が違う文字列を揃える層。NFCとNFDの不一致、声調記号の位置ゆれ、IME合成の崩れ、旧エンコーディング由来の文字化けがここに来る
• 第2層が要。ベトナム語は空白があるが、それは音節の境界であって語の境界ではない。空白で区切る処理はエラーを出さずに動いてしまうため、原因の候補として最後まで挙がらない
• 分かち書きの精度は、VLSP 2013 のテストセット（2120文）で RDRsegmenter が F1 97.90%、同ベンチマークの最高水準は UITws-v1 の 98.06%。一方、Vietnamese Universal Dependencies Treebank（800文超）では underthesea 80.04%、VnCoreNLP 78.37%、PyVi 57.88% という数字が出ている。評価データが異なるため直接比較はできないが、評価データ次第で数字が大きく変わることを示している
• 第3層は費用と入る量に効く。GPT-4のトークナイザはベトナム語で英語の2.5倍のトークン数を要すると報告されている（Petrov らの2023年の論文を引用する後続論文経由の数値）
• ベトナム語向けに作られたモデルほど前処理を前提にする。PhoBERT は入力が分かち書き済みであることを必須としている
• 用途によって支配的な層が違う。モデル選定を初手に置くべき用途は翻訳だけで、RAG、チャットボット、議事録、帳票OCR、分類と集計は第1層か第2層から着手する
• 費用は5層に分かれる。最も飛ばされやすいのが評価データの構築で、ここを飛ばすと精度を議論できなくなる
• ベトナムのAI法は2026年3月1日に施行済み。既存システムには一般分野で12か月、医療・教育・金融分野で18か月の猶予期間がある。タイはドラフト段階であり、両国で段階が違う
• 最初の90日は、正規化、辞書、評価セットの順に進める。モデル比較は最後に置く

ベトナム語で精度が出ないという相談は、どの層で起きているかを切り分けるところから始められます。自社の文書がどの層で崩れているかを一度見てみたい、評価の作り方だけ相談したい、といった検討段階でも構いません。お問い合わせはこちらからご連絡ください。

参考情報

• VnCoreNLP (GitHub) A Vietnamese Natural Language Processing Toolkit
• arXiv A Fast and Accurate Vietnamese Word Segmenter
• undertheseanlp NLP-Vietnamese-progress Word Segmentation Leaderboard
• huybik Word Tokenizer Benchmark
• VinAIResearch PhoBERT (GitHub)
• VietUnicode FAQ
• arXiv PhoGPT Generative Pre-training for Vietnamese
• AI Singapore SEA-HELM Leaderboard
• VILAF Vietnam Enacts its First Law on Artificial Intelligence