CONTACT →
Daily AI Briefing
毎日のようにAI関連のニュースが届きますが、その多くは一次情報ではなく、ノイズも少なくありません。研究機関・開発企業・第一線の専門家による発信の中から、本当に押さえておきたい情報だけを厳選してお届けします。
Nathan Lambert が、Reflection が自社最強のモデルを公開したものの中国勢の後ろに付ける形になり、Nvidia や Thinking Machines と同じ位置に並んだと指摘しています。この件はいろいろと深読みされがちだが、最も明快な結論は「中国勢はLLMを作るのが非常にうまい」ということだ、との見方です。
モデル選定の前提が変わりつつある話です。性能で選ぶなら中国系モデルが候補から外せなくなり、ライセンスやホスティング先の整理を先にやっておく必要があります。
AK が Hugging Face Papers の新着「Octrees as an Explicit 3D Language」を紹介しました。オクトツリー（八分木）を3D表現のための明示的な言語として扱うアプローチの論文です。
3Dを離散トークン列として扱えると、既存のLLM/自己回帰モデルの道具立てがそのまま使えます。3D生成をテキスト生成と同じスタックに載せたい場面で効いてきそうです。
同じく AK の紹介で、「Scaling Trajectories for Complex Tasks through Recursive Self-Rewrite」。複雑なタスクの実行軌跡（trajectory）を、再帰的な自己書き換えによってスケールさせる手法を扱っています。
エージェントの長い作業ログを学習データに変える方向の研究です。人手でトラジェクトリを集めるのが最大のボトルネックなので、自己書き換えで増やせるなら実務の学習コストに直結します。
AK が「Rollout-Marginal Distillation for Long-Horizon Autoregressive Video Generation」を紹介。長いホライズンの自己回帰的な動画生成に向けた蒸留手法の論文です。
自己回帰で長い動画を作ると誤差が蓄積して崩れるのが定番の課題です。蒸留でそこを抑えられるなら、短いクリップ止まりだった用途が実用の尺に届きます。
Hamel Husain が evals FAQ の一項目として「evals はどのくらいの頻度で実行すべきか」に回答しました。答えは、実行コストとその eval がどれだけ飽和しているかを、エラーを捕まえることのビジネス価値と天秤にかけて決める、というもの。FAQ 全体もブログで公開されています。
「毎コミットで全部回す」は現実的でなく、飽和した eval を回し続けても情報が増えません。CIに組み込む eval と週次で回す eval を分ける設計の指針として使えます。
PyTorch が、この2年で Meta がメディア関連スタックを TorchCodec / TorchVision / TorchAudio の3ライブラリに統合してきたと説明しました。TorchCodec が画像・動画・音声のCPUおよびCUDAでのデコード／エンコードを担う単一の置き場所になります。
データローダ周りの依存が整理される話で、既存のコードが TorchVision/TorchAudio のI/Oに乗っているなら移行先を把握しておく必要があります。
PyTorch Accelerator Integration Working Group が、プラットフォーム横断で標準的なハードウェア有効化の仕組みを整えようとしていると発表。バックエンドをまたいだテスト、プロファイリング、コンパイラ対応、分散実行の統一を狙うもので、今年の成果が共有されています。
NVIDIA以外のアクセラレータを選べるかどうかはこの手の標準化次第です。推論基盤のコストを見直すときの選択肢の広さに関わってきます。
Ethan Mollick が、現在のAI政策、特にラボ側から出てくるものについて疑問を呈しています。超知能が間近だと信じるなら、AIをどう作れば世界が良くなるかという難しい判断は不要で、ASIが決めてくれるのを待てばいい。しかし、そうならなかった場合は――という問題提起です。
作る側の設計判断を先送りしない、という話として読めます。今の世代のモデルで何を任せて何を人が持つかは、結局自分たちで決めるしかありません。
Samir Saci による記事の紹介。OpenClaw のエージェントが12のサプライチェーン担当ペルソナを動かし、ミラノの倉庫からの航空輸送注文を追跡して、配送遅延の理由を説明するという構成です。
1体の万能エージェントではなく役割ごとに分けた構成の実例です。業務の担当分けをそのままエージェント分割に写す作り方は、既存業務の自動化で真似しやすい形です。
Himanshu Sharma が、従来型のテキスト分類器が実際にどれだけのラベル付きデータを必要とするのか、そして追加データで何が得られるのかを計測した記事です。すべてのテキスト分類問題にLLM APIが必要なわけではない、という切り口です。
分類タスクをLLMに投げると推論コストとレイテンシが毎回乗ります。必要なデータ量が見えていれば、軽量モデルに落とす判断を数字で下せます。
Anubhab Banerjee による解説。ごく最近までAIは真の System 1（速い直感的処理）を持てず、開発者は単純で一瞬の判断にまで遅くおしゃべりな System 2 型モデルを使わざるを得なかったと述べ、LLMと System One モデルの境界と使い分けを論じています。
ルーティングの設計論として実用的です。頻度の高い小さな判断を軽いモデルに寄せるだけで、コストと応答時間が桁で変わる場面があります。
こうした動きを、自社の業務にどう活かせばいいか ―
迷ったときに相談できる窓口があります。