← 2026-10-11 の一覧へ戻るホーム
独自の意思決定モデルを構築する

2026/10/11 7:50

独自の意思決定モデルを構築する

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

本研究の核心となる洞察は、言語モデルは単一パスの意思決定システムを模倣することは可能であるが、特定のカリブレーションが行われる限りでは、しばしば危険な過剰な自信を示すという点にある。標準的なモデルが複数のパスを通じて順次テキストを生成するのに対し、システムワンアプローチは制約付きデコーディング（例えば、選択肢 A〜E の語彙をマスキングする）を用いて、AI に固定されたオプションを 1 パスで選択させる。この手法は推論速度を向上させるが、信頼スコアの膨張というリスクをもたらす；具体的には、ネイティブ出力トークンの確率は次のトークンに対する自信を反映しており、正しい答えの真なる確率を反映していない。CommonsenseQA の保持サンプルでの評価では、ファインチューニングの後であっても未カリーブレーテッドなモデルは、明確な単一の答えが存在しない困難な Commonsense 問題に対して高い不確かさ（例：99.78%）を割り当てることができ、マクロ F1 精度は約 58％に留まり、高自信ビンに至っては単なる 70％に過ぎなかった。本研究では、LLM 模倣（Qwen/Qwen3-1.7B）における温度スケイリングを用いてこの問題を成功裏に解決し、モデルの報告された自信を実際の性能と数学的に整合させ、結果として適合温度が約 3.8 となった。したがって、制約付きデコーディングは標準化テストのような多選択タスクに対して効率的を提供するものの、その後のカリブレーションなしで展開することは、過剰な自信による誤りを招き、ユーザーを欺くことになる。今後、事前に定義された答えへの厳格な遵守が求められる適用においては、信頼性指標が真に信頼性を反映するように、事後処理ステップ（例えば温度スケイリング）の優先を確保する必要がある。

本文

「System One」決断モデルの実装と較正：Qwen3-1.7B を用いた検証

概要

System One（システム・ワン）とは、較正された確率値あるいは許容される全ての選択肢を出力するよう設計された決定型モデルのことです。

なぜ必要か？

日常的な言語モデルから JSON 形式の構造化された出力を得る場合、単なるプロンプトでは不十分であり、Structured Output を用いて有効な出力を強制する必要があります。

  • モデルは入力に対して 1 つのパス（prefill）で埋めるが、有効な応答生成には各トークンごとにパスを実行する必要があるため、通常の生成では最終出力まで多くのパスを要します（例：11 パス）。
  • これに対し、決断モデルは固定された選択肢から単一パスで選べることを前提としています。

実装手法：出力制限による挙動の模倣

LLM を用いて出力トークンのセットを制限することで、System One の振る舞いを模倣できます。ここでは Qwen/Qwen3-1.7B を使用して実装と検証を行います。

コードスニペット

以下の Python スクリプトにより、選択肢のみから推論を行い、確率分布を取得します。

import argparse
import json

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "Qwen/Qwen3-1.7B"
options = ["A", "B", "C", "D", "E"]

parser = argparse.ArgumentParser()
parser.add_argument("--input", default="question.json")
args = parser.parse_args()

# トークナイザーとモデルを読み込む
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype="auto",
    device_map="auto"
)

# モデルが各選択肢に対して最初に発音するトークン ID
option_token_ids = [tokenizer.encode(opt, add_special_tokens=False)[0] for opt in options]


def format_prompt(item):
    prompt = item["question"] + "\n"
    for opt in options:
        prompt += f"{opt}. {item[opt]}\n"
    prompt += "Answer:"
    messages = [
        {"role": "user", "content": prompt}
    ]
    return tokenizer.apply_chat_template(
        messages,
        tokenize=False,
        add_generation_prompt=True,
        enable_thinking=False
    )


with open(args.input) as f:
    item = json.load(f)

model_inputs = tokenizer(format_prompt(item), return_tensors="pt").to(model.device)
with torch.no_grad():
    logits = model(**model_inputs).logits[0, -1]
# 制約付きデコード：選択肢のトークンのみが許可される
probs = torch.softmax(logits[option_token_ids].float(), dim=-1)

print(f"予測結果: {options[probs.argmax().item()]}")
for opt, prob in zip(options, probs.tolist()):
    print(f"{opt}: {prob:.4f}  {item[opt]}")

テスト実行例（単純な質問）

入力データ:

{
    "question": "空の色は何ですか？",
    "A": "赤色",
    "B": "青色",
    "C": "緑色",
    "D": "紫色",
    "E": "知りません"
}

出力結果:

  • 予測結果: B（青色）
  • 確率分布:
    • A: 0.0000, B: 0.9988, C: 0.0000, D: 0.0000, E: 0.0012

モデルは入力を正しく理解し、正解に対応する予測を行えています。

精度評価：公開データセットによるテスト

CommonsenseQA のランダムなサンプルホールドアウトに対し、未学習のモデルを実行した結果です。

1. ファインチューニング前の結果（ベースライン）

適合率 (precision)再現率 (recall)F1 スコアサポート数
A0.57330.71970.6382239
B0.55060.76860.6416255
C0.53720.65980.5922241
D0.72060.39040.5065251
E0.75190.42550.5435235
  • 全体精度: $725/1221 \approx 0.5938$
  • マクロ F1 スコア: 0.5844

2. ファインチューニング後の結果

データセットに対する簡易なファインチューニングを行うことで性能が向上しました。

適合率 (precision)再現率 (recall)F1 スコアサポート数
A0.64750.66110.6542239
B0.61130.67840.6431255
C0.62340.59750.6102241
D0.67000.54180.5991251
E0.58080.64260.6101235
  • 全体精度: $762/1221 \approx 0.6241$
  • マクロ F1 スコア: 0.6234

モデルの較正（Calibration）検証

モデルの出力スコアが実際の精度を反映しているか確認する必要があります。曖昧な問題に対するテストで、過信傾向が浮き彫りになります。

テスト例：極めて曖昧な質問

入力: 「コウモリを見かける可能性が最も高い場所はどこですか？」（選択肢：鍾乳洞、野球ゲーム中、屋根裏部屋、動物園、スポーツ用品店）

  • 出力結果: A（鍾乳洞）で確率 0.9978 を獲得。
  • 問題点: 明確な正解が存在するはずのない問題に対して、モデルが極端に高確率を割り当てていることが示されています。これは出力確率を「信頼スコア」として扱う際の誤りです（追加学習なしでは自信度＝真の確率は保証されません）。

未較正状態のデータ分布

信頼スコアのビン区間ごとの精度を見てみると、自信度と精度が一致していないことがわかります。モデルは一般的に過信しています。

ビン区間件数自信度 (確率)精度
(0.00, 0.10]00.00000.0000
(0.10, 0.20]00.00000.0000
(0.20, 0.30]30.28340.0000
(0.30, 0.40]260.37610.2692
(0.40, 0.50]410.45380.2683
(0.50, 0.60]700.54900.3286
(0.60, 0.70]740.64760.3649
(0.70, 0.80]770.74950.4286
(0.80, 0.90]1210.85550.4711
(0.90, 1.00]8090.98550.7009
  • 課題: 自信度 0.9〜1.0 の予測でも正解率はわずか 70% です。
  • 過信の例: 0.8〜0.9 の自信度でも精度は約 40% にとどまります。

較正手法：温度スケールリングと曲線適合

モデルの出力スコアが精度を反映するようにするため、以下の手法を用いて較正を行います。

1. 温度スケールリング（Temperature Scaling）

温度値を変更することで、出力確率分布を平坦化し、実際の精度に近似させることができます。

2. 曲線適合による最適温度の探索

モデルの精度に合わせて温度パラメータをフィットさせました。

  • 発見された温度: 3.797280788421631

これにより、はるかに良い較正が得られました。調整後のデータ分布は以下のようになります。

ビン区間件数自信度 (確率)精度
(0.00, 0.10]00.00000.0000
(0.10, 0.20]00.00000.0000
(0.20, 0.30]820.27120.2317
(0.30, 0.40]2170.35070.3917
(0.40, 0.50]1990.44720.5126
(0.50, 0.60]1660.54750.5482
(0.60, 0.70]1390.65620.5827
(0.70, 0.80]1400.74920.7714
(0.80, 0.90]1690.85070.7988
(0.90, 1.00]1090.93330.9541
  • 効果: 高自信度（0.9 以上）の予測でも精度は 95% 以上 に向上しており、モデルの過信傾向が大幅に改善されました。

次のステップ

より詳細な検証やデータセットの構築、評価、ファインチューニング、そしてモデル自体の較正を行うスクリプトは GitHub リポジトリにて公開しています。より大規模なモデルでも同様のアプローチを試してみることを強くお勧めします。

同じ日のほかのニュース

一覧に戻る →

2026/10/07 21:30

2D 車両

## Japanese Translation: 「Motion Lab」は、1996 年に GFA BASIC で書かれた先駆的な物理エンジンが GTA の車体システムを動力源としていたのを記念し、同エンジンの 30 周年を祝うためのモダンな Web ベースの再現作品です。当時の一般的なシンプルな「ポインタ・フィジックス」と異なり、この JavaScript インプリメンテーションは、リアルなトルクおよび力の相互作用を含む高度な古典的な 2 次元剛体動力学を正確にシミュレートします。本プロジェクトは、教育的目的のためにレガシースタイルを維持しつつ、オリジナルのソフトウェアが後に摩擦に関する推測に基づいた近似的かつ技術的に不正確な車体シミュレーション層を追加したことを認める一方で、「リマスター」された、より美しいバージョンの元のワイヤフレーム美学を提供しています。ユーザーは「Car（カー）」「Spaceship（スペースシップ／通称：Ship）」「Brick（ブリック）」という 3 つの異なるモードを体験でき、これらのモードは歴史的に「Brick モデル」から始まり、「Ship 要素」を含むよう進化し、最終的に「Car 要素」を取り入れた経緯を持っています。体験には、重力やバリアーの有効/無効化に加え、キーボードまたはタッチ入力により制御される GTA スタイルのカメラズームが含まれています。重要なのは、この非公式なプロジェクトが Rockstar Games および Take-Two から独立しており、オフィシャル製品ではなくトリビュートであることです。2026 年の発表を予定している本再現作品は、ユーザーが外部プラグインに依存せず、数十年にわたる技術開発を直接体験することを呼びかけています。

2026/10/11 5:31

あなたは存在したくても、街自体がそれを好まない街建設ゲーム

## Japanese Translation: サンフランシスコ当局は、特定の住宅シミュレーターに関する自由裁量審査を正式に開始し、都市の規制環境におけるその影響を検討するための重要な手続き的段階を示しています。この措置は、政府機関が該ツールを積極的に調査していることを示しており、同時に具体的な欠陥や直ちに懸念すべき事項がまだ特定されていないことも指摘しています。当面の次の段階では、審査プロセスを継続してシミュレーターの法的地位および運用可能性を決定することとなり、これが将来的にサンフランシスコにおける同様の住宅シミュレーターの開発と規制方法に影響を与える可能性があります。

2026/10/09 16:29

ニックスが私のデバッガーの半分を書いた

## Japanese Translation: Rewind VM は、Nix ビルドをその入力（スレッドスケジューリングを含む）の純粋な関数として扱い、ローカルストアおよびバイナリキャッシュに対してハッシュベースのチェックによる正確な再現性を検証することで、仮想マシンデバッグを決定論的に行います。このシステムは、ハッシュ付きクロージャーを含む読み取り専用 erofs イメージ上で起動します。ビルド ID は cache.nixos.org または `debuginfod` を介してデバッグ情報（Linux カーネルソースを含む）を取得するために使用されます。分析を支援するために、Rewind はソースパネル、スタックフレーム、`.rwd` エクスポートファイルに保存されたブックマーク、「Compare」タブで並置表示され最初に異なるイベントをハイライトするトレース比較機能、ゲストカーネルが各ステップで CPU 所有権を報告できるようにして実行を正確に再プレイするためのツールを提供します。`rewind gdb` を使用すると、すべてのスレッドを維持したまま VM の任意のステップでフォークできます。「Compare」タブと `rewind compare` は別々の実行間の差異を表に出し、`rewind check --run` は複数のスケジューリング下で任意のステップから実行をフォークして競合条件のインターリーブ可能性を評価します。この無料のデバッグインフラストラクチャ（入力、シンボル、ソース、決定論的分析機能）を提供することで、Rewind は高価な独占ツールなしで並行性问题への調査の障壁を下げてソフトウェアの信頼性を向上させます。