LLMは「真実」より「他モデルの答え」を当てるのが得意
LLMは実際に正しい答えよりも、他のモデルが何と答えるかを予測する方が得意だという研究。誤るときはモデル同士が揃って同じ誤りに陥るため、複数モデルの多数決（polling）では正解を取り戻せない、とICML採択論文で報告している。
メモ
出典 @StanfordAILab↗
複数モデルのアンサンブルや自己一貫性で精度を担保する設計の落とし穴。相関した誤りは投票では消えない。
学習データの重複除去の「取りこぼし」が計算資源を最大33%浪費
重複除去（deduplication）は標準的だが完璧にはできない。この研究は残った重複が計算資源換算でどれだけコストになるかを測り、最悪ケースの繰り返し構造がモデルサイズから予測可能だと示す。組み合わせ次第で計算量の最大33%が無駄になり得るという。
メモ
出典 @StanfordAILab↗
事前学習のデータ設計が学習効率に直結するという定量的な指標。dedupの詰めが甘いと、丸ごと計算を捨てることになる。
LLMは事実をどこに蓄え、どう引き出すのか——Gemmaで層をたどる
LLMが事実をどのように格納し、どの経路で引き出すのかを、GemmaファミリーのモデルでSubhanga Upadhyayが解説。事実想起（factual recall）の経路を、Transformerの各層にわたって追跡する解釈可能性の記事。
メモ
出典 @TDataScience↗
モデル内部で知識がどこに宿るかを知ることは、知識編集・アンラーニングや幻覚対策の足がかりになる。
散らばったツールをMCPで束ねる——壊れやすいエージェントを安定化
エージェントシステムはツールがスタック全体に散在すると保守が難しくなる。Priyansh Bhardwajが、MCP（Model Context Protocol）を使って脆弱な構成を、安定して発見可能なアーキテクチャへ作り替えた過程を解説している。
メモ
出典 @TDataScience↗
自作エージェントのツール管理が破綻しがちな人向け。MCPを「整理の型」として使う実例として読める。
text-to-SQLで学ぶ、なぜ「1エージェント」では足りないのか
text-to-SQLパイプラインを題材に、マルチエージェントシステムの設計手順をPriyansh Bhardwajが解説。1つのエージェントでは不十分になる場面がある理由を説明している。
メモ
出典 @TDataScience↗
単一エージェントを分割すべきかの判断材料になる。分割は万能ではないが、責務分離が効く典型例。
CrewAIやLangGraphの前に——多くのLLMアプリはフレームワーク無しで足りる
CrewAIやLangGraphなどのフレームワークを選ぶ前に、もっと単純な問いを立てるべきだとShuai Guoが指摘。多くのLLMアプリケーションは、フレームワークを使わなくても十分に動く、と示している。
メモ
出典 @TDataScience↗
「まず薄く自前で書く」判断の後押し。抽象化レイヤを入れる前に、そのコストを見極める視点。
実務の検索はこう組む——キーワード常時＋埋め込み＋最後に1回のLLM呼び出し
「並列のアンカー検出、キーワードは常に、埋め込みも併用し、最後にLLM呼び出しを1回」——Angela Shiが企業向け文書インテリジェンス連載で、検索（retrieval）の実装メカニクスを分解している。
メモ
出典 @TDataScience↗
RAGを「埋め込みだけ」で組みがちな人向け。キーワードと埋め込みのハイブリッド＋LLM最小化という現実解。
AIエージェントを扱う仕事は「マネジメント」に近づく
AIエージェントとの協働がマネジメントに近づくにつれ、AI時代に向けた大規模なマネジメント教育が要るのではとEthan Mollickが提起。米政府はかつて第二次大戦中に工学・科学・マネジメントの戦時訓練プログラム（ESMWT）を実施し、それが戦後の好況の大きな要因になったと振り返る。
メモ
出典 @emollick↗
エージェント運用は「指示・委任・監督」の技能に寄っていく。個人スキルより組織的な教育設計の話として面白い。
「vibecoding」のフロントエンド、半年前はもう大昔
AIに任せて雰囲気で作る（vibecoded）フロントエンドの設計は進化が速く、半年前のものがもう大昔に見える、とEthan Mollickが短くコメントしている。
メモ
出典 @emollick↗
AI生成UIの流行り廃りの速さ。ツールもプロンプトの作法も陳腐化が速い前提で作る必要がある。