facebookresearch

英語論文や技術PDFのレイアウト崩れを防いで翻訳する方法：2段組・表・数式の破損パターンと対策 英語の学術論文や技術仕様書のPDFを読む際、段落の途切れや表の崩壊、数式の文字化けに悩まされる問題を解決します。 PDF内部のテキスト配置構造を紐解きながら、なぜ翻訳時にレイアウト破損が起こるのか、その4大原因を検証します。 論文の2段組や表・数式を適切に扱えるツールの特徴と、翻訳後に確認すべき重要チェックポイントがわかります。 Wordのファイルには、どの単語が段落を構成し、どの単語が表に属しているかの構造情報が記録されています。しかし、多くのPDFにはそれがありません。PDFが持っているのは文字コードと、その文字を紙面（画面）上に描画する座標情報だけです。段落や表、文といった構造は、読む人間の目が補完して認識しています。 一部のPDFにはアクセシビリティタグが付与されていますが、学術論文を含め付いていないものも数多く存在します。そのため、2段組レイアウト、複数列にまたがる見出し、次ページへと続く文章といった構造は、翻訳を行う前に正しく組み直す必要があります。そのうえで、翻訳によって長さが変わった訳文を元のレイアウトに収め直さなければなりません。書式が崩れるのは、まさにこの工程です。 手元のファイルに応じた基本的な選択肢は以下のとおりです： - 元の .docx や .pptx がある場合：PDFではなく、その元ファイルを翻訳するのが確実です。 - 表が少なく文字中心のPDF（10 MB未満）：Google 翻訳のドキュメント機能を手軽に試せます。 - 表・数式・2段組を含む論文や技術レポート：レイアウトを再構築するタイプの翻訳ツールを利用し、後述する4つのチェックポイントを確認してください。 - スキャンデータ（テキスト選択不可）：事前にOCR処理が必要です。DeepLはスキャンデータにも対応していますが、Google 翻訳ではスキャンページは未翻訳のまま残ります。 1. 翻訳ツールはPDFの内部をどう見ているのか PDFからテキストを取り出す際、内部で何が起きているのかを可視化するため、arXivに公開されているAI言語モデルの論文2本（LLaMA と Mistral 7B）を例に取ります。一般的なオープンソースPDFツールである MuPDF の mutool でテキストを抽出した結果を見てみましょう。レイアウトを考慮しないツールが翻訳処理に渡しているのは、おおよそ次のようなデータです。 1.1 表は単なる数字の列に分解される LLaMA 論文の表3（Table 3）では、10個のモデルを8つのベンチマークテストで比較しています。  これをテキスト抽出すると102行のデータになります。ヘッダーの後に数値が1行ずつ並びます。 BoolQ PIQA SIQA HellaSwag WinoGrande ARC-e ARC-c OBQA GPT-3 175B 60.5 81.0 - 78.9 70.2 68.8 51.4 57.6 Gopher どの数値がどのテストに対応しているのかを示す情報は完全に失われています。これをそのまま翻訳ボックスに貼り付けても、表としての構造は戻ってきません。 1.2 1つの文の中に表データが丸ごと混入する LLaMA 論文の3ページ目末尾の文は、"we need to" で途切れています。  その続きは、4ページ目左欄の表3の下に現れます。  抽出されたテキストを見ると、脚注や改ページ、表3の102行、さらに表題が、1つの文の真ん中に挟み込まれています。 To fully benefit from this optimization, we need to 2https://github.com/facebookresearch/xformers BoolQ PIQA … Table 3: Zero-shot performance on Common Sense Reasoning tasks. reduce the memory usage of the model by using 順序通りに機械的に処理するツールでは、文の途切れと表の混入を見分けることができず、不自然に分割された訳文が生成されてしまいます。 1.3 添字や分数が別の文字・数値に化ける Mistral 論文では、変数 h に添字 i が付けられています（hᵢ）。  テキスト抽出を行うと添字の位置情報が失われ、単なる hi という文字列になります。 former to attend information beyond the window size W. The hidden state in position i of the layer k, hi, attends to all hidden states from LLaMA 論文でも、4d の3分の2（⅔·4d）という重ね組みの分数が次のように抽出されます。  improve the performance. We use a dimension of 2 34d instead of 4d as in PaLM. 位置情報が脱落した結果、「4dの3分の2」が「34d」という全く異なる数値になってしまいます。 1.4 単語が行末ハイフンで分断される 2段組の論文では行末のハイフネーションが多用されます。  We introduce LLaMA, a collection of founda- tion language models ranging from 7B to 65B … (175B) on most benchmarks, and LLaMA- 65B is competitive with the best models, founda-tion はハイフンを除去して繋ぐ必要がありますが、モデル名である LLaMA-65B のハイフンは保持しなければなりません。 2. PDF翻訳ツールの選択肢と特徴 | 選択肢 | 長所 | 限界 | | --- | --- | --- | | 翻訳ボックスへのコピー＆ペースト | 無料ですぐに使える | 表、数式、レイアウトが失われ、文が途中で切れることが多い | | Google 翻訳（ドキュメント） | 無料。.docx、.pdf、.pptx、.xlsx に対応 | 10 MB・300ページまで。画像内文字やスキャンページは翻訳されない。モバイル非対応 | | DeepL（ファイル翻訳） | Web/デスクトップ/API対応。スキャンデータ対応。Proプラン等で.docx変換可能 | アカウントが必要。プランごとに翻訳ファイル数制限あり。CAD由来PDFなどは非対応 | | Word等に変換してから翻訳 | 翻訳前に元ファイルを修正できる | 変換時点でレイアウト崩れが発生した場合、誤りがそのまま残る | | レイアウト再構築型の翻訳ツール | 表、数式、分割された文を構造として認識 | 元ファイルと同一の配置にはならない。訳文の長さに応じて改行やフォントサイズが変化する | 私たちが開発している Equalang のドキュメント翻訳は、このレイアウト再構築アプローチを採用しています。ページの切れ目で分断された文章を翻訳前に結合し、表構造を1列に潰さずに維持したまま再構築します。また、数式を文字化けとして破棄せず、数式最適化のオプションも提供しています（対応言語：日本語、英語、中国語、韓国語、スペイン語、フランス語など）。 ただし、言語によって翻訳後の文字量が変わるため、元ファイルと完全に一致するわけではありません。文字が溢れたり改行位置が変わる箇所は、目視での確認が必要です。 3. PDF翻訳後に必ず確認すべき4つのポイント 1. 表の整合性：列ヘッダーと数値の対応がずれていないか確認します。 2. 改ページと表前後のテキスト：ページの最終行や表の直後に、文頭・文末が途切れた不自然な文がないか確認します。 3. 数式と記号：文中のインライン変数や分数が、一般的な英単語や誤った数字に化けていないか点検します。 4. ページ数とハイパーリンク：訳文の膨張でページが予期せず増えていないか、目次や参照リンクが正常に飛べるかを確認します。 この記事はドキュメント翻訳ツールを開発している Equalang チームが執筆しました。 参考資料 - Touvron et al., "LLaMA: Open and Efficient Foundation Language Models", arXiv:2302.13971v1, CC BY 4.0. - Jiang et al., "Mistral 7B", arXiv:2310.06825v1, CC BY 4.0. - Google 翻訳 ヘルプ, Translate documents & websites, 2026年10月7日確認. - DeepL ヘルプセンター, Translate PDF files, 2026年10月7日確認. - 実測方法: テキストは2026年10月7日に MuPDF 1.25.6 で抽出（コマンド mutool draw -q -F txt -o out.txt in.pdf）。図は論文ページの切り抜きで、強調は筆者が入れたものです。

Hyperagents Self-improving AI systems aim to reduce reliance on human engineering by learning to improve their own learning and problem-solving processes. Existing approaches to self-improvement rely on fixed, handcrafted meta-level mechanisms, fundamentally limiting how fast such systems can improve. The Darwin G\"odel Machine (DGM) demonstrates open-ended self-improvement in coding by repeatedly generating and evaluating self-modified variants. Because both evaluation and self-modification are coding tasks, gains in coding ability can translate into gains in self-improvement ability. However, this alignment does not generally hold beyond coding domains. We introduce \textbf{hyperagents}, self-referential agents that integrate a task agent (which solves the target task) and a meta agent (which modifies itself and the task agent) into a single editable program. Crucially, the meta-level modification procedure is itself editable, enabling metacognitive self-modification, improving not only the task-solving behavior, but also the mechanism that generates future improvements. We instantiate this framework by extending DGM to create DGM-Hyperagents (DGM-H), eliminating the assumption of domain-specific alignment between task performance and self-modification skill to potentially support self-accelerating progress on any computable task. Across diverse domains, the DGM-H improves performance over time and outperforms baselines without self-improvement or open-ended exploration, as well as prior self-improving systems. Furthermore, the DGM-H improves the process by which it generates new agents (e.g., persistent memory, performance tracking), and these meta-level improvements transfer across domains and accumulate across runs. DGM-Hyperagents offer a glimpse of open-ended AI systems that do not merely search for better solutions, but continually improve their search for how to improve. Comments: Code at facebookresearch/Hyperagents

OmniFaceRig: Fully Automatic Inner-Mouth-Aware Face Rigging Across Diverse 3D Character Topologies Facial rigging--creating Facial Action Coding System (FACS) blendshapes and inner-mouth geometry (teeth, gums, and tongue)--remains a major bottleneck in 3D character production. We present OmniFaceRig, a fully automatic end-to-end pipeline that converts a static surface-only 3D character mesh, with no pre-modeled oral cavity, into an inner-mouth-aware FACS rig with up to 155 blendshapes, procedurally fitted teeth, gums, and tongue, and re-packed UV/texture. It supports humans, humanoids, and long- and short-muzzled animals with no manual landmarks, user-provided templates, or per-asset setup. OmniFaceRig combines a hybrid vision-language and computer vision riggability checker, a four-model face segmentation ensemble, keypoint-driven template registration, procedural inner-mouth construction, and collision-aware blendshape transfer. For non-human characters, it selects topology-specific templates with a nose-landmark-free design and uses as-rigid-as-possible deformation with signed-distance-field constraints to reduce teeth-face intersections. We also introduce Omni-Bench, an open-source benchmark of more than 1,000 biped 3D characters rigged with FACS blendshapes and inner-mouth geometry, spanning humans, humanoids, cats, dogs, and other animals. Experiments show high rigging success, nearly complete face detection recall, low inner-mouth penetration, and 20-30 s end-to-end latency per asset on a single A100 GPU. Comments: 36 pages, 19 figures, 9 tables. Accepted to ACM Transactions on Graphics (SIGGRAPH Asia 2026). v2: revised text and appendix, updated Omni-Bench description for the public dataset release, corrected references. Project page: omnifacerig.github.io ; Dataset: facebookresearch/omnifacerig

Selecting or Solving? What Best-of-N Verification Delivers in Video Reasoning Answering a complex question about a long video is a grounding problem: the answer turns on a few seconds of evidence, and vision-language models remain well below human accuracy at finding them. The standard way to spend extra test-time compute on this kind of video reasoning is best-of-N selection: sample several chain-of-thought answers from a fixed model, then let a second model re-watch the video and pick one. Such pipelines are reported by a single headline number, their margin over a majority vote. That number conflates two effects with opposite deployment consequences: the benefit the second model adds by selecting among candidates, and the benefit it would have supplied by solving the question itself. We separate them, measuring the Selection Increment (SI) -- selection accuracy minus the same verifier's accuracy with the candidates withheld -- alongside the margin over self-consistency, across five long-video benchmarks. The Selection Increment is largest for the weakest verifiers: a verifier that solves poorly on its own leaves the candidates the most room to help. Beating the majority vote follows the opposite profile: where the vote already sits near its ceiling no verifier we test improves on it; below that ceiling only the strongest do. On Video-Holmes, the two come apart on a single pool of candidates -- a weak verifier gains +19.3 points from the candidates yet lands 7.1 points below the vote, while the frontier verifier gains the least and beats the vote. The weakest verifier also shows a failure mode: on EgoSchema it picks by where an option sits in the list rather than by what the video shows. Read as a merit score, SI puts a verifier that fails to beat a majority vote at the top of its ranking; read as an audit, it says which of the two effects a headline number delivers. Code is available at facebookresearch/best-n-selection-video-reasoning. Comments: Accepted at NeurIPS 2026 VLM4WRD workshop

GSLM2: Multi-Stream Speech Representation Learning and Generative Spoken Language Modeling Generative spoken language models (SLMs) offer a route to learning linguistic structure purely from speech, yet they lag far behind text-based models in both capability and data scaling efficiency. We identify two bottlenecks underlying this gap: the limited linguistic quality of existing speech units and the reliance on a single stream of discrete units to represent speech. Multiple codebooks are widely used to encode acoustic features but rarely to represent speech semantics. We present GSLM2, which learns and models complementary properties of speech at multiple levels of abstraction. Its encoder, SpidR 2.0, uses self-supervised learning with differentiable prediction heads to induce high-quality discrete units at multiple levels. A multi-stream SLM then jointly models these units using a shared temporal backbone, stream-specific predictors, and an autoregressive head that captures cross-stream dependencies. Across training data sizes and model scales, up to 6M hours and 6.5B parameters, GSLM2 consistently improves linguistic competence while scaling more efficiently with data. As a result, it substantially narrows the gap between spoken and text-based LMs; across read and conversational speech domains, we shrink the gap by about two orders of magnitude on sWuggy, sBLIMP, and tSC, while also outperforming competitive speech-text systems on all three tasks. We open-source the training code and model checkpoints at facebookresearch/gslm2. Comments: Equal contribution by Yosuke Higuchi and Tom Fizycki. Core contribution by Mahi Luthra, Charles-\'Eric Saint-James and Azeez Syed

Inflearnが自動で字幕を生成するまで（AI/インフラ編） ! この記事は2023年10月31日に執筆されたものです。 こんにちは。InflabのDevOpsエンジニア、SunBです。 2023年9月、Inflearnに字幕とスクリプトの機能が追加されました。皆さん、活用されていますか？　今回追加された字幕機能は、動画の音声データをもとに自動で字幕を生成する部分と、生成された字幕を受講画面に表示する部分の、大きく2つに分けられます。 今日は、このうち私が実装を担当した字幕生成について、どのような技術をもとに、どのような過程を経て実装したのかをお話しします。 2日で字幕機能を作ってデモする まず、「DevOpsエンジニアが字幕機能を実装したの？」と思われる方もいらっしゃると思うので、今回の字幕機能の実装プロジェクトがどのように始まったのかをご紹介します。 Inflabでは今年から、Infthonという名前で社内ハッカソンを開催しています。応募者をランダムに4人1組のチームに分け、約2日間でアイデアの議論とMVPの実装を行ったあとに発表する、という形式です。 ところが偶然（？）、Inflearnの講座プレイヤーやVODインフラを多く手がけていたFE開発者のPapicoと私が同じチームになり、自然と講座の再生に関するアイデアを議論することになりました。そして、第1回Infthonのテーマだった「チームの生産性向上、またはAIを活用したサービス改善」に最も合うと考えた講座のAI字幕機能をアイデアとして選びました。 まず、AIベースの字幕生成機能を実装するにあたって、最低限の条件として次のことを考えました。 字幕生成がオフラインで動作すること（データの外部送信を防ぐ） 字幕生成にコンピューティングリソース以外の追加費用がかからないこと（オープンソースモデルを自前で実行） 字幕生成にかかる時間が動画の長さを超えないこと（ライブデモができるくらい速いこと） これらの条件を満たす技術を探してみたところ、OpenAIのWhisperというモデルが目に留まりました。Whisper以外に検討した技術は以下のとおりです。 KoSpeech: Archived OpenSpeech + KsponSpeech: 自分たちで学習させてモデルを作るには、技術への理解度もまだ低く、時間もかなりかかると予想された KakaoのPORORO: Archived MetaのSeamlessM4T: テスト用の講座を使ったPoCの過程で、SeamlessM4T largeモデルはWhisper large-v2モデルに比べて精度が劣ることを確認 NaverのCLOVA SpeechなどのAPIベースのサービス: データの外部送信とAPI料金が発生 Infthon以前にも、MacWhisperなどのツールで、OpenAIのSTTモデルであるWhisperの存在とその精度の高さは知っていましたが、深く調べたことはありませんでした。実装期間が2日と短かったため、仕組みを深く理解することよりも、素早く適用してデモできるかどうかを重視して作業を進めました。その結果、すべての処理を私のMac上でオフラインで動かす構成になりました。その際、Pythonで実装されたOpenAIのWhisperは遅すぎたため、代わりにC++に移植されたwhisper.cppを使いました。 こうして、次の流れを短期間で実装できました。 動画をアップロードする ffmpegで16-bit WAVの音声データを抽出する whisper.cpp + large-v2モデルで字幕を書き起こし、srtファイルとして保存する 受講画面でこのsrtファイルを再生する さらに、FE開発者のPapicoの活躍で、スクリプトの表示と再生位置の移動、字幕の修正依頼と修正依頼の管理機能までデモでき、第1回Infthonで1位という栄誉を手にしました。 こうして楽しい経験として幕を閉じたと思っていたのですが…… 正式プロジェクトとして採用 ある意味当然のことながら、字幕機能はすぐに正式プロジェクトとして採用され、新たなスタートを切りました。 Infthonですでにデモまで終えていたので大きな心配はありませんでしたが、引っかかる点が3つありました。 Shaka Playerでm3u8のHLSプレイリストとsrt字幕ファイルを同時に表示すると、字幕の同期がずれる問題 AWSのインフラでWhisperをまだ動かしたことがなかった点 韓国語字幕の1行あたりの長さと改行位置が適切でなく、読みにくい問題 1つ目は、FE開発者のPapicoが字幕の表示処理をShaka Playerの機能を使わずにReactで新たに実装し、きれいに解決してくれました。一方、2つ目と3つ目は、そのまま現実の問題として降りかかってきます。 インフラ上でWhisperを動かす Infthonのときとは違い、今回は実際のユーザーにサービスを提供するため、まずは私たちのインフラ上で機能を動かす必要がありました。 エンコーディングインフラの改善記録 字幕生成インフラについてお話しする前に、まず動画エンコーディングインフラを改善した過程をご紹介します。 私たちは2022年10月まで、動画のエンコーディングにAWS MediaConvertを使っていましたが、コスト削減とエンコーディングオプションのカスタマイズのために、EC2 c6i.xlarge Spot InstanceベースのAWS Batch構成に移行しました。MediaConvertのReserved Queueなど、さまざまな代替案も試しましたが、予約したエンコーディングの開始が遅すぎたり、4Kなど一部のオプションが使えないといった制約があったりして、要件を満たすのは難しいと判断し、自分たちで構成する方向を選びました。 結果として、インフラ構成の変更は効果がありました。長さ28分の1080p動画を540p、720p、1080pにエンコードする場合、AWS Batchを使ったときとMediaConvertを使ったときにかかる時間と費用は、以下のとおりでした。 AWS Batch (ECS EC2 c6i.xlarge Spot) MediaConvert (On-Demand Pro) 差 時間 約10分 約7分 約3分 (x0.7) 費用 約$0.021 約$1.895 (SD x 1, HD x 2) 約$1.874 (x90.2) 動画の長さと比べれば、エンコーディング時間の差はわずかですが、費用はなんと90倍以上の差があることを確認しました。 AWS Batch構成で、EC2インスタンスタイプごとの費用と性能を分析した結果は以下のとおりです。（長さ28分の1080p動画を540p、720p、1080pにエンコードする場合、Spot Instance未適用） インスタンスタイプ オンデマンドの1時間あたりの費用 (A) エンコーディングの実行時間 (B) 実際の費用 (A x B) c6i.xlarge $0.192 10分 $0.032 c6g.xlarge $0.154 12分47秒 $0.033 c6i.2xlarge $0.384 5分57秒 $0.038 c6i.4xlarge $0.768 4分23秒 $0.056 g5g.xlarge $0.5166 5分1秒 $0.043 g5.xlarge $1.237 3分15秒 $0.067 エンコーディングインフラと同じ構成でwhisper.cppを試す 上記の改善したエンコーディングインフラをもとに、字幕インフラも同じ構造で構成してみました。AWS Batch上のc6i.xlargeインスタンスで28分の動画に対してwhisper.cppを実行したところ、結果はなんと69分3秒と、予想よりもはるかに遅いものでした。 Infthonのデモ用にMac Studio（M1 Ultra）で同じ動画をwhisper.cppで処理したときは、3分30秒でした。これを見て、すぐにGPUインスタンスのPoCに取りかかりました。 GPUインスタンスのPoC 最初は、g5インスタンスより安いARMベースのg5g.xlargeインスタンスを使ってみようとしました。ところが、NVIDIAドライバーやCUDAのバージョンをいくら変えても、PyTorchからCUDAを認識できませんでした。CUDA 11のPython cuDNNライブラリはARMアーキテクチャをサポートしておらず、PyTorchの正式版はCUDA 12をサポートしていなかったため、PyTorch Nightly + CUDA 12 cuDNNの構成を試しましたが、torch.cuda.is_available() が False を返す状態が続きました。そんな中、AWS BatchではまだARMアーキテクチャベースのGPUインスタンスをサポートしていないというドキュメントを見つけ、g5gインスタンスの利用はひとまず諦めました。 その後、g5.xlargeインスタンスでOpenAIのPythonベースのWhisperを実行してみたところ、7分17秒かかりました。動画の長さに比べれば許容範囲でしたが、Mac Studioでwhisper.cppを使ったときは3分30秒だったことを考えると、ほかに方法はないかと考えるようになりました。そして、SeamlessM4Tについて調べていたとき、偶然Hacker NewsでWhisperXに言及しているコメントを見かけました。 WhisperXへの移行 WhisperXを使って、g5.xlargeインスタンスで28分の動画の字幕生成を試してみたところ、59秒で完了し、最も速い結果となりました。その出力結果も、Whisperやwhisper.cppと比べて精度が劣るということはなく、それぞれ一長一短がありました。 以下は、出力結果を比較した当時に書いたメモの一部です。 Whisper、WhisperXはg5.xlargeで、whisper.cppはMac Studioで抽出したバージョン 3つともかなり違いがあるが、どれか1つが最も優れているというわけではなく、それぞれにうまく書き起こせている部分がある。 WhisperXが正確に抽出した部分 뽑았는데 (Whisper: 꼽았는데) 등허리 (Whisper: 등어리) 복부 (Whisper: 복구) whisper.cppが正確に抽出した部分 Eye Reflect (WhisperX: I Reflect) Whisperが正確に抽出した部分 Z-Remesh (WhisperX: gremesher) 아이리플렉트 (WhisperX: I Reflect) WhisperXはほかの2つよりはるかに速く実行でき、音節単位でalignするので行の再構成に有利であり、字幕の修正依頼機能の有効性も比較的高くなると推定されることを考えると、WhisperXを使うのが最も良いと思われる。 ただし、ときどき複数の文を早口で話す部分で抜け落ちる文があるが、精度が低いと判断して意図的に除外しているように見える。 まとめ 最初に試したwhisper.cpp + c6i.xlargeを基準に、試した組み合わせとの差をまとめると次のとおりです。（large-v2モデルを使って28分の音声データを書き起こした場合） ツール マシン 実行時間 差（速度） whisper.cpp c6i.xlarge 69分3秒 - (x1) Whisper c6i.xlarge 時間がかかりすぎて計測を中断 - WhisperX c6i.xlarge 実行中にエラーが発生 - whisper.cpp Mac Studio 3分30秒 65分33秒 (x19.7) Whisper Mac Studio 時間がかかりすぎて計測を中断 - WhisperX Mac Studio 15分26秒 53分37秒 (x4.5) whisper.cpp（cuBLASビルド） g5.xlarge 17分25秒 51分38秒 (x4) Whisper g5.xlarge 7分17秒 61分46秒 (x9.5) WhisperX g5.xlarge 59秒 68分4秒 (x70.2) 最終的に、WhisperX + g5.xlargeの組み合わせを選びました。 こうして最初の絶望を乗り越え、速度を70倍以上改善し、インフラ上で字幕生成機能を正常に動かせるようになりました。その過程でGPUインスタンスや動画エンコーディングに関する分析も行い、エンコーディング関連のプロセスも改善できました。 （試行錯誤の跡） 字幕の長さと読みやすさの改善 字幕をどう生成するかという課題は、音声データからテキストを抽出するだけでは終わりませんでした。 whisper.cpp、Whisper、WhisperXのいずれにも、--max_line_width のような1行の長さを制限するオプションがあったのですが、問題はこのオプションが動作しないことでした。（……）おそらく韓国語だから動作しないのだろうと推測しています。 そのため、モデルが出力した字幕データは行ごとに長さがバラバラで、文の終わりで改行されることもほとんどなく、読みやすさは最悪でした。 これを改善するために、ピリオド/疑問符/感嘆符があれば改行する案、一定の文字数以上なら単純に空白を基準に半分に分割する案、形態素解析によって行を再構成する案など、さまざまな方法を模索しました。 そんな中、WhisperXに移行して音節単位で時間を追跡できるようになったことで、いっそすべての行を一から作り直そうと考えました。そこで以下の基準を定め、WhisperXの実行から行の構成までを一度に行うPythonスクリプトを実装しました。 WhisperXが時間の追跡に失敗した音節の時間は、時間の追跡に成功した最も近い前後の音節の時間、または文の開始・終了時間から線形補間する。（wav2vecの韓国語モデルベースだったため、ハングル以外は音節の時間を追跡できないという問題がありました。） 直前の単語までの行の長さが0.5秒未満であれば、ほかのどの条件を満たしていても改行しない。 直前の単語までの行の長さが10秒を超えたら、現在の単語から新しい行にする。 現在の単語を加えると行が10文字を超え、かつ形態素解析の結果で文の数が変わる場合は、現在の単語から新しい行にする。 現在の単語を加えると行が50文字を超える場合は、現在の単語から新しい行にする。 文の開始が直前の文の終わりから0.5秒以内の場合は、文の開始時間として直前の文の終了時間を代わりに使う。 実は、このうち形態素解析で文の数を計算し、それをもとに改行する基準は最後に作ったものです。この基準を決めるまでは、WhisperXをCLIで実行したあと、JSONで保存されたデータを読み込んで行を構成する処理をすべてGoで実装していました。しかし、形態素解析と文の数の計算にKiwiを使うことになったため、WhisperXをPython内で直接実行するようにし、行の構成もPythonで実装し直しました。そしてGoは、このPythonスクリプトを実行し、最終的に構成された字幕データをストレージに保存するという、AWS Batch内の1つのジョブのライフサイクル管理だけを担う構造にしました。 こうして、現在提供している字幕のように、読みやすさが大きく改善された字幕データを生成できるようになりました。 GPUインスタンス不足の問題を回避する 問題はすべて解決したと思い、これまでにアップロードされた講座を対象に、実際に字幕を一括生成しようとしました。ところが、AWS Batchにジョブを投入していくら待っても、EC2インスタンスが起動しませんでした。Spot Requestを確認してみると、ソウルリージョンにg5.xlargeインスタンスのSpot Capacityがなく、起動できていなかったのです。 Spot Instanceとは？ Spot Instanceは、AWSで使われていないコンピューティングリソースを最大90%割引した価格で提供する機能です。実行中のSpot Instanceがときどき中断されることもありますが、AWS Batchなどを使ってワークフローの耐障害性を確保していれば、Spot Instanceを適用するだけで60%以上のコスト削減効果を得られます。 実際に、動画エンコーディングインフラにSpot Instanceを適用することで平均70%のコストを削減できていたので、そもそも費用のかさむGPUインスタンスを使ううえで、Spot Instanceの適用は必須でした。 Spot Capacityを求めて GPUインスタンスが足りないという話はよく耳にしていましたが、実際に経験したのは初めてでした。3日待っても起動しなかったので、別の方法を探し始めました。 最初に、Spot Placement Scoreという機能を使ってみました。米国のバージニア、オハイオ、オレゴンリージョンはg5.xlargeインスタンスが最も安く、Placement Scoreも高く出ていたので、まずはバージニアリージョンで試してみました。 初めて使うリージョンで何もなかったため、VPC、Subnet、EIP、NAT Gatewayをはじめ、AWS Batch関連の各種リソースをすべて新しく作成しました。ところが実行してみると、同じようにSpot Capacityがないというエラーが発生しました。しまった！と思い、すぐ隣のオハイオリージョンにも同じ構成を作ってみましたが、やはりSpot Capacityがないというエラーが発生しました。（……） Placement Scoreは当てにならないなと思って調べてみたところ、スポットインスタンスアドバイザーというものを見つけました。g5.xlargeスポットインスタンスの中断頻度が低いリージョンを探してみると、オレゴンリージョンが該当することが分かりました。 バージニア、オハイオリージョンに作ったものはすべて削除し、オレゴンリージョンに構成して実行してみると、ようやく字幕生成ジョブが動き始めました。一括処理のために2,000台のg5.xlargeインスタンスを同時に起動する計画でしたが、オレゴンリージョンでさえインスタンス不足で最大500台ほどしか起動できませんでした。それでも、約4時間で字幕の一括生成を完了できました。 一括処理のコスト 基盤 単価 費用 差 AWS Batch (g5.xlarge Spot) - $807.22 - (x1) AWS Batch (g5.xlarge On-Demand) - 約$2,690 約$1,883 (x3.3) OpenAI Whisper API $0.006 / minute 約$8,700 約$7,893 (x10.8) Naver CLOVA CSR API $0.012 / minute 約$17,400 約$16,593 (x21.6) 字幕の一括生成作業にかかった費用は $807.22 で、約24,000時間に及ぶ動画の音声データをAPIベースのサービスで処理する場合と比べて、10分の1以下のコストで字幕を生成できる構成を実現できました。 結論 以上のような過程を経て、約2か月で字幕生成機能を無事に実装できました。Infthonをきっかけに、2日間でアイデアの選定から技術調査、デモ用の実装までを終え、その後の2か月間で、それをユーザーにリリースできるレベルまで引き上げるためにさまざまな試みをしました。貴重な経験でした。 字幕生成に関する技術的な部分も注目に値しますが、特に強調したいのは、1人が短期間でこなしたにしては、インフラ関連の作業量がかなり多かったことです。何のリソースもないリージョンを3回も渡り歩き、VPCからAWS Batch環境までを一晩で構成できたのは、何かが準備されていなければ不可能なことです。特に、受講権限を持つユーザーにのみ字幕データを提供する対応や、字幕のストレージをS3からMongoDBに移行する作業など、本文には書いていない数多くのインフラ作業がありました。それらに触れなかったのは、ほとんど悩むことなく素早く対応できたからです。 これが可能だったのは、これまで懸命に構築してきたIaCのおかげだと思います。私たちがどのようにIaCを構築したかについては、（今度こそ本当に）近日公開予定の「InflabのIaC構築記（Part 1）」の記事でご覧いただけます。AWS CDKからTerraformへの記事でTerragruntとTerratestについての記事を予告しておきながら、1年以上新しい記事を投稿できなかった理由も、その記事で詳しく書いていますので、IaCに興味のある方はぜひ読んでみてください。 ありがとうございました。

JEPA: qué es la arquitectura de LeCun que no genera píxeles Yann LeCun lleva años insistiendo en que los modelos generativos, los mismos que producen texto o imágenes token por token, no son el camino hacia una inteligencia artificial con sentido común. El 29 de octubre de 2026 publicó, junto a Randall Balestriero, la prueba matemática de esa intuición. Su paper en arXiv demuestra que la arquitectura JEPA que ambos diseñaron converge a la misma representación del mundo sin importar la modalidad de entrada, algo que la predicción de próximo token logra con mucha menos eficiencia. Esa demostración no es el tema de este artículo. Lo que importa para un desarrollador es entender qué hace distinta a esta arquitectura, que Meta ya usa en producción en I-JEPA y V-JEPA. Su apuesta central es predecir representaciones en vez de píxeles. TL;DR - JEPA predice la representación latente de una parte oculta, sin reconstruir píxeles ni tokens.- Meta usa este diseño en I-JEPA para imágenes y en V-JEPA para video en producción.- Un codificador objetivo con pesos EMA y stop-gradient evita el colapso representacional.- Las vistas positivas necesitan 42 veces menos muestras que el next-token prediction para alinear representaciones.- A diferencia de la difusión, JEPA predice embeddings para entender el mundo, no para generar contenido nuevo. ¿Qué es la arquitectura JEPA? La arquitectura JEPA es una familia de modelos de aprendizaje autosupervisado que predice la representación latente de una parte faltante de los datos a partir de una parte visible, sin generar los datos originales pixel por pixel. LeCun la propuso en 2022 como alternativa a los generativos. LeCun presentó la idea en su ensayo A Path Towards Autonomous Machine Intelligence, donde argumentaba que un sistema inteligente necesita un modelo del mundo capaz de predecir sin gastar cómputo en detalles irrelevantes. Reconstruir cada píxel de un video, por ejemplo, obliga al modelo a aprender ruido de cámara o texturas de fondo que no ayudan a entender la escena. JEPA evita ese desperdicio prediciendo en el espacio de las representaciones (embeddings) en lugar del espacio de los datos crudos. En la práctica significa entrenar dos codificadores que nunca comparten gradiente directo y un predictor que conecta ambos. El resultado es un modelo que aprende qué información importa de una escena sin que nadie le diga qué es importante. Por qué importa el enfoque predictivo de LeCun El problema que resuelve JEPA es concreto: entrenar modelos de visión sin millones de etiquetas humanas. Los modelos generativos de imágenes (difusión, autoencoders variacionales) también aprenden sin etiquetas, pero gastan su capacidad reconstruyendo cada textura y cada pixel de ruido, justo lo que después hay que ignorar para tareas como clasificación o segmentación. El paper de Balestriero y LeCun le pone números a esa intuición. Usando un corpus de 145.000 descripciones de imágenes y 940 millones de imágenes web, encontraron que las vistas positivas (dos observaciones de la misma escena) alinean representaciones usando 42 veces menos muestras que el next-token prediction entrenado sobre el mismo texto. Eso explica por qué los modelos de lenguaje alinean con la visión solo a gran escala. La predicción de próximo token es, según los propios autores, una JEPA con "vistas malas", fragmentos de un mismo documento en lugar de observaciones reales de una escena compartida. Un modelo de texto de apenas 109 millones de parámetros entrenado con vistas buenas alineó mejor con los encoders de imagen de DINOv2 y CLIP que cualquier modelo de lenguaje evaluado, incluso uno de 72.000 millones de parámetros. Para quien entrena modelos con presupuesto limitado la lección es práctica. Elegir una arquitectura que prediga en espacio latente ahorra cómputo y datos etiquetados, dos recursos que escasean fuera de los laboratorios grandes. Cómo funciona JEPA por dentro La arquitectura tiene tres piezas. El codificador de contexto procesa la parte visible de la entrada, un bloque de parches de una imagen o un clip de video. El codificador objetivo procesa la parte oculta, pero sus pesos no se entrenan por gradiente, se actualizan como un promedio móvil exponencial (EMA) de los pesos del codificador de contexto. El predictor toma la salida del codificador de contexto y trata de adivinar la salida del codificador objetivo. flowchart TD A["Entrada (imagen o video)"] --> B["Codificador de contexto"] A --> C["Codificador objetivo (EMA)"] B --> D["Embedding de contexto"] C --> E["Embedding objetivo"] D --> F["Predictor"] F --> G["Embedding predicho"] G --> H["Perdida en espacio latente"] E --> H La pérdida de entrenamiento compara esa predicción contra el embedding objetivo real, casi siempre con una distancia L2 o smooth L1, nunca contra los píxeles originales. Como el codificador objetivo nunca recibe gradiente directo y el predictor ve menos información que el codificador objetivo, el sistema no puede memorizar una salida constante para hacer trampa, y ese detalle es lo que previene el colapso representacional, el fracaso más común de este tipo de entrenamiento. > 💭 Clave: Sin la asimetría entre el codificador de contexto y el codificador objetivo (EMA más stop-gradient), el modelo encuentra el camino más corto: predecir siempre el mismo vector y minimizar la pérdida sin aprender nada. I-JEPA divide una imagen en parches y oculta varios bloques grandes y contiguos, no parches sueltos al azar. Ocultar bloques grandes obliga al predictor a razonar sobre la estructura de la escena, dónde termina un objeto, qué hay detrás, en lugar de copiar textura del parche vecino, que es lo que pasa si el hueco es minúsculo. flowchart LR A["Imagen dividida en parches"] --> B["Bloque de contexto visible"] A --> C["Bloques objetivo ocultos"] B --> D["Codificador de contexto"] C --> E["Codificador objetivo"] D --> F["Predictor predice embeddings de C"] E --> G["Embeddings reales de C"] F --> H["Comparar con perdida L2"] G --> H V-JEPA extiende la misma idea al tiempo. En vez de ocultar solo una región espacial, oculta bloques que se extienden a lo largo de varios cuadros consecutivos, así el predictor tiene que modelar tanto la estructura de la escena como su evolución, el primer paso hacia lo que Meta llama un modelo de mundo. Ejemplos prácticos: así se ve una predicción de JEPA en código El mecanismo central de JEPA, predecir un embedding a partir de otro, se puede ilustrar con un fragmento mínimo en PyTorch. No es el código real de los repositorios de Meta, es un esqueleto que muestra la forma del problema. import torch import torch.nn as nn class Predictor(nn.Module): def __init__(self, dim=768): super().__init__() self.proj = nn.Linear(dim, dim) def forward(self, context_embedding, mask_tokens): return self.proj(context_embedding + mask_tokens) context_embedding = torch.randn(1, 196, 768) # embeddings del bloque visible mask_tokens = torch.randn(1, 196, 768) # tokens posicionales del bloque oculto predictor = Predictor() predicted_embedding = predictor(context_embedding, mask_tokens) print(predicted_embedding.shape) La salida es torch.Size([1, 196, 768]): un batch, 196 parches (14x14 en una imagen de 224x224 con parches de 16 píxeles) y 768 dimensiones por embedding. Esa misma forma es la que debe tener el embedding objetivo real para poder compararlos con la función de pérdida. El codificador objetivo nunca recibe gradiente directo, solo un promedio móvil exponencial. Cómo empezar con I-JEPA y V-JEPA Para correr el código oficial necesitás Python 3.9 o superior, Git y, para entrenar en serio, una GPU con soporte CUDA. Para solo cargar un checkpoint preentrenado alcanza con CPU, aunque mucho más lento. Los pasos siguientes son para Linux y macOS; en Windows corren igual dentro de WSL. git clone https://github.com/facebookresearch/ijepa.git cd ijepa python -m venv venv source venv/bin/activate pip install -r requirements.txt Para V-JEPA el repositorio es distinto: git clone https://github.com/facebookresearch/jepa.git, seguido de los mismos tres pasos de entorno virtual e instalación. No hay una forma de confirmar la instalación con un solo comando genérico, porque cada repositorio expone su propio script de evaluación. La señal de que todo cargó bien es que ese script termine e imprima la métrica final (la accuracy del linear probe, en el caso de I-JEPA) en vez de interrumpirse con un traceback de dependencias faltantes. JEPA vs. modelos generativos y contrastivos JEPA no es la única forma de aprender sin etiquetas. Comparado con otras dos familias, la diferencia queda más clara. EnfoqueQué prediceVentajaLimitaciónJEPA (I-JEPA, V-JEPA)Embedding de una parte oculta a partir de una parte visibleNo gasta capacidad en detalles irrelevantes; más eficiente en datosNecesita trucos anticolapso (EMA, stop-gradient); no genera contenidoModelos generativos (difusión, autoregresivos de píxeles)Los datos originales completos, pixel por pixel o token por tokenSirven para crear contenido nuevo directamenteMás cómputo y datos para la misma calidad de representaciónAprendizaje contrastivo (SimCLR, CLIP)Si dos vistas vienen de la misma imagen, comparando embeddings completosRepresentaciones robustas sin reconstruir nadaDepende de aumentaciones manuales y bancos grandes de negativosNext-token prediction (LLMs de texto)El siguiente token de una secuenciaEscala muy bien con datos y cómputo en lenguajeEs una JEPA con vistas malas y alinea con otras modalidades solo a gran escala flowchart TD subgraph Generativo["Modelo generativo"] P1["Entrada parcial"] --> P2["Decodificador"] P2 --> P3["Reconstruccion en espacio de pixeles"] end subgraph JEPA["Arquitectura JEPA"] J1["Entrada parcial"] --> J2["Predictor"] J2 --> J3["Prediccion en espacio latente"] end La elección no es ideológica. Si el objetivo final es generar una imagen o un texto, un modelo generativo sigue siendo la herramienta correcta. Si el objetivo es que un sistema entienda una escena para después actuar sobre ella, un robot, un auto autónomo, predecir en espacio latente rinde más por cada muestra de entrenamiento. Casos de uso reales: de la clasificación de imágenes a los modelos de mundo Meta publicó I-JEPA en 2023 como su primer modelo de visión entrenado con esta arquitectura, pensado para tareas de clasificación y segmentación con pocas etiquetas disponibles. El paper original lo mostró compitiendo con modelos contrastivos usando una fracción de su cómputo de entrenamiento. V-JEPA oculta bloques que se extienden en el tiempo, no solo en el espacio. V-JEPA, publicado en 2024, extendió la idea a video para tareas como reconocimiento de acciones y comprensión de movimiento físico. El paper de V-JEPA lo presenta como un paso hacia modelos que entienden causa y efecto en el mundo físico, lo que LeCun describe como "modelos de mundo": sistemas capaces de predecir qué pasa después de una acción sin haber visto exactamente esa secuencia antes. El caso de uso más concreto hoy es el preentrenamiento: entrenar primero con JEPA sobre datos sin etiquetar y después afinar una cabeza pequeña para la tarea final, con muchas menos imágenes o videos etiquetados que los que necesitaría un modelo entrenado desde cero. Errores comunes y buenas prácticas El error más citado en la literatura de aprendizaje autosupervisado es el colapso representacional: el modelo aprende a producir el mismo embedding para cualquier entrada, minimizando la pérdida sin aprender nada útil. JEPA lo evita con la asimetría entre codificadores, pero esa asimetría no es automática. Si el codificador objetivo se actualiza demasiado rápido (un EMA con momentum bajo) o demasiado lento, el riesgo de colapso vuelve. Otro error común es confundir JEPA con aprendizaje contrastivo. SimCLR y CLIP necesitan pares negativos, ejemplos que NO deben parecerse, y aumentaciones de datos cuidadosamente diseñadas. I-JEPA y V-JEPA no usan negativos explícitos; la asimetría arquitectónica hace ese trabajo. > ⚠️ Ojo: La limitación real, y la razón por la que JEPA no reemplaza a los modelos generativos, es que sus embeddings no sirven para generar contenido directamente. Si el proyecto necesita un generador de imágenes o un chatbot, un modelo generativo sigue siendo la pieza correcta. Profundizando: la hipótesis platónica y el teorema de representación El resultado más fuerte del paper de Balestriero y LeCun es lo que llaman el teorema de representación platónica. Los autores demuestran que dos JEPA entrenadas por separado sobre modalidades distintas, texto e imagen, por ejemplo, convergen a la misma representación salvo una rotación, siempre que sus pares positivos sean "vistas buenas", dos observaciones reales de la misma escena. Con vistas malas, fragmentos arbitrarios de un documento, la convergencia tiene un límite acotado pero no desaparece. La consecuencia práctica, no solo teórica, es que esa rotación se puede calcular sin reentrenar nada. Los autores tomaron un encoder de texto y un encoder de imagen entrenados por separado, calcularon la rotación que los alinea y construyeron un generador de descripciones que obtuvo un CIDEr de 0,838 en COCO, sin que los dos encoders hubieran visto jamás un par imagen-texto durante el entrenamiento. En un benchmark sin pares, ese mismo text JEPA superó el zero-shot de todos los modelos de lenguaje evaluados hasta 8.000 millones de parámetros, con 64% contra un máximo de 56% top-5 en ImageNet-100. Esto no significa que la arquitectura JEPA resuelva la hipótesis platónica de LeCun por completo. El propio paper aclara que el límite de desalineación depende de qué tan "buena" sea la vista, y construir vistas buenas para cada modalidad nueva, audio, sensores de robots, sigue siendo un problema de diseño abierto, no una receta universal. 📖 Resumen en Telegram: Ver resumen Tu próximo paso: cloná el repositorio de I-JEPA, cargá un checkpoint preentrenado y corré el script de linear probing sobre un dataset chico propio para ver cuántas etiquetas necesitás realmente para una accuracy aceptable. Preguntas frecuentes ¿La arquitectura JEPA reemplaza a los transformers generativos? No. JEPA resuelve el problema de aprender representaciones sin etiquetas; los transformers generativos siguen siendo la herramienta cuando el objetivo final es producir texto, imagen o audio nuevo. Son complementarios, no rivales directos. ¿Qué diferencia a I-JEPA de V-JEPA? I-JEPA trabaja sobre imágenes estáticas y oculta bloques espaciales de parches. V-JEPA extiende la idea a video, ocultando bloques que se extienden en el tiempo para que el modelo aprenda también la dinámica de una escena. ¿JEPA necesita pares negativos como el aprendizaje contrastivo? No. SimCLR y CLIP comparan pares positivos contra negativos explícitos. I-JEPA y V-JEPA evitan el colapso con la asimetría entre el codificador de contexto y el codificador objetivo, sin necesitar negativos. ¿Por qué next-token prediction alinea peor con la visión, según el paper de LeCun? Porque sus pares de entrenamiento son fragmentos de un mismo documento de texto, no dos observaciones reales de una escena compartida. El paper lo describe como una JEPA con "vistas malas", y por eso necesita mucha más escala para alinear con modelos de imagen. ¿Se puede usar JEPA para texto, no solo para imágenes y video? Sí. El propio paper de Balestriero y LeCun entrena un text JEPA de 109 millones de parámetros con vistas positivas y lo compara directamente contra modelos de lenguaje de hasta 72.000 millones de parámetros. ¿JEPA sirve para generar imágenes o video nuevo? No directamente. Sus embeddings describen una escena, pero no están pensados para reconstruir píxeles. Generar contenido nuevo a partir de esos embeddings requiere acoplar un decodificador o un modelo generativo aparte. Referencias - Balestriero y LeCun, "Proving and Improving the Platonic Representation Hypothesis with JEPAs" (arXiv, 2026): el paper que motiva este artículo.- Assran et al., "Self-Supervised Learning from Images with a Joint-Embedding Predictive Architecture" (arXiv, 2023): el paper original de I-JEPA.- Bardes et al., "V-JEPA: Video Joint-Embedding Predictive Architecture for Self-Supervised Visual Learning" (arXiv, 2024): el paper original de V-JEPA.- Repositorio oficial de I-JEPA en GitHub: código y checkpoints preentrenados.- Repositorio oficial de V-JEPA en GitHub: código y checkpoints preentrenados. 📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

PDFを翻訳するとレイアウトが崩れる理由と確認すべき4か所 本記事はEqualangチームが執筆しています。Wordファイルと異なり、大半のPDFは「どの単語が段落を構成し、どの単語が表に属しているか」という構造情報を保持していません。PDFが持っているのは文字と、その文字を描画する座標だけです。 二段組の段組み、複数列にまたがる見出し、次ページへと続く文章といった構造に見えるものはすべて、翻訳の前に組み直す必要があります。そのうえで、長さが変わった訳文を元のレイアウトに収め直さなければなりません。書式が崩れるのは、この「構造解析」と「再配置」の2つの工程のどこかです。 手元にあるドキュメントに応じた適切な選択肢は以下の通りです： 元の .docx や .pptx がある場合：PDFではなく元ファイルを翻訳するのが確実です。 表の少ない文字中心のPDF（10 MB未満）：Google 翻訳のドキュメントアップロード機能などが手軽な選択肢になります。 表・数式・二段組を含む論文やマニュアル：レイアウトを再構築する専門ツールを選び、後述する4か所のポイントを確認してください。 文字選択ができないスキャンPDF：翻訳の前に文字認識（OCR）が必要です。DeepLなどはスキャンデータを受け付けてOCRも自前で処理しますが、Google 翻訳ではスキャンページが未翻訳のまま残る場合があります。 1. 翻訳ツールはPDFの中に何を見ているのか 版面（レイアウト）を読み取らない一般的なツールがどのようなテキストを翻訳の材料にしているのか、具体的な例を見てみます。ここでは arXiv の論文2本（LLaMA および Mistral 7B）を用意し、オープンソースPDFツール MuPDF の mutool でテキストを抽出しました。 1.1 表は単なる数字の列に分解される LLaMA 論文の表3（10個のモデルを8つのテストで比較した表）を例にとります。 これをテキスト抽出すると、102行の連続した文字列に変わります。 BoolQ PIQA SIQA HellaSwag WinoGrande ARC-e ARC-c OBQA GPT-3 175B 60.5 81.0 - 78.9 70.2 68.8 51.4 57.6 Gopher どの数値がどのテストに対応しているかをツールに伝える手がかりは失われます。これをそのまま翻訳ボックスに貼り付けても表構造は復元されず、単語は翻訳されても表そのものは消えてしまいます。 1.2 文の途中に表全体が割り込む LLaMA 論文3ページの右欄末尾は "we need to" で途切れています。 続きは4ページ左欄、表3を挟んだ下部にあります。 抽出されたテキストストリームでは、文の途中に脚注や改ページ、表3の102行とそのキャプションがすべて割り込んでいます。 To fully benefit from this optimization, we need to 2facebookresearch/xformers BoolQ PIQA … Table 3: Zero-shot performance on Common Sense Reasoning tasks. reduce the memory usage of the model by using ページごとや抽出順のまま翻訳するツールでは、この離れた2つの断片をつなぎ合わせることができません。結果として、ページ下部で切れた文と、表の下に唐突に現れる文の後半が別々に翻訳されます。 1.3 添字と分数が別文字に化ける Mistral 論文の変数 h_i（添字 i 付きの変数）を抽出すると、添字情報が失われて単なる英単語 hi に変化します。 former to attend information beyond the window size W. The hidden state in position i of the layer k, hi, attends to all hidden states from ツールにとって hi は一般的な英語単語と区別がつきません。 さらに複雑なのが分数です。LLaMA 論文のある箇所では、4d の 3分の2（\frac{2}{3}\cdot 4d）という重ね組みの分数が書かれています。 improve the performance. We use a dimension of 2 34d instead of 4d as in PaLM. 4d の 3分の2 が 34d に変わってしまっています。上付き・下付き文字や分数記号は描画位置情報に依存しているため、座標を考慮しない抽出では全く異なる値になってしまいます。 1.4 単語が行末ハイフネーションで分断される 二段組の論文では行末での単語分割が多く発生します。LLaMA 論文では、ハイフンで分割された一般単語が242行にのぼります。 We introduce LLaMA, a collection of founda- tion language models ranging from 7B to 65B … (175B) on most benchmarks, and LLaMA- 65B is competitive with the best models, founda- と tion はハイフンを外して1つの単語につなぎ直す必要がありますが、LLaMA- と 65B の間のハイフンはモデル名の一部として保持しなければなりません。 2. どのような選択肢があるか 選択肢 長所 限界 翻訳ボックスにコピー＆ペースト 手軽に即座に試せる 表、数式、レイアウトが失われ、文が途中で切れることも多い Google 翻訳の「ドキュメント」タブ 手軽に利用可能。.docx、.pdf、.pptx、.xlsx に対応 10 MB・300ページ上限。画像内文字やスキャンページは翻訳対象外。小型画面非対応 DeepL のファイル翻訳 Web版・デスクトップ版・API対応。スキャン対応。特定プランで編集可能 .docx 出力可能 アカウントが必要。プランごとに翻訳ファイル数の上限あり。CAD出力PDF等は非対応 Word に変換してから翻訳する 翻訳前に Word 上で修正・調整が可能 PDFからWord変換時に生じた誤りや崩れがそのまま残る レイアウトを再構築する翻訳ツール 表、数式、分割された文を構造として扱う 元ファイルと完全に同一にはならず、テキスト長の変化による改行やフォント調整が生じる ※ Google 翻訳と DeepL についての記述は、各サービスの公式ヘルプページ（2026年10月7日確認時点）に基づきます。 私たちが開発している Equalang のドキュメント翻訳は、まさにこの「レイアウト再構築型」のアプローチをとっています。ページの切れ目で分割された文をつなぎ直し、結合セルや複数行ヘッダーを持つ表も構造を保ちながら再構築します。数式最適化オプションも用意しており、日本語、英語、中国語、韓国語、スペイン語、フランス語などに対応しています。 なお、Equalangは新規登録で200クレジットが付与されるため、手元のPDFで実際の再現性を確認していただけます。 3. PDFを翻訳したら確認すべき4つのポイント どのようなツールを用いた場合でも、翻訳後には以下の4か所を確認することをおすすめします。 表の整合性：ヘッダー行が対応する列の上にあるか、数値が変わっていないか。 改ページ部と表の下のテキスト：ページ下部や表の直後で文が途切れたままになっていないか。 数式と変数：文中の記号が英単語に化けていないか、分数が別の数字になっていないか。 ページ数とリンク：ページ数が不自然に増減していないか、目次リンクが正常に動作するか。 参考資料 Touvron et al., "LLaMA: Open and Efficient Foundation Language Models", arXiv:2302.13971v1, CC BY 4.0. Jiang et al., "Mistral 7B", arXiv:2310.06825v1, CC BY 4.0. Google 翻訳 ヘルプ, Translate documents & websites, 2026年10月7日確認. DeepL ヘルプセンター, Translate PDF files, 2026年10月7日確認. 実測方法: テキストは2026年10月7日に MuPDF 1.25.6 で抽出（コマンド mutool draw -q -F txt -o out.txt in.pdf）。図は論文ページの切り抜きで、強調は筆者が入れたものです。

クラシック・データサイエンスの現在地 #2 k-means — 少数の代表から圧縮・検索・学習へ はじめに k-meansは、今も現役です。データのグループ分けに加え、ベクトル検索や画像モデルの学習データ選定にも使われています。 そのつながりを知るには、「近い点を集める」から少し視点を変えると分かりやすくなります。 たくさんのデータを、少数の代表値で表す。 まず、何を「よい代表」とするか、その求め方と限界を見ていきます。そのうえで、得られた代表値やクラスタが、圧縮・検索・学習にどう使われるかをたどります。 「クラシック・データサイエンスの現在地（Not old, but Classic Data Science）」の第2回です。第1回のBootstrapと、シリーズを始めた背景はこちら。 zenn.dev 1. 写真を8色にすると、何が失われる？ 元の色を、代表色に置き換える 写真の各画素を、8つの代表色のどれかに置き換えてみます。値を有限個の代表値で表す、この操作が量子化です。 左が元画像、右が8色で再構成した画像。りんごの陰影や木目の細かな色の違いが失われています。 代表色の一覧を共有すれば、各画素には色そのものではなく番号を記録できます。8色なら3ビット。ただし、画像全体には色の一覧や画像サイズの保存も必要です。 では、どの8色を選べばよいのでしょうか。 「元の色に近い」を、数値で決める RGBの各成分の差を二乗して足し、置き換えによる誤差とします。元の色が (240,30,30)、代表色が (220,40,40) なら、 (240-220)^2+(30-40)^2+(30-40)^2=600 全画素の誤差を合計し、それを小さくする代表色を探します。最小化したい、この合計が目的関数です。 ただし、RGB上の距離と、人が感じる色の違いは完全には一致しません。ここでの「よい」は、数値上の近さです。 同じ代表に集まる点が、クラスタになる 代表色が決まっていれば、各画素を最も近い色へ割り当てればよい。同じ代表色に割り当てられた画素の集まりが、クラスタです。 見方 注目するもの 量子化 どの代表値で近似するか クラスタリング どの点が同じ代表値に集まるか 一般には、n 個のデータ x_i\in\mathbb{R}^d と中心数 k を与え、中心 \mu_j\in\mathbb{R}^d と各点の所属 c_i\in{1,\ldots,k} を求めます。 \min_{\mu_1,\ldots,\mu_k,\;c_1,\ldots,c_n} J=\sum_{i=1}^{n}\left|x_i-\mu_{c_i}\right|^2 代表値の位置と割り当てを、同時に選ぶのがk-meansの問題設定です。 中心数 k も、この最適化で自動的に決まるものではありません。写真で「8色」と先に決めたように、用途に合わせて与えます。 中心は観測された点に限りません。この式では空のクラスタも許されますが、その場合は平均を計算できないため、実装では中心の再配置などで対処します。 2. よい代表値を、どう求める？ 片方を固定すれば、もう片方が決まる 各点に k 個の番号を付ける候補は k^n 通り。同じ分割の重複も含みますが、全探索は点数とともに難しくなります。 そこで、中心と割り当てを一度に決めず、片方ずつ求めます。 固定するもの もう片方の求め方 中心の位置 各点を最も近い中心へ割り当てる 各点の割り当て 各クラスタの平均を中心にする なぜ平均なのか。2画素 (240,30,30) と (200,50,50) を1色で表すと、片方の色を使う場合の誤差合計は2,400。平均 (220,40,40) なら1,200に減ります。 片方の画素を誤差なく表すより、平均色で両方を近似したほうが、全体の誤差は小さくなります。 空でないクラスタでは一般に、二乗誤差を最小化すると、中心は平均になるのです。 平均が最適になる理由 点の集合 C とその平均 \bar{x} について、任意の中心 \mu に対して、 \sum_{i\in C}|x_i-\mu|^2 =\sum_{i\in C}|x_i-\bar{x}|^2 +|C||\mu-\bar{x}|^2 第1項は \mu によらず、第2項は0以上。\mu=\bar{x} のとき最小です。 割り当てと平均を繰り返す、Lloyd法 初期中心を用意し、「最も近い中心への割り当て」と「平均への移動」を交互に繰り返します。 説明用の75点・k=3。右は同じ所属のまま中心を1回更新。収束後ではありません。 Lloydの原論文（1982年掲載）が扱ったのも、信号を限られた代表値で伝える量子化の問題でした。 最近傍への割り当ては各点の誤差を、平均への移動はクラスタ内の誤差合計を最小にします。どちらも、もう片方を固定した条件での最適化です。 各更新で、同じデータに対する J は増えません。0以上なので目的関数の値は収束します。 ただし、誤差が減ることと、大域最適解が得られることは別です。 したがって、途中で改善が止まったことだけでは、すべての中心と所属の組み合わせを比べたことにはなりません。 片方だけ変えても改善しない配置でも、中心と所属を同時に変えれば、さらに小さい誤差が得られるかもしれません。初期値が違えば結果も変わります。 1点ずつ更新するMacQueen法との違い MacQueen（1967）§2.1の逐次手順では、新しい点を最も近いクラスタへ追加し、平均をすぐに更新します。次の点は更新後の中心で割り当てます。 すでに m 点あり、平均が \mu のクラスタへ点 x を加えると、 \mu'=\frac{m\mu+x}{m+1} =\mu+\frac{x-\mu}{m+1} この1巡では過去の点を割り当て直さず、初期中心と到着順に結果が依存します。また、対象データが増えるため、Lloyd法の「同じデータの誤差は増えない」という性質は、そのまま使えません。 3. 誤差が小さければ、よい分類？ 欲しかったグループと、距離でできるグループ 写真の色を近似するなら、元の色との距離は自然な基準です。でも、顧客を購買傾向で分けたい場合も、それで十分でしょうか。 k-meansが見るのは特徴量と距離です。購買意向や、点のつながりを直接捉えるわけではありません。 同じ点でも、作成時のグループとk-meansの分割は一致しません。左のラベルは学習に使っていません。 身長をcmからmmに変えるだけでも、その成分の差は10倍、二乗距離への寄与は100倍になります。 数値上の誤差を小さくできても、業務で意味のあるクラスタが得られたかは別に確かめる必要があります。 まず特徴量と尺度を見直す。ただし、標準化だけで任意の構造を捉えられるわけではありません。 つながりや密度ならDBSCAN系、所属の不確かさや分布の広がりなら混合モデルなど、目的に合う方法を選びます。scikit-learnの比較も参考になります。 初期値が違うと、結果も変わる 同じデータでも、初期中心が違えば、異なる配置で改善が止まることがあります。 上と同じ75点・k=3。丸枠は初期中心、星は収束後。右は左側を細分し、右側をまとめています。 初期中心を変えて複数回実行し、誤差の小さい結果を選ぶ方法があります。選び方を工夫するのがk-means++です。 最初の1点はランダムに、以後は既存の中心までの最短距離の二乗に比例する確率で選びます。まだ代表されていない領域を選びやすくしますが、近似保証は初期化後の誤差の期待値に関するもので、毎回最適になる保証ではありません。 全点を繰り返し調べるコストを減らす Lloyd法では、毎回すべての点と中心の距離を比べます。MiniBatch k-meansは、少数の点を取り出して中心を更新します。 左は更新前の全88点、右は16点で1回更新。352回と64回は距離評価数で、処理時間ではありません。 更新は軽くなりますが、Lloyd法と同じ結果や、毎回の全データ誤差の減少は保証されません。 4. その結果が、圧縮・検索・学習に使える クラスタを「正しい分類」と解釈しなくても、代表値や所属は役立ちます。 代表値で近似する：PQによる圧縮 写真の色番号と同じく、Product Quantization（PQ）は、多次元ベクトルを分割して各部分を代表の番号で表します。 橙は元の値、緑の星は代表。番号から各部分の代表を取り出し、連結して復元します。 部分 元の値 選んだ代表値 保存する番号 前半 (1.2,2.3) (1,2) 0 後半 (8.7,7.6) (9,8) 2 コード (0,2) から復元するのは (1,2,9,8)。元の値との二乗誤差は0.38です。写真の色番号と同じく、番号と代表の対応表（コードブック）を共有します。 各部分に3個の代表があれば、組み合わせは 3\times3=9 通り。コードブックはk-meansなどで学習し、その保存容量も必要です。 Faissには、圧縮コードから距離を評価する IndexPQ と、区画分けも使う IndexIVFPQ があります。 クラスタで区切る：IVFによる検索 100万個のベクトルを毎回すべて比較する代わりに、クラスタごとのリストを作ります。 クエリに近い中心を選ぶ → その区画内を比較する → 近い候補を返す。 これがk-meansを使ったIVF検索です。中心は答えそのものではなく、探す場所を示す案内板になります。 原図の説明用260点。星は区画の中心、＋はクエリ。近い点でも、別の区画にあると見落とします。 同じ点とクエリで、訪れる区画数 nprobe だけを増やすと、次のようになります。 訪れる区画数 比較する候補 真の上位5点の回収 1（図） 29 / 260点 3 / 5点（60%） 2 88 / 260点 5 / 5点（100%） この例では、探索範囲を広げると見落とした2点を回収できますが、比較する候補も増えます。必要な速度と再現率のバランスは、実データで確認します。 クラスタが「猫」「犬」を意味する必要はありません。検索範囲を絞れれば役立つからです。なお、IVFの区画分けにk-meansが必須なわけではありません。 PQも組み合わせると、検索範囲と保存量の両方を減らせます。NVIDIA cuVSの解説（2024年）では、区画とPQコードブックの学習の両方にk-meansを使っています。近似には誤差が伴い、検索精度・メモリ・速度の調整が必要です。 別の選択肢には、近い点を結ぶグラフをたどるHNSWがあります。Faissも提供しており、精度やメモリ、索引の構築・更新コスト、実行環境で使い分けます。 番号を仮の正解にする：DeepCluster DeepCluster（2018年）は、CNNで抽出した画像特徴をk-meansで分け、クラスタ番号を擬似ラベルとしてCNNを学習します。 上段で擬似ラベルを作り、下段ではそれを固定してネットワークを更新。更新した特徴で、再びクラスタリングします。学習手順の概念図です。 「クラスタ7＝猫」と分かっている必要はありません。番号の予測を通じて有用な画像特徴を学ぶのが狙いで、k-means自体には勾配を流しません。公式実装はこちら。 学習するデータを選ぶ：DINOv3 DINOv3（2025年）§3.1では、DINOv2の画像特徴に階層的k-meansを適用し、階層に基づくバランスサンプリングで学習画像を選んでいます。 データ選定の一部を模式化。実際は5段階の階層を使います。点の数や群の大きさは実測値ではありません。 DeepClusterが番号を「予測する」のに対し、こちらは群の偏りを抑えてデータを「選ぶ」ための構造です。意味上のクラスが均等になる保証ではありません。 検索による選定や既存データセットも併用しているので、性能をk-meansだけの効果にはできません。それでも、大量の特徴ベクトルを整理する工程で、古典的な手法が使われています。 5. 2026年に学ぶ価値はある？ 今回の判定は、現役です。 2026年10月31日に確認した資料と2024〜2025年の解説・論文には、圧縮・検索・データ選定の具体例があります。ただし、これだけで利用率や現在の主流までは判断できません。 学ぶなら、まず写真の8色化とLloyd法の図を行き来してみてください。「何を固定し、どの誤差を減らすか」と、最適解を保証しない理由を一緒に追えます。 手法として使う：データをクラスタに分ける。 部品として組み込む：検索の区画や、データ選定の階層を作る。 考え方を広げる：多数の値を少数の代表で近似し、短いコードで表す。 写真の8色化から、検索や学習の準備まで。共通するのは、代表値や所属を求めたあと、その結果を次の処理へ渡すことです。 k-meansがClassicなのは、長く使われてきたからだけではありません。何を「よい代表」とするか、その求め方と限界を理解すると、今の技術を支える仕組みまで見通せる。その見通しのよさに、今学ぶ価値があります。 参考 scikit-learn — Clustering：目的関数、初期化、MiniBatch、ほかの手法との比較。 Lloyd, “Least Squares Quantization in PCM” (1982)：量子化の原論文。 MacQueen, “Some Methods for Classification and Analysis of Multivariate Observations” (1967)：§2.1の逐次更新。 Arthur & Vassilvitskii, “k-means++: The Advantages of Careful Seeding” (2007)：初期化と期待値での近似保証。 Sculley, “Web-Scale K-Means Clustering” (2010)：MiniBatch k-means。 Jégou et al., “Product Quantization for Nearest Neighbor Search” (2011)：部分ベクトルの量子化と近傍検索。 Faiss — Faiss indexes、Building blocks：PQ・IVF・HNSWとコードブックの学習。 Caron et al., “Deep Clustering for Unsupervised Learning of Visual Features” (2018)：擬似ラベルによる画像特徴の学習。 NVIDIA cuVS — IVF-PQ Part 1, Deep Dive (2024)：GPU検索における区画分けと量子化。 Vo et al., “Automatic Data Curation for Self-Supervised Learning: A Clustering-Based Approach” (2024)：階層的クラスタリングによるデータ選定。 Siméoni et al., “DINOv3” (2025), §3.1：学習データの選定と組み合わせ。

ProgramBench: Can Language Models Rebuild Programs from Scratch?