翻訳辞典RAGでLLMの翻訳改善を狙ったが
きっかけ
翻訳者が「なぜその訳語を選ぶのか」というニュアンスや判断理由まで書かれた翻訳辞典がある。これをデータベース化し、RAGでLLMに文脈として渡してやれば、機械翻訳特有の不自然さが消えて人間らしい翻訳ができるのではないか、と考えたのが始まりだった。
学んだこと
約4,000項目をOCRで取り込み、検索基盤やパイプラインをかなり堅牢に作り込んだあとにA/Bテストを行った。しかし結果は、辞典を渡したことで翻訳が良くなったのが3件、逆に悪化したのが4件で、実質的に効果が出なかった。
文字列として成句が100%ヒットしていても、文脈上の「語義」まで一致していたのは約6割にとどまった。さらに、語義が合っていたとしても、LLMが辞書の強い表現に引っ張られてしまい、かえって文脈にそぐわない訳になるケースが目立った。
自分なりの理解
「本当に役に立つか」の検証が後回しになりデータベース作成に時間をかけすぎてしまった。
LLMにとって追加情報は必ずしもプラスに働かない場合もある。現代のモデルは素の状態でもかなり自然な日本語を出せるため、中途半端に関連する辞書情報を渡すと、無視できずに無理やり使おうとしてしまう。
RAGにおいて「文字として検索に引っかかること（文字列の精度）」と「その文脈で必要な意味であること（意味の精度）」には大きな隔たりがあり、後者を担保できないなら何も渡さないほうがいい。
実践へのつなげ方
- 価値の検証を初日に終わらせる: DB設計やパイプライン構築をする前に、生テキストをプロンプトに手動で貼り付けて20〜30件テストする。
- 作問・停止条件を先に決める: 「改善が悪化を上回らなければ撤退する」といった基準を事前に決めておき、深追いを防ぐ。
- 「怪しい情報を混ぜるくらいなら、何も渡さない方がマシ」: 確信が持てない情報はコンテキストに含めない。
次に試すこと
新しいアイデアを検証する際は、コードやDB作りから始めずに、スプレッドシートと手動のコピペといった1日以内に効果測定を終わらせるものから始める。