predictingthepast について
Predicting The Past は Aeneas と Ithaca を使い、古代ラテン語・ギリシャ語のテキストを分析します。碑文を扱う研究者向けに、復元、地域・年代の推定、類例検索、埋め込み生成を提供します。
主な機能
- 01損傷した文字の復元
- 02碑文の地域と年代の推定
- 03類似する碑文の検索
- 04テキスト埋め込みの生成
- 05ラテン語とギリシャ語の前処理
活用シーン
- 01碑文の欠損箇所を復元
- 02碑文の地域や年代を推定
- 03類例となる碑文を検索
- 04古代テキストの埋め込みを生成
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ google-deepmind/ science-skills --skill predictingthepastインストール後、Claude Code で/predictingthepastを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/iphi-region-sub-loc.jsoniphi-region-sub.txtled-proper-names.txtled-region-sub-loc.jsonled-region-sub.txtoutput_format.mdscripts/preprocess.pyrun_inference.pyvisualize_results.py詳細
過去を予測する(Aeneas / Ithaca)
Aeneas(ラテン語)と Ithaca(古代ギリシャ語)は、古代のテキストに対して次の4つのタスクを実行します。
- 復元 — 欠損または損傷した文字を補います
- 帰属判定 — 地理的および年代的な起源を推定します
- 文脈化 — 並行する碑文を検索します
- 埋め込み — テキストの埋め込みベクトルを生成します
前提条件
-
uv:uvのスキルを読み、セットアップの手順に従って、uvがインストールされ、PATH に設定されていることを確認してください。 -
ユーザーへの通知:.licenses/predictingthepast_LICENSE.txt がワークスペースのルートディレクトリに存在しない場合は、(1)ユーザーに https://github.com/google-deepmind/predictingthepast/blob/main/README.md#license--disclaimer の利用条件を確認するよう明確に通知し、適切な引用情報とデータセットに関する謝辞全文を記載してください。また、これらのデータセットを使用する際は、元のデータソースに謝意を示し、引用する必要があることも伝えてください。次に(2)通知内容とタイムスタンプを記録したファイルを作成してください。
基本ルール
- このスキル内で完結させること:ウェブ検索や外部ツールは使用しないでください。このスキル内のスクリプト(
preprocess.py、run_inference.py、visualize_results.py)のみを実行してください。モデルの出力はそのまま提示し、外部の情報で補足したり、置き換えたりしないでください。 - 通知:このスキルが使用された場合は、そのことを出力に記載してください。
初回読み込み時
復元用の記号を提示し、その後、ユーザーにテキストの入力を促してください。
?:- 意味:長さが既知の欠損箇所です。この文字を予測します。
- 例:
donat in ??????????rtis
#:- 意味:長さが不明な欠損箇所です。長さが不明な文字列を予測します。
- 例:
donat in #rtis
-:- 意味:復元する必要のない、欠損または損傷した文字です。
- 例:
prolixin---s fecit
_:- 意味:復元する必要のない、長さが不明な欠損箇所です。
- 例:
prolixin_s fecit
この一覧を提示した後、分析するテキストを入力するようユーザーに促してください。
前処理
推論の前に入力テキストをクリーニングします。
uv run <SKILL_DIR>/scripts/preprocess.py \
--language=latin \
--input="raw text here..."
またはファイルから:
uv run <SKILL_DIR>/scripts/preprocess.py \
--language=greek \
--input_file=/tmp/input.txt \
--output_file=/tmp/cleaned.txt
前処理の内容
- ラテン語:小文字に変換し、アラビア数字とローマ数字を
0に変換し、編集用の角括弧[]と丸括弧()を削除し、句読点を取り除き、有効な文字(abcdefghiklmnopqrstuvxyzに0 . - _ ? # <space>を加えたもの)に限定します - ギリシャ語:小文字に変換し、アクセントを取り除き、数字表記を
0に変換し、PHI クリーニング(括弧の正規化、シグマの変換)を適用し、ギリシャ文字(αβγδεζηθικλμνξοπρςστυφχψωϛに0 . - _ ? # <space>を加えたもの)に限定します
推論
復元の制約
- 入力の最小長:25文字(短い場合は
-で埋めます)。 ##の連続は禁止です。?#または#?が隣接することもできません。?の並びに含まれるスペースも合計文字数に数えます。- ユーザーのテキストに
#が含まれる場合は、復元する文字数を尋ね、それに応じて--restore_max_lenを設定してください。 - テキストの複数箇所を一度に復元しようとする場合は、テキストをセクションごとに復元することを提案してください。1回のクエリにつき損傷箇所を1つに絞るよう勧めてください。処理が速くなり、予測の品質も高まります。
事前確認
次のいずれかに該当する場合は、続行する前にユーザーに確認してください。
- 復元の複雑さ — 入力に
?文字が 10 個を超えて含まれている場合、または--restore_max_len > 10とともに#が使われている場合は、次のように警告します。「この復元では N 文字を扱うため、完了まで約 M 分かかります(高性能 CPU マシンでは、復元時間は追加の?1 文字ごとにおよそ 10 秒ずつ直線的に増加します。5 → 約 1 分、10 → 約 2.5 分、20 → 約 5 分、30 → 約 8 分)。続行しますか?それとも、クエリを簡略化しますか(例:?の数を減らす、--restore_max_lenを短くする、またはセクションごとに復元する)?」 - 複数ウィンドウへの分割 — 入力テキストが 750 文字を超え、複数のウィンドウに分割される場合は、次のように警告します。「このテキストは N 文字で、重複部分のある W 個のウィンドウに分割され、それぞれ個別に実行されます。処理時間が大幅に長くなります。続行しますか?それとも、入力を短くしますか?」
これらの要因が重なると、複数のウィンドウにまたがる複雑な復元は、いずれか一方だけの場合よりも大幅に時間がかかります。
タスクの選択
各タスクはそれぞれのフラグで制御します。少なくとも 1 つのフラグを指定する必要があります。
--attribute— 地理的および年代的な帰属--restore— テキストの復元(入力に?または#が必要)--contextualize— 関連する碑文の並列検索
任意の組み合わせを使用できます。3 つすべてを同時に使用することもできます。
--embedding を指定すると、ほかのタスクとあわせてテキスト埋め込みベクトルも生成されます。
推論の実行
# Attribution + Restoration (text with gaps)
uv run <SKILL_DIR>/scripts/run_inference.py \
--language=latin \
--input="cleaned text with ???" \
--attribute --restore \
--output_json=/tmp/results.json
# Attribution + Contextualization (no gaps)
uv run <SKILL_DIR>/scripts/run_inference.py \
--language=latin \
--input="cleaned text" \
--attribute --contextualize \
--output_json=/tmp/results.json
# All tasks
uv run <SKILL_DIR>/scripts/run_inference.py \
--language=latin \
--input="cleaned text with ???" \
--attribute --restore --contextualize \
--output_json=/tmp/results.json
# Generate dashboard
uv run \
<SKILL_DIR>/scripts/visualize_results.py \
--input=/tmp/results.json \
--output=/tmp/dashboard.html
出力は常にコンソール(JSON/要約)に返され、リッチな可視化のために HTML ダッシュボードにも必ず書き込む必要があります。
HTML アーティファクトの配信:HTML ファイル(ダッシュボード、または作成するその他の HTML アーティファクト)を生成した後は、ユーザーがブラウザーで表示できるよう、バックグラウンド HTTP サーバーを起動してください。プロセスが終了されないよう、バックグラウンドタスクのプロセス内でサーバーをフォアグラウンド実行してください(末尾に & を付けないでください)。ポートの競合を避けるため、ランダムな高位ポートを使用してください。
以下の例では、<HTML_FILE> を生成した HTML ファイルの絶対パス(例:/tmp/dashboard.html または C:\tmp\dashboard.html)に置き換えてください。
Linux/macOS の場合:
# Pick an unused port and start the server as a persistent process
HTML_FILE=/tmp/dashboard.html # ← set to the actual HTML file path
PORT=$(export PATH="$HOME/.local/bin:$PATH" && uv run python -c "import socket; s=socket.socket(); s.bind(('',0)); print(s.getsockname()[1]); s.close()")
FILENAME=$(basename "$HTML_FILE")
echo "View URL: http://localhost:${PORT}/${FILENAME}"
export PATH="$HOME/.local/bin:$PATH" && uv run python -m http.server "$PORT" --bind 0.0.0.0 --directory "$(dirname "$HTML_FILE")"
Windows(PowerShell)の場合:
# Pick an unused port and start the server as a persistent process
$HTML_FILE = "C:\tmp\dashboard.html" # ← set to the actual HTML file path
$PORT = & "$HOME\.local\bin\uv" run python -c "import socket; s=socket.socket(); s.bind(('',0)); print(s.getsockname()[1]); s.close()"
$FILENAME = Split-Path $HTML_FILE -Leaf
$DIRNAME = Split-Path $HTML_FILE -Parent
Write-Host "View URL: http://localhost:${PORT}/${FILENAME}"
& "$HOME\.local\bin\uv" run python -m http.server $PORT --bind 0.0.0.0 --directory $DIRNAME
次に、応答には http://localhost:<port>/<filename>(または
http://127.0.0.1:<port>/<filename>)を主要なクリック可能リンクとして提示してください。さらに、リモート環境向けの代替リンクとして http://<hostname>:<port>/<filename> も提示してください。ユーザーに file:// の生パスを提示してはいけません。
フラグ
--input:テキスト文字列(--input_fileとは同時に指定できません)--input_file:UTF-8 テキストファイルのパス--language:latinまたはgreek--models_dir:モデルファイルのディレクトリ(デフォルト:$HOME/.predictingthepast/models)--attribute:地理的および年代的な帰属を実行します--restore:テキストの復元を実行します(入力に?または#が必要です)--contextualize:並列碑文の検索を実行します--contextualize_top_k:返す上位の類例数(デフォルト:10)--contextualize_exclude_test_valid:コンテキスト化の結果からテスト/検証テキストを除外します。 内部の数値id(id % 10が3または4)に基づいてフィルタリングします。--embedding:テキストの埋め込みベクトルを生成します(デフォルト:オフ)。有効にすると、 出力に完全精度の浮動小数点ベクトルを含むembeddingフィールドが追加されます。--output_json:統合した JSON をファイルに保存します(visualize_results.py用)--restore_beam_width:ビームサーチで探索する復元候補の数です。大きいほど網羅的になりますが、処理に時間がかかります(デフォルト:100)--restore_max_len:すべての?および#の欠損部分で復元する最大文字数です(デフォルト:15)--restore_temperature:サンプリング温度です。低いほど保守的になり、高いほど創造的になります(デフォルト:1.0)--window_overlap:長文を分割する際のウィンドウの重複率です(デフォルト: 0.33)
長文(750 文字超)
各ウィンドウは25~750 文字である必要があります。入力テキストが750文字を超える場合、 自動的に重複するウィンドウに分割されます(デフォルトの重複率は33%です)。各ウィンドウは 個別にモデルで処理され、地理的および年代的な帰属結果は、すべてのウィンドウにわたって 平均化されます。復元とコンテキスト化はウィンドウごとに実行され、結果が連結されます。
出力形式
--output_jsonを使用して、統合した JSON をファイルに保存します。帰属、復元、コンテキスト化の
すべてのフィールドを含む--output_jsonの完全な形式については、output_format.mdを参照してください。
結果の提示
ユーザーが依頼したすべてのタスクの結果を提示してください。必ず HTML ダッシュボードを生成し、
前述のバックグラウンド HTTP サーバーで配信して、http://の URL をクリック可能なリンクとして提示してください。年は BCE/CE 形式で表記してください。
復元
最上位の予測で、復元した文字を太字にしてください。ビームサーチによる上位10件の候補を、 順位、復元テキスト、スコアの列を持つ番号付きの表で示してください。最も顕著な単語(文字ではありません)を要約し、生の顕著度配列をそのまま出力しないでください。
地理的帰属
上位10地域を、順位、地域、スコアの列を持つランキング表で示してください。説明文では最上位の予測を強調してください。最も顕著な単語(文字ではありません)を要約し、 生の顕著度配列をそのまま出力しないでください。
年代的帰属
最上位の年と加重平均年を報告してください。分布の形状(ピークとなる10年間、推定範囲)を説明し、 160個すべてのビンを列挙しないでください。最も顕著な単語(文字ではありません)を要約し、生の顕著度配列をそのまま出力しないでください。
コンテキスト化(類例)
jpを使用するか、独自のコードを作成して、--output_jsonからコンテキスト化データを抽出してください。上位の類例を、順位、ID、Trismegistos ID、地域、年代範囲、スコア、パートナーリンクの列を持つ表で示してください。JSON に含まれる上位の類例の全文を引用してください。
ユーザーが類例の数を指定した場合は、返す数を制御するために--contextualize_top_kを使用してください。
テスト/検証テキストの除外を求められた場合は、--contextualize_exclude_test_validを追加してください。これは内部の数値id(テストはid % 10が3、検証は4)に基づいてフィルタリングします。
埋め込み(--embeddingが設定されている場合)
ベクトルの次元数(384個の浮動小数点数)を明記してください。
参考資料
詳しくは、以下をご覧ください。 predictingthepast.com
重要: ユーザーに推論結果を初めて返すときは、適切な論文(ギリシャ語の場合は Ithaca、ラテン語の場合は Aeneas)と、以下のデータセット謝辞を引用するようユーザーに伝えてください。
Ithaca(古代ギリシャ語):> Assael, Y., Sommerschield, T., Shillingford, B. et al. 深層ニューラルネットワークを用いた古代文書の復元と帰属判定。Nature 603, 280–283 (2022).
Aeneas(ラテン語):> Assael, Y., Sommerschield, T., Cooley, A. et al. 生成ニューラルネットワークによる古代文書の文脈化。Nature 645, 141–147 (2025).
データセットへの謝辞
重要: ユーザーに推論結果を初めて提示するときは、使用言語に応じた適切な引用と、データセットへの謝辞全文を含めてください(以下を参照)。
Ithaca と Aeneas のプロジェクトは、それぞれ古代ギリシャ語とラテン語の碑文の高品質なデータセットを利用しています。これらのデータセットは、数世紀にわたる研究者による資料収集と、数十年にわたるデジタル編集作業によって構築されました。
Ithaca(古代ギリシャ語):特に Ithaca は、Packard Humanities Institute が「Fair Use」ライセンスで公開した、Searchable Greek Inscriptions データベースの2019年版を利用しています。David Packard の寛大な支援を受けて作成されました: inscriptions.packhum.org.
Aeneas(ラテン語):Aeneas は、以下のデータを用いてトレーニングされました。
- Epigraphic Database Roma (EDR):クリエイティブ・コモンズ 表示 4.0 国際ライセンス(CC-BY)に基づき、 Zenodoで公開されています。EDR は edr-edr.itでも利用できます。
- Epigraphic Database Heidelberg (EDH):クリエイティブ・コモンズ 表示-継承 4.0 国際ライセンス(CC-BY-SA) に基づき、Zenodoで公開されています。EDH は edh.ub.uni-heidelberg.deでも利用できます。
- Epigraphic Database Clauss Slaby (EDCS_ETL) の ETL リポジトリ:クリエイティブ・コモンズ 表示 4.0 国際 ライセンス(CC-BY)に基づき、Zenodoで公開されています。EDCS_ETL はmanfredclauss.deおよび github.com/sdam-au/EDCS_ETLでも利用できます。
これらのリソースには、公開された碑文の大部分が検索可能なデジタル形式で収録されています。