watanko

株式会社パンハウスでdeveloperをしています

[あやせひろみ @hiromi_ayase]

FuguのベースになってるConductorは強化学習でモデルオーケストレーションをやるって論文で結構面白いと思う
https://t.co/xeRfUXquzs

[elie @eliebakouch]

to be clear, this is a closed source orchestrator on top of closed source models. if before you didn't control the models, now you don't even control which ones are used or how much. this is not "AI sovereignty"

i've also read the tech report to get an opinion on the technical stuff:

fugu (not the ultra version) is basically a classifier that selects which model at each turn is most likely to answer correctly (in other words a router). this leads to -10 points on SWE Bench pro compared to opus, gets some gains on other benchmarks but very slight. argument could be that it reduces cost, but no information about this so it's likely the opposite. they also have an autoresearch benchmark where they compare to frontier models "Model A, B and C" which is really crazy to not be transparent about what models you compare against. let's also say that this probably doesn't support adding new llm out of the box since you need to retrain the classifier

about fugu ultra, this is basically and advanced plan mode and orchestrator, this is a model that for a query outputs a plan with multiple "workflows". my understanding of workflows is that they say: "spawn model A subagents to achieve this, then use model B to judge it, then summarize this with model C" which is just a test time scaling compute strategy. i think this is an okish way to do it, but it's limited by the fact that they need to predict everything before the agents start working, which is why they limit this to 5 steps. imo you need to predict what to spawn at t+1 with the information you get at t, not with the info you get at t=0. there are also other issues such as fable 5 score on terminal bench being wrong and them being super vague and unclear about which model is in the LLM pool (they only mention closed source api one)

the biggest and most obvious issue is that they are introducing a "test time scaling" method with "best of N" over models, and they literally NEVER REPORT the number of output tokens or cost to achieve a benchmark/task

the good comparison here is not with opus, but it's opus with ultracode/workflows enable, not with kimi, but with kimi swarm ect.. very very confusing release

[watanko @watanko_]

ensembleすれば性能上がるのは至極当然な気がしてて、むしろそれはコスト的に地獄の釜が開いただけな気がするんだけどなあ
内部でスーパー職人技orchestrationがなされているからこそこの性能というならめちゃくちゃ価値あるけど

[watanko @watanko_]

ensembleするだけでなく、秘伝のタレ的な構成が存在するんだろうか

[Sakana AI @SakanaAILabs]

Introducing Sakana Fugu: A full multi-agent orchestration system accessible via a single model API.

Our ‘Fugu Ultra’ model matches the performance of Fable and Mythos, delivering frontier capability without the risk of export controls.

Try it: https://t.co/hhO6qTawgb 🐡

[荒川 豊 (Yutaka Arakawa) | 九大 | 福岡未踏 @rkwy]

カカクコム、800万行、1.3万テーブル（最長レコード数、5.89億行）という技術負債を全面刷新中。

3層・合計71体のAIエージェントにより、C#・Classic ASP混在のコードをPython・FastAPI・htmxへ全面移行。

設計者の月額AI利用料は実に440万円。高いけど、逆にいうと、人間を雇用して同じことをやろうとしたら、こんな費用ではできないので安い気もする。

価格コムに限らず、技術負債を抱えた古いシステムは大量にあるわけで、今後の参考になる資料。

保険カテゴリのコードは43%へ、クレカカテゴリのコードは66%へ。今後の保守メンテコストを抑えることができるのでスリム化は重要。

━━━━━━━
価格.comをAI駆動で全面刷新する ー 30年分の技術的負債を返し、次の30年の土台をつくる ー / AI Engineering Summit Tokyo 2026 https://t.co/HaC7h0wLSn

#speakerdeck

[watanko @watanko_]

これやりたい

[野川の側 @nogawanogawa]

PRごとに検証環境が立ち上がる仕組みをTerraform × GitHub Actionsで作った話 - エムスリーテックブログ https://t.co/mTYUVb1gW0

[野川の側 @nogawanogawa]

PRごとに検証環境が立ち上がる仕組みをTerraform × GitHub Actionsで作った話 - エムスリーテックブログ https://t.co/mTYUVb1gW0

[chokudai(高橋 直大)@AtCoder @chokudai]

なんかおかしいなーと思って、社内で長文読解系のベンチマーク作って回してるんだけど、Opus 4.8さんマジで大丈夫……？ちょっと酷過ぎるよ……？

[Itaru Tomita / 冨田到 @itarutomy]

GrepSeekが発表された（https://arxiv[.]org/html/2605.29307v1）。

RAGのベクトルインデックスを丸ごとなくして、grepコマンドでWikipedia 2100万文書を直接検索する手法「DCI（Direct Corpus Interaction）」を、9Bの小型モデルQwen3.5-9Bに学習させた研究。

まず前提を整理する。通常のRAG（検索拡張生成）はテキストをあらかじめベクトルに変換して事前インデックスを構築し、「意味的に近い」ドキュメントを返す。速いが固定チャンク単位に縛られ、「親会社と子会社の区別」「化学式の完全一致」のようなケースで混同しやすい。一方、DCIはインデックスを持たず、grep/rgコマンドで生テキストを直接検索するので任意粒度の文字列を精確に取り出せる。

先行DCIはClaude等の大型モデル依存で1クエリ最長1時間かかっていたが、GrepSeekは小型モデルに学習させることでこれを解決した。ただし直接RLをかけると「コマンドが広すぎてコンテキストが爆発する」崩壊が頻発し、1024GBのRAMでも枯渇したと報告されている。

そこで2段階学習を設計した。「正解を知るTutor」がgrep証拠チェーンを逆算構築し、「正解を知らないPlanner」がそれを正方向の推論軌跡に変換して合成データ1万件を作成。SFT後にGRPO（グループ相対ポリシー最適化）で200ステップ強化学習する。

学習が進む中の挙動変化が面白い。最初はコマンドを複数回独立発行するが、ステップが進むにつれてパイプ（|）で繋いだ複合コマンドへ進化し、発行コマンド数が平均3.06回から2.56回に減少。1回の検索でより多くの情報を取る方向に自律的に洗練されていく。

7ベンチマーク中4つで最高F1（マイクロ平均0.5691、最強比較手法Search-R1は0.5441）。HotpotQAでは0.6231対0.5591と差が顕著。アブレーション実験でSFTを除去するとマイクロ平均0.3314まで落ちることから、コールドスタートデータが精度の土台になっている。

弱点はアクセント付き固有名詞や表記ゆれ（PopQAで有意低下）。クエリ1件あたりの推論時間もベクトル検索より長い。ただし事前インデックス構築が完全不要で、ベクトル検索ではA100 GPUで数十時間かかるインデックス作成コストがかからない点は大きい。

grepで検索を学習することのポテンシャルと限界が、同時に見えてくる論文。

[watanko @watanko_]

めちゃくちゃ面白い

[Itaru Tomita / 冨田到 @itarutomy]

「遠い物体は画像上部に映る」という自然写真のクセを、AIがそのまま空間理解の手がかりとして使っている実態を暴いた論文（https://arxiv[.]org/html/2605.30161v1）。

VLM（画像とテキストを同時に扱うAIモデル）に「AとB、どちらが遠い？」と問うと、多くのモデルは物体の「縦位置」で答えていることが判明した。自然写真では遠い物体ほど画像上方に映る（透視投影の法則）。このパターンを過学習している。論文ではこれを「垂直距離もつれ（vertical-distance entanglement）」と呼ぶ。

衝撃の数字。Qwen2.5-VL（200万サンプルで追加学習）の正解率は、遠い物体が画像「上」にある通常パターンで60.9%。「下」にある逆パターンでは24.0%まで落下（差: 36.9ポイント）。モデルの種類・サイズ・追加学習量を問わず、全ケースでギャップが正値として現れる。

驚くのは「データを増やしても必ず改善しない」点。Qwenは200万サンプル追加しても距離の内部表現がほぼ変わらず反例精度が悪化するケースも。一方、2000万超のQAで訓練したRoboRefer-2Bはギャップが27.3ポイントに縮小。2350億パラメータのQwen3-VL-235Bは平均精度0.908・ギャップ0.068まで到達した。

内部の特徴ベクトルを解析すると、「奥行き軸の一貫性（距離コヒーレンス）」が高いモデルほど複数ベンチマークで安定した高性能を示すことも判明。RoboReferが0.649に対し、NVILA+2Mは0.241。ベンチマーク精度が似ていても内部表現の構造は全く異なる。

「精度が高い＝空間を理解している」は安全な仮定ではない。どんな手がかりで答えているかを問うことが、空間AI評価の新たな軸になる。

[watanko @watanko_]

こんにちは笑
(画像はweekly集計)

[Kazuhiro Sera (瀬良) @seratch_ja]

唐突ですが・・首都圏在住 + 自他ともに認める Codex / OpenAI API のヘビーユーザーだという方、もしよかったら簡単なレスか Like をいただけないでしょうか？？

[watanko @watanko_]

正直もうコーディング性能はgpt5.5で十分な気がしてるので、いかにモデル蒸留し、あるいはthinking-lessに、同等の性能発揮できるかを考えた方が良さそう

[いとう @ INDX @k1ito]

昨日人工知能学会で僕が報告したのだが、
LLMのreasoning/thinkingのeffortを上げても情報抽出の精度は上がらないという現象がおきており、
Llama parseも報告していて面白い。
https://t.co/KiM5WdlaYp

[watanko @watanko_]

ありがてえ〜

[yousukezan @yousukezan]

Pythonパッケージマネージャー「uv」に、依存関係の脆弱性とマルウェアを検査する新機能が追加された。新たに導入された「uv audit」は既知の脆弱性や非推奨状態のパッケージを検出でき、さらにインストール時のマルウェアチェック機能も提供される。

開発元は6月8日、プレビュー機能として「uv audit」を発表した。これは依存関係をスキャンし、既知の脆弱性やプロジェクトの廃止・非推奨状態などを検出する機能で、既存のpip-auditと同様の用途を持つ。uvのロックファイルや設定情報を活用することで、典型的なプロジェクトではpip-auditより4～10倍高速に動作するとしている。

また、「uv add」や「uv sync」実行時にOSVデータベースを参照し、既知のマルウェアパッケージが依存関係に含まれていないか確認する機能も追加された。マルウェアが検出された場合、同期処理は中断される。

この機能は環境変数「UV_MALWARE_CHECK=1」を設定した場合のみ有効になる。現時点では公開されたアドバイザリ情報に基づいて判定を行う。

開発チームは今後、脆弱性を考慮した依存関係解決、OSV以外の脆弱性データソース対応、requirements.txtやpylock.toml対応などを検討しているとしている。
https://t.co/YChYy5bV1l

[yousukezan @yousukezan]

Pythonパッケージマネージャー「uv」に、依存関係の脆弱性とマルウェアを検査する新機能が追加された。新たに導入された「uv audit」は既知の脆弱性や非推奨状態のパッケージを検出でき、さらにインストール時のマルウェアチェック機能も提供される。

開発元は6月8日、プレビュー機能として「uv audit」を発表した。これは依存関係をスキャンし、既知の脆弱性やプロジェクトの廃止・非推奨状態などを検出する機能で、既存のpip-auditと同様の用途を持つ。uvのロックファイルや設定情報を活用することで、典型的なプロジェクトではpip-auditより4～10倍高速に動作するとしている。

また、「uv add」や「uv sync」実行時にOSVデータベースを参照し、既知のマルウェアパッケージが依存関係に含まれていないか確認する機能も追加された。マルウェアが検出された場合、同期処理は中断される。

この機能は環境変数「UV_MALWARE_CHECK=1」を設定した場合のみ有効になる。現時点では公開されたアドバイザリ情報に基づいて判定を行う。

開発チームは今後、脆弱性を考慮した依存関係解決、OSV以外の脆弱性データソース対応、requirements.txtやpylock.toml対応などを検討しているとしている。
https://t.co/YChYy5bV1l

[象牙山刘能 @disksing]

在AI时代，每个程序员都活成了自己最讨厌的那种 team leader：

1. 半年不写一行代码，编程能力严重退化，还自诩"我也是搞技术的“

2. 开会的时候把一线开发干的活全说成是自己的功劳，连自己的汇报材料都是让别人总结的

3. 瞎JB指挥，出了问题就甩锅说是下面没执行好

4. 不了解项目具体情况，只会提”单测加了没“、“性能还要优化”、“文档要沉淀一下”这类空洞的要求

5. PR 基本上看不懂，只会让别人先review了自己跟着点赞

6. 遇到 bug 了只知道无脑转发让别人查一下，自己负责来来回回转发消息

7. 还经常吐槽“今年的应届生水平越来越不行了”

[いとう @ INDX @k1ito]

「生成AIで10倍働いた結果、10倍年収が上がるようにする」にはカンパニー制・ホールディングス制にしてひたすら階層を浅く・オーナーシップを持った何でもやる人を増やすのが良い気がしている。
逆に普通の日本の会社の従業員がTokenmaxxするインセンティブってあるのか？
https://t.co/D387ZfH4PU

[watanko @watanko_]

そうなんだ（ドン引き）

[ゆかたゆ @yukata_yu]

機関投資家サイドは高速注文をするためにFPGAを使っていますし、通信ラグを減らすために「途中まで投機的にパケットを送っておいて最後にTCPのチェックに失敗することで破棄する」などのテクニックを使っていますよ。

[ちくわぶ @Prgckwb]

astral (uv, ruff の会社）の公式 skill があるの知らなかった、uv の skill には "Always use uv for Python work" などと書いてある

https://t.co/JeCRboLB2J