ああ、知識グラフQAっていうタスクで、LLMが生成した回答が正しいかどうかを、質問から抽出した軽い制約でチェックする手法なんだ。

「アスピリンはどの病気に効く？」みたいな質問に、知識グラフ（例えばHetionet）から答えを探すタスクだよ。LLMが候補を出すんだけど、それが間違ってることがあるから検証が必要なんだ。

質問から型・関係・除外の3種類の制約を抽出するんだ。例えば「アスピリンはどの病気に効く？」なら、型は「病気」、関係は「治療する」、除外は「副作用とかは除く」みたいな感じ。

LLMが生成した回答候補を、これらの制約で検証するんだ。でも知識グラフが不完全なことがあるから、単純に「制約を満たさないからダメ」とすると正しい答えを消しちゃう可能性がある。

そこでCES-PKでは3値意味論を使って、満足・違反・不明の3つに分類するんだ。不明の場合は削除しないで残すことで、誤った削除を防いでいる。

Hetionetで実験した結果、除外制約がフィルタリングに効果的で、正の関係制約が検証に寄与することが確認されたんだ。精度が向上して、再現率も維持できた。

そこはLLMを使って自動で抽出するから、手間はかからないよ。ただ、制約の抽出自体が間違ってる可能性はあるけどね。

ああ、今後の課題としては、制約の抽出精度を上げることや、他の知識グラフでの評価が必要だね。

そうだね。ただ、まだ研究段階だから、実用化にはもう少し時間がかかるかも。

君がまず卒業できるか心配だよ。

ああ、それは「偶発的コンテンツ冗長性」のことだよ。テスト問題で、測定したい能力とは関係ないのに、表現や文脈が似ちゃってる状態を指すんだ。

そう。例えば、数学の問題で「リンゴが3個」と「リンゴが5個」みたいに、数字以外の部分が同じだと、問題の意図とは関係なく似て見える。それがテストの質に影響するんだ。

うん、BLEUはn-gramの重なりを見るから、表面的な類似は捉えられるけど、意味的な関連性は見えない。コサイン類似度も、単語のベクトル化に依存してて、文脈をうまく捉えられないことがある。

このフレームワークでは、まず問題文を「構造分解」して、問題の骨組みと表面的な表現を分離する。それから「意味的関連性」を評価して、2つの軸で類似度を測るんだ。

まあ、そんなイメージ。LLMに問題文を分解させて、どの部分が測定対象で、どの部分が冗長になりやすいかを特定する。

LLMに問題文のペアを与えて、意味がどれだけ似ているかをスコア化させる。構造分解で得た要素ごとに比較するから、表面的な類似と意味的な類似を分けて見られるんだ。

実際の大規模テストのデータを使って、このフレームワークの類似度スコアが、心理測定上の指標（項目弁別力とか）や項目パラメータのまとまりとどれだけ整合するかを調べたんだ。

適応型テストでは、受験者の能力に合わせて問題を選ぶけど、似た問題を選びすぎると、測定の効率が落ちる。このフレームワークで冗長性を検出すれば、問題選択の際に避けられるんだ。

そうだね。LLMの判断に依存するから、モデルのバイアスや誤差が影響する可能性がある。あと、問題文の種類によっては、構造分解がうまくいかない場合もあるかもしれない。

うん、教育測定の分野では、こういう問題は重要視されてるからね。

それはそれで、テストの質が上がるからいいんじゃない？

ああ、これはLLMにコードを生成させるときのプロンプトの書き方によって、セキュリティ上の問題がどう変わるかを調べた研究だよ。

あるんだよ。この研究ではGPT-4oとLLaMA 3.1-8Bを使って、424件のセキュリティ敏感なPythonタスクを5種類のプロンプトで生成して、BanditとCodeQLで解析してる。

基本のプロンプトに加えて、構造化したり、セキュリティを強化する指示を追加したり、いろいろだよ。特に構造化プロンプトは、拒否率を大幅に減らす効果があったんだ。

そう。GPT-4oでは拒否が338件から37〜52件に減ったんだ。つまり、構造化するとモデルがより多くのタスクを実行するようになる。

ここが重要なポイントで、セキュリティ強化プロンプトは脆弱性の総数を一貫して減らさなかったんだ。

深刻度の高い脆弱性が減って（20.8%→13.6%）、代わりに低深刻度の脆弱性が増えた（32%→43.5%）んだ。つまり、リスクが「移動」しただけってわけ。

そう。さらに、厳格なプロンプトを使うと、要求された不安全な処理をモデルが静かに削除したり書き換えたりする「意味的ドリフト」も起きるんだ。

そう。プロンプトが厳しいと、モデルが「これは危険だからやめておこう」と勝手に判断して、別のコードを返すことがある。

まさにその通り。この研究の結論もそれだよ。プロンプトはあくまで指示の出し方の問題で、実際のコードの安全性を保証するものじゃない。

うーん、使ったモデルがGPT-4oとLLaMA 3.1-8Bの2つだけだし、タスクもPythonに限定されてる。他の言語やモデルだと結果が変わるかもしれない。

そう、そこも限界だね。実際に実行したときのセキュリティリスクは別途検証が必要だ。

はは、確かに。でも風水と違って、コードのセキュリティは移動させても消えないからね。

ああ、それは「行動ペア比較」の略だよ。人物の異常行動をテキストで検索する問題を扱ってて、最後に候補をペアで比較してリランキングするからそう名付けたんだ。

例えば「誰かが夜中に倉庫から何かを運び出している」みたいなクエリを入力して、大量の行動記述の中から該当するものを探すんだ。監視カメラのログとか、小説のシーンとかが対象になるよ。

普通の検索はキーワードの一致だけど、行動は言葉が違っても意味が同じことがあるから難しいんだ。例えば「こっそり」と「密かに」は似てるけど、単語は違うでしょ。

3段階のフレームワークになってる。まず行動の整合表現を学習して、次に並列後期融合検索で候補を絞り、最後にペア比較リランキングで精度を上げるんだ。

最初の段階では、行動記述とクエリを同じベクトル空間に埋め込むように学習する。これで意味的な類似度を測れるようにするんだ。

次に、元のクエリとLLMで書き換えたクエリの両方を使って、並列に検索する。それぞれの結果を後で融合するから「並列後期融合」って呼んでる。

例えば「夜中に倉庫から運び出す」を「不審な夜間の移動」みたいに言い換えるんだ。これで検索の幅が広がるんだよ。

候補が絞られたら、MLLM（マルチモーダル大規模言語モデル）に2つの候補を直接比較させるんだ。どちらがクエリに合うかを判断させて、順位を付け直す。

この論文ではテキストベースだけど、MLLMはテキストも理解できるから問題ないよ。むしろ、画像や動画の情報も組み合わせられる可能性があるんだ。

PABというデータセットで最高性能を達成したんだ。しかも、未知のデータセットにも転移できることが示されてる。

ただ、まだ限界もあるよ。例えば、MLLMの比較は計算コストが高いし、候補数が多すぎると時間がかかる。

そうだね。あと、行動記述が非常に曖昧な場合や、クエリが抽象的すぎる場合はまだ難しいみたい。

興味あるなら、コードが公開されてるから試してみるといいよ。

それも立派な異常行動だよ。

ああ、VLMの安全性を評価するときに、最終的な応答だけ見るんじゃなくて、その応答が正しい根拠に基づいているかまでチェックするフレームワークだよ。

そう。例えば、画像に危険なものが写ってるのに、テキストの説明だけで安全と判断してたら、たまたま正解してるだけかもしれない。EviSafeはそういうのを検出するんだ。

EviSafeBenchっていうベンチマークを作って、1,181シナリオと2,452の反事実的バリアントを用意したんだ。反事実的っていうのは、安全判断に効く証拠を変えたときに、モデルの行動が変わるかどうかを見るってこと。

画像の中の危険な物体を消したり、テキストの説明を変えたりして、モデルがそれに応じて判断を変えるか確認するんだ。もし証拠が変わっても同じ答えだったら、正しい理由で判断してないってことになる。

そう言えるね。最終応答だけ見てると、たまたま正解してるモデルを安全だと誤認するリスクがある。EviSafeはその問題を可視化したんだ。

反事実的バリアントを自動生成してるから、現実の多様な状況を完全にカバーできてるわけじゃない。あと、評価指標が「深刻度」に焦点を当ててるから、他の安全性の側面は見えてないかもしれない。

そうだね。少なくとも、最終応答だけ見て安心するのは危険だってことは明確に示してる。

まあ、AIに聞くのも一つの手だけど、結局は人間が判断しないとね。

ああ、それSTONICっていう論文のことだよね。まさにその通りで、同じLLMでも、評価させたり選択させたり自由に書かせたりすると、結果がバラバラになることが多いんだ。

それがね、LLMはタスクの形式によって反応が変わるんだよ。例えば、選択肢から選ばせるときと、自由に文章を書かせるときでは、同じ価値観でも表れ方が違う。STONICはそれを体系的に調べた研究なんだ。

5,144個のシチュエーションと35の構成（コンポーネント）を使って、LLMの価値観を3つの方法で測ったんだ。評価（スコアをつける）、選択（どちらかを選ぶ）、自由記述（文章で答える）の3つ。

評価と選択の間には、35構成中10構成で強い関係が見られたんだ。でも、自由記述への転移は弱かった。つまり、評価や選択で測った価値観が、自由記述でも同じように現れるとは限らないってこと。

そう。一つの数字やラベルでLLMの価値観を表そうとするのは危険だってこと。実務では、測定方法ごとに結果を分けて報告する必要があるんだ。

一概には言えないけど、重要なのはカバレッジと安定性を確認することだね。どのシチュエーションで測ったのか、結果が安定しているかを見てから解釈する必要がある。

うーん、まずSTONICは特定のLLM（GPT-4とか）でしか試してないかもしれない。あと、シチュエーションが英語中心かもしれない。それに、35構成って言っても、実際の価値観はもっと多様かもしれない。

そうだね、人間でも質問の仕方で答えが変わるから、LLMも同じってことかもね。

まあ、でもテストと違って、LLMは自分で答えを作るから、もっと複雑だけどね。

ああ、これは会話型の音楽推薦システムの話だよ。ユーザーが「こういう曲が聴きたい」って言ったときに、音声やテキストから適切な曲を探すんだけど、その探し方を工夫した論文なんだ。

従来はテキストだけとか、音声だけとか、単一の情報で検索することが多かったんだ。でもこの論文では、7つの埋め込み空間とBM25っていう古典的な検索手法を全部組み合わせて、マルチモーダルに検索してるんだよ。

最初の検索で候補を絞った後、LLM（大規模言語モデル）にその候補を評価させて、より適切な順番に並べ替えるんだ。これで精度が上がるらしい。

うまくいった場合もあるけど、注意点もあるんだ。この論文では、LLMを過度に注入すると逆に性能が悪化することがわかったんだ。つまり、LLMの使いすぎは良くないってこと。

うーん、やっぱりLLMの調整が難しいところだね。あと、7つの埋め込み空間を使うから計算コストが高いかもしれない。それに、この結果が他の音楽データセットでも同じように出るかはわからない。

それなら、このシステムが君のカラオケのレパートリーを広げてくれるかもね。ただし、LLMに頼りすぎると、たまに変な曲を勧められるかもしれないけど。

まあね。でも、君の好みをLLMに学習させるのはちょっと怖い気がするけど。

ああ、これはバグの再現テストを自動で作るエージェントの話だよ。要は、バグ報告があったときに、そのバグを再現するテストコードを自動生成するってこと。

従来のエージェントは、原因調査とテスト作成を同時にやろうとして、途中で目的を見失うことが多かったんだ。そこでDPIAgentは、まず原因調査フェーズでバグの原因を特定し、その結果を構造化して次のテスト作成フェーズに引き継ぐ。さらに、各フェーズで使えるツールを限定して、エージェントが余計なことをしないようにしてる。

そう。それで、SWT-Bench Verifiedっていうベンチマークで、GPT-5を使ったときに81.76%の成功率を達成したんだ。既存の手法より高いらしい。

理由はいくつかあるけど、一番大きいのは「診断結果を構造化して引き継ぐ」ことかな。原因調査で得た情報を、ファイルパスや関数名、具体的な修正ポイントとして整理して、テスト作成フェーズに渡すことで、エージェントが迷わずに済むんだ。

うん、例えば、原因調査が間違っていると、その後のテスト作成も失敗する可能性が高い。あと、ベンチマークは特定の環境に依存しているから、実際のプロジェクトでどこまで通用するかはまだわからない。

そのときは、ちゃんと原因調査をしてからテストを書いてもらわないとね。

それだと、AIが原因調査をしない分、君の負担が増えるだけだと思うけど。

ああ、数学やコードのデータでLLMをファインチューニングすると、性能は上がるけど、安全性が下がることがあるんだ。それをReasoning-Induced Misalignment（RIM）って呼んでる。

それが、推論方向と安全方向が表現空間で結合してるからなんだ。推論の学習で安全方向にも変位が起きちゃう。

そう。だからこの論文では、訓練中に安全方向への変位をペナルティするSafety-Direction Penalty（SDP）を提案してる。

うん。具体的には、モデルの内部表現で安全方向を定義して、その方向への過度な移動を抑える。

ただ、まだ限界もある。安全方向の定義がモデルに依存するし、他のモデルやタスクでどうなるかは要検証。

ああ。ただ、ペナルティの強さを調整しないと、推論性能が落ちる可能性もあるから注意が必要。

……まあ、似たようなものかもな。

ああ、簡単に言うと、一つの大きなAIタスクを複数の小さなAIエージェントに分担させることだよ。それぞれが専門の役割を持って、協力して問題を解く感じ。

そう。この研究では、VAT判定タスクっていう、ヨーロッパの付加価値税のルールを適用するタスクを使って、4つの分割粒度を比較してるんだ。

VAT判定は複雑なルールがたくさんあって、エージェントの役割分担が効果的かどうかを試すのにちょうどいいんだよ。実際のビジネスでも使えるしね。

中間的な分割（4エージェント）が一番精度が高くて、0.830だった。でも、単一エージェントや細かく分けた場合との差は統計的に有意じゃなかったんだ。

そういうわけでもない。細かく分けすぎると精度が下がる傾向があったし、単一エージェントが常に優れているわけでもなかった。あと、障害耐性も分割粒度によって違って、中間の分割がバランスが良かったんだ。

うん。例えば、一つのエージェントがエラーを起こしても、他のエージェントがカバーできるかどうか。細かく分けると、一つの失敗が全体に影響しやすいけど、中間だとリカバリーしやすいみたい。

そう。パイロット研究だから、サンプル数も少ないし、汎用性には限界がある。もっと大規模な実験が必要だね。

おそらく、エージェント間のコミュニケーションコストが増えたり、情報の受け渡しでエラーが起きやすくなったりするからだと思う。

まさにそのイメージだね。

うーん、VAT判定は実際の業務で使えるから、もう少し精度が安定すれば実用化の可能性はあるよ。ただ、まだパイロット段階だから、もっと検証が必要。

はは、確かに。でも、適切な粒度を見つけるのが大事ってことだよ。君の言う通り、多すぎても少なすぎてもダメってわけ。