AI に問いを投げて資料を読むとき、検索の仕組み、問いの立て方、返ってきたものの評価は、一つの工程の別の面です。ここでは、まず検索と生成を組み合わせた対話環境の設計を述べ、次に翻訳や註釈を読解の工程に位置づける試みを取り上げ、最後に返ってきたものを専門家が評価する段階を扱います。

典拠が示される対話環境の設計

西洋古典の対話環境 Humanitext Antiqua は、2,338 作品・115,145 チャンクを収録し、密ベクトルと疎ベクトルを組み合わせたハイブリッド検索を採ります。固有名や術語の一致と、意味的な言い換えの双方を拾うためです [UC-038 §三つの公開サービス]。

この環境では、回答の記述に引用チップが付き、底本と実際に用いた検索クエリを示す典拠パネルへ対応します。何を検索した結果なのかが分からなければ、出典の妥当性を判断できないためです。典拠から対訳閲覧サービス(Humanitext Reader)の同じ箇所を開けるのは、チャンクの ID が同じで対応がずれないからです [UC-038 §三つの公開サービス]。

こうした設計の前提には、答えが参照箇所の ID つきで返り、人間が原典に立ち返って検証できるという方針があります。もっともらしい答えでも、何に基づくかが分からなければ使えません [UC-038 §デジタル化とAI-Ready化の違い]。

自由な問いかけに応じる柔軟さには限度もあります。DiHuCo ガイドラインシステムの運営者は、キーワード検索と RAG による AI チャットを標準の入口としつつ、AI チャットは固定的な出力が得られず、データセットを尋ねれば記事から取り出して紹介してくれても、全体として何をやるべきかには答えられないと述べています。ガイドラインとしての「線」が通らないという指摘です [UC-034 §Agentic Publishingとは何か]。対話による探索は、個別の資料を引き出すことには向き、全体の筋道を示すことには別の手立てが要ります。

資料を AI が読める形に整える

検索と生成の質は、資料をどう整えたかに左右されます。Humanitext の設計では、あらかじめ参照単位に ID を振り、原典どうしや原典と注釈・二次文献の関係をつないでおきます。エージェントは張られたリンクをたどるだけで済み、推論の手前の作業をデータ構築の側で済ませられます。解析や検索のたびに文脈を組み立て直すと、答えに取りかかる前に多くのステップとトークンを費やすためです [UC-038 §デジタル化とAI-Ready化の違い]。

チャンクに区切ると文脈が途切れるという問題には、生成時に直前までのチャンクの訳を文脈として与え、参照の解決にのみ使って現在のチャンクだけを訳させる文脈指向翻訳で対処しています [UC-038 §保存・配信・推論の三層アーキテクチャ]。チャンク化の技術そのものは別の節で扱うので、ここでは、読解の質が資料の整え方に依存する点を確認するにとどめます。

画像から文字を取り出す入口についても、同じ考え方が当てはまります。Humanitext OCR は、マルチモーダル LLM による文字認識で、資料の特徴と抽出したい内容をプロンプトに書き添えるだけで済みます。行単位で座標とともにテキストを取り出し、原本画像と行テキストを一対一で結びつけ、目視校正と共同校正を可能にしています [UC-038 §三つの公開サービス]。

読解の工程を分けて、翻訳と註釈を位置づける

翻訳や註釈の生成を、文字列の置き換えとしてではなく、読解の一部として設計する試みがあります。ヴェーダ文献を対象とする VEDA AI は、読解を、字を読む、誤りの向こうにある正しいテクストを読む、語形・構文を分析して読む、文脈・背景を調べて読む、関連する別の文献を参照して読む、という五つに整理し、それぞれを小さな部品に分けています。取り込み、語形を読む、意味を調べる、翻訳・註釈を生成する、という各コンポーネントの対応です [UC-039 §文献を「読む」とはどういうことか, UC-039 §VEDA AI:読解の工程を部品に分ける]。

この設計では、意味を調べる工程を辞書に委ねます。AI にすべて任せる場合でも、モデル内部の知識に頼らず辞書を引いて確認します。サンスクリット語の辞書には 1800 年代にさかのぼるものもあり、100 年以上の積み重ねの知識を取ってくることになります [UC-039 §VEDA AI:読解の工程を部品に分ける]。ただし辞書も批判的に読む必要があり、同義語の扱いや語義の取捨は文脈から決めなければなりません [UC-039 §VEDA AI:読解の工程を部品に分ける]。

この工程は一直線のパイプラインではなく、行き来しながら翻訳へ至ります。最終的に見えるのは翻訳ですが、形態素解析や辞書検索の結果もそれぞれが出力であり、各工程で人が誤りを修正して次へ渡すデータを改善します。その記録は将来の学習データにもなります [UC-039 §VEDA AI:読解の工程を部品に分ける]。

言語ごとにモデルと資料を差し替える

読解の工程を部品に分ける枠組みは、ヴェーダ文献に限らず応用できると考えられています。ヴェーダ語では OCR に専用モデル、形態素解析に ByT5-Sanskrit、辞書検索に CDSL を用います。日本語の古文に置き換えるなら、OCR は NDLOCR-Lite、形態素解析は MeCab と UniDic、辞書検索は JMdict という組み合わせです [UC-039 §言語ごとにモデルと資料を差し替える]。辞書検索の選定は GPT に聞きながら進めたため、専門家ならもっとよい辞書を知っているかもしれない、と発表者は述べています。各工程で最適なモデルを選べば同じ流れで扱え、最初の結果が粗くても、テキストを読みながら AI を育てていくプラットフォームになるという構想です [UC-039 §言語ごとにモデルと資料を差し替える]。

註釈を生成する翻訳

註釈の生成を重視する理由は、古典研究における翻訳が、言語間の置換ではなく、背景や文化的文脈に基づく解釈の表明だからです。語釈、文法、儀礼・思想の背景、文献間の関係が訳に影響し、註釈は解釈の過程を読み手へ開示します。生成 AI に必要なのは自然な訳だけでなく根拠のある訳だ、という位置づけです [UC-039 §註釈を生成する翻訳モデルという目標]。

実験として、訳してから翻訳判断を説明する順序、訳文と註釈を同時に生成する順序、先に語釈・文法・文献的根拠を整理して訳に反映する順序の三つが予定されています。どの順序が翻訳の妥当性、註釈の根拠性、専門家の評価しやすさを高めるかを比べる計画です [UC-039 §註釈を生成する翻訳モデルという目標]。この課題は始まったばかりで、結果はまだありません。

なお Humanitext Reader は、4 言語の対訳を AI による文アライメントで対応づけて提供し、日本語・中国語・韓国語で対訳のある古典がごく一部にとどまる現状から、既存の学術翻訳を置き換えるのではなく、その手前で原典に触れる機会を広げる基盤と位置づけています。訳・注は AI による初稿であることを明示し、疑わしい訳や解釈の分かれる箇所は文単位のコメントで議論します [UC-038 §三つの公開サービス]。

返ってきたものを専門家が評価する

AI が返したものを使う側の課題は、複数の場面で共通して語られています。

参加者アンケートでは、虚偽の回答、専門ではない情報の妥当性判断、ファイル全体の作業を指示したのに部分的にしか行われていない OCR 作業のチェックが、困っていることとして挙がっています。尋ねる事項に関する知識がなければそのまま信じてしまうことがあり得る、という気がかりも書かれています。求められているのは、検証の方法、AI 以外のツールと併用して精度を高める方法、ハルシネーションを起こさないプロンプトの書き方です [Issues-002 §論点2:出力の確からしさの確認]。年代や地域による回答の偏り、とくに非英語圏への偏りや、複数の AI モデルを使うことが本当に批判的な回答を生むのかという疑問も、同じ記事に示されています [Issues-002 §論点2:出力の確からしさの確認]。

この確認を研究設計に組み込んだ例として、SPReAD の採択研究があります。歴史的文書から LLM が作った知識グラフの品質を、生成に使ったものとは別の LLM に評価させ、大学院生による人手の評価との一致を測る計画が示されています。生成と評価に異なる系統のモデルを用いるのは、生成したモデルが自分の出力を甘く評価する偏りを避けるためです。文化遺産を扱う生成 AI についても、専門家のペルソナによる合議と実際の専門家による盲評を組み合わせる計画があります。評価に用いる LLM にも系統的な誤判定が生じうることは限界として挙げられ、モデルの更新によって結果が揺れるとき何を再現の対象とするかは未解決とされています [Issues-004 §論点3:AIの出力の検証]。

VEDA AI は、専門家の評価・修正をモデル改善へ戻す共有プラットフォームを構想しています。複数モデルの翻訳・註釈を並べて選択・採点し、専門家が註釈を書き換えて根拠資料と判断の履歴を残し、人の修正を将来の再学習用のデータに使う仕組みです。評価には BLEU や COMET に加え、註釈の正確性・有用性・根拠性の専門家評価を用います [UC-039 §註釈を生成する翻訳モデルという目標, UC-039 §評価・解釈共有プラットフォームと公開したい成果]。現時点で論文などの検索は未実装で、今後は一次・二次文献を加え、どのテキスト・用例・語義に基づいて訳を生成したのかを辿れる仕組みへ進める計画です [UC-039 §今後の方向性]。

AI の出力に人が関わる点は、記事生成の工程にも共通しています。DiHuCo ガイドラインシステムでは、AI が書いた記事を AI がレビューし、講演者本人が確認してから登録しますが、生成 AI が素材にない情報を書き加えてしまう問題は、生成とレビューに共通する課題として残っています [UC-034 §記事生成のワークフロー]。この工程の詳細は別の節で扱います。