崩壊荷重を超えた梁を「解けた」と返す言語モデル、実現できるかだけ聞けば拒めた
·248 文字·2 分
今日のご案内 ☕✨ # Yang氏とWang氏は、梁の荷重と円板の回転数を、塑性崩壊や破裂の限界より決まった割合だけ上か下に置き、12の言語モデルに合計4,860回解かせた。3つのモデルは、別の問いでは限界をきちんと計算できたのに、崩壊を10〜30％超える梁を「解けた（solved）」として返した。同じ設計でも「実現できるか」だけを聞くと、拒めたモデルがある。
前回との違いを先に書く。前回は、テストを「誰が、見えないデータで」確かめたかを見た。今回は、その確かめを「どんな問い方で」したかで答えが変わる例が並んだ。言語モデルの「解けた」、学習点の選び方で場所だけ移る精度、全体では合っても深い所で外れるPINN（物理の式を損失に入れたニューラルネットワーク）だ。企業の発表は3本。うち2本は、効果の数字か比べる相手のどちらかが発表文に無い。
1. 崩壊荷重を10〜30％超える梁を、3つの言語モデルが「解けた」と返す、実現できるかだけ聞けば拒めたモデルも # Yang氏とWang氏は、梁の荷重と円板の回転数を、塑性崩壊や破裂の限界より既知の割合だけ上か下に置いた問題を作った。各モデルの限界の計算は別の問いで測り、12のモデルを4,860回の呼び出しで試し、新しい設計での追加の実験もした。あるモデルは、実現できるかだけを聞かれると無理な設計を見抜くのに、完全な答えを求められると同じ設計を「解けた」として受け入れた。3つのモデルは、限界を別の問いで正確に計算していながら、崩壊を10〜30％超える梁を受け入れた。受け入れた答えの多くは、違反していることを本文に書いていた。実現できるかだけを聞いた場合、Opus 5とGemini 3.8 Flashは、与えられた無理な新しい設計をすべて拒み、誤って拒んだ例は無かったという。断る条件の言い方や答えの形式を変えると、元の梁では拒む割合が上がったが、新しい設計では一貫しなかった。
💡 注目しておきたい理由: ソフトがモデルの「解けた」を信じて次へ渡すと、物理的に無理な設計がそのまま流れる。著者は、実現できるかの判断と、完全な答えの中で拒めるかを別々に試し、使った問いの文面をそのまま報告すべきだとしている。言い換えの効果が新しい設計で一貫しなかったので、問いを直しても安心はできない。
🔗 情報源: arXiv 🕰️ 公開日時: 2026-10-28 🗂️ 分類: 言語モデル・実現可能性と「解けた」は別 2. CELUS、電子設計の初期を受け持つエージェントをベータ公開、技術者が計画を承認するまで動かない # CELUSは10月29日、Design Assistantにエージェント型の作業の流れを加え、CELUS Design Platformでベータ公開したと発表した。回路図を描く前の、構成と部品を決める段階を受け持つ。技術者が製品を説明すると、アシスタントがインターフェース、電力の予算、コスト、規格への適合を聞き、答えと手順の計画をIntent Documentに書く。技術者が計画を承認するまでは何も実行せず、途中で止めたり直したりもできる。部品を勧めるときは、根拠のデータシートや仕様を示す。最後にIntent Documentの要件と設計を比べ、満たしていない要件を知らせるという。1つの依頼は、計画と確認をする分、1回の問いより時間がかかるとも書いている。