R&D

R&D最新情報

何を検証し、どう測定し、何を結論としたか。後退を招いた結果も含めて公開しています。

12件のノート

2026/09/04評価Specter撤回

自らは検証していない較正結果を引き継いだ確信度シグナル

本番環境では算出できない別のシグナルに対する較正結果を根拠として、新しい確信度判定を投入していた。再測定の結果、これを撤回した。

較正に用いたシグナルは正解データを必要とするが、本番環境にそれは存在しない。実装では較正されていない代理指標に置き換えられ、しかもプルリクエスト・コミットメッセージ・docstringのいずれもが、元の数値を根拠として引用していた。
全設問データセットで再測定したところ、投入された代理指標が保っていた識別力は、較正済みシグナルのおよそ3分の1にとどまった。大半のターンを「確信度が低い」と判定する一方、そのうちの多くは実際には正解を含んでいた。閾値を掃引しても、採点に用いたデータへの過適合でない改善は見つからなかった。
従来の値へ差し戻したうえで、候補実装と測定用ハーネスはコードベースに残した。再挑戦する際は、投入後ではなく投入前に設計と測定を行う。
根拠は、それを無効にするはずの置き換えを生き延びることがある。数値だけが文章に残り、それが測定した対象は静かに差し替えられるからである。

2026/09/01評価共通基盤導入済み

費用を投じる前にベンチマークを検証する

実行不能と判定できるベンチマークを事前に拒否するプラン用エンドポイント、実際に実行されたモデル名を明示する試験群、そして実行プロセスの終了後も結果が残る保存基盤を導入した。

計画段階で、費用が発生する前にベンチマークを検証する。実際に、実行不能な評価を4件承認していた計画をこの仕組みが検出した。
対照ハーネス自体も検証の対象とする。同一条件の2つの試験群は差分ゼロを報告しなければならない。差分が出た場合、それは発見ではなくハーネスの欠陥である。
各試験群は、実行したモデル名を明示する。当然のようでいて以前は成立しておらず、ある調査では「測定値」と称されていた数値が測定でなかった原因を3つ特定した。
結果はサーバー上のファイルではなく専用ストアに保存する。ジョブが現在使用しているモデルに限らず、カタログ内の任意のモデルをベンチマークでき、モデル間のスコアを1画面で比較できる。

2026/08/19評価Specter導入済み

事前登録された同一性に紐づく判定型評価

構造生成のゴールデン評価と、判定者を用いたレポート評価。費用が発生する各フェーズは、それを生成したプロンプトとコードに厳密に紐づけられる。

生成された分析構造に対するゴールデン評価ハーネスを構築した。各生成の来歴は推測ではなく明示的に記録する。
第2階層のレポート評価は、文脈を分離した実行と明示的な判定プロトコルの下で行う。判定者が採点対象の資料によって誘導されることはない。
費用が発生する評価フェーズはすべて、事前登録されたプロンプトとコードの同一性に紐づける。何が生成したのかを厳密に追跡できない結果は、行動の根拠にならない。
判定者自身の較正も実行と併せて記録する。系統的な欠陥が見つかった場合は、平均に埋もれさせるのではなくキャンペーンを中止する。

2026/08/18モデル共通基盤導入済み

単一のディスパッチャ、宣言型の能力定義、そして正直な拒否

すべてのモデル呼び出しをタスクとして命名し、バインディング経由で解決する。モデルの対応可否は事前に宣言され、エンジンは実行中に判明させるのではなく、対応できない要求を事前に拒否する。

タスクレジストリがシステム内のすべてのLLM機能を命名する。呼び出し側はモデルではなくタスクを指定する。バインディングがタスクとエンドポイントを対応づけ、呼び出しごとに参照される。
プロバイダー（Anthropic、Gemini、Bedrock、OpenRouterなど）は単一の接続層の背後に置く。すべてのアダプターは画像を黙って破棄せず、確実に描画する。
バインディングごとのパラメータは型付けされ、未知のキーは拒否する。タイムアウト、出力上限、温度、専用の並列度レーンを個別に設定できる。
提供中のモデルは、提供終了を顧客が発見する前に自動で検査する。初期の検査実装は能力を測定せずに仮定しており、それ自体が一つの発見であった。現在は根拠に基づく場合にのみ判定を絞り込む。

2026/08/14検索Specter進行中

明示的なコンテキスト予算と、上限到達時の抽象化

根拠を黙って切り捨てるレポートは、収まらなかったものを明示するレポートより悪い。そこで予算を明示的に扱い、収まらない内容は破棄せず抽象化する方式へ変更した。

組み立て処理全体で場当たり的に行われていた切り詰めを、共通の予算パッカーに置き換えた。ファイル親和性によるバケット化と、量子化した重要度の階層化により、全文を割り当てる対象を決定する。
予算内で網羅性を満たせない場合、抽象化ステージが収まらなかった要素をスキーマ準拠の要約として生成する。参照ごとの位置情報を保持するため、引用は実在する箇所を指し続ける。
抽象化結果は検証済みの構成メンバーに紐づけてキャッシュする。破損したキャッシュはデータとしてではなく、キャッシュミスとして扱う。
再計画はラウンド番号付きの状態機械として動作し、階層ごとの状態は単調に進行する。これによりカバレッジの波は振動せず収束する。実行ごとの予算テレメトリが、収まったものと収まらなかったものを記録する。
この機能は現時点で既定では無効である。パッカーと抽象化ステージはいずれもフラグの背後にあり、置き換え対象の既存経路と比較測定が済むまで有効化しない。テレメトリを設けた目的は、切り替えの前にその比較を可能にすることにある。

2026/07/29評価Specter導入済み

バリュエーションエンジンのゴールデンケース

自信をもって誤る財務モデルは、モデルがない状態より悪い。第1階層のゴールデンケースと第2階層の抽出評価により、正解が既知のケースにエンジンを固定する。

第1階層のゴールデンケースハーネスは、人手で検証したケースに対してコアエンジンとそのアダプターを検証する。
第2階層の抽出評価は中間時点のゴールドセットに対して実行し、抽出の失敗とモデリングの失敗を切り分ける。
言語に関する仕様は独自の評価で担保する。途中で切れた生成結果は表示せず拒否し、生成された文章は英語だけでなく対応するすべての言語で検証する。
診断情報は数値を断定するのではなく評価額の符号を説明する。また、前提が変化した予測にはステイルネス指紋を付与して明示する。

2026/07/16システム共通基盤進行中

OCRの費用を一度だけ支払う

コンテンツハッシュが既知のファイルは、再度読み取らずにビジョン処理の後段からパイプラインへ合流する。

データルームには同一の文書が別名で重複して存在することが多く、従来はその複製ごとに最初から読み取っていた。
コンテンツハッシュのキャッシュにより、一致した場合はビジョン処理を完全に省略し、プロジェクト固有の処理である根拠構築の段階から合流する。
キーはファイル名ではなく内容である。名前を変更した複製や再出力された複製も、同一文書として認識される。
この機能は既定では無効であり、フラグの背後で動作する。誤った文書を返すキャッシュは二重にコストを払うことより悪い。同一性判定を本番規模で検証し終えるまで、ゲートは維持する。

2026/07/10検索共通基盤導入済み

行単位の埋め込みチャネルの撤去

すべてのテーブル行を埋め込んでおり、それはシステム内で最大の構造だった。前後比較の対照実験は、検索にそれが不要であることを示した。よって撤去した。

手法：同一のゴールデンセットに対する前後比較を、3つの設問階層で実施した。SQLで決定的に生成した正確値の設問、モデル生成による意味的設問、そしてテーブル系チャネルの変更が影響してはならない文書対照階層である。対照階層が動いた場合、壊れているのはシステムではなく測定である。
判断基準は再ランキング後の値とする。それが実際にユーザーが目にする順序だからである。第1段階の候補も報告するが、結論には用いない。
制限時間内に完了しなかったクエリは、失敗として採点せず前後の双方から除外し、除外はすべて報告した。時間はサンプル数を制約してよいが、スコアを制約してはならない。
決定的な階層は4回実行した。設問セットを更新すると1桁台の変動が生じるため、1回の測定は結果とは呼べない。
結果：顧客規模のライブラリでは、3階層すべてにおいて再ランキング後の検索性能は中立であった。対照階層は変動せず、測定の妥当性を裏づけた。正確値の参照は、保持したセルに対するSQLで解決する。インデックス容量とクエリ遅延はいずれも減少した。

2026/07/07検索共通基盤導入済み

推測ではなく測定に基づく検索処理の実像

6つのチャネルを等重みでランク融合し、クロスエンコーダで再採点したうえで予算内にレンダリングする。実装に照らして記述し直したことで、誤って説明されていた箇所が明らかになった。

キーワード検索と密ベクトル検索のチャネルを、根拠・テーブル・行の各単位で並列に実行する。相互ランク融合（RRF）が等重みでこれらを統合する。生スコアは破棄しランクのみを用いるため、特定チャネルのスケールが全体を支配することはない。
続いてクロスエンコーダが統合済み候補を再採点する。テーブルについてはメタデータ信号と一致行を併せて採点し、最良値を採用する。したがって、どの行が一致したかが、再ランカーおよび最終的にモデルが目にする内容を決定する。
日本語のキーワード検索は、社内ドキュメント上「機能していない」と記述されていた。実データに対して実行したところ、部分的に機能しており、特定語に偏っていることが判明した。ライブラリごとに文書頻度の高い語のストップリストを適用して精緻化し、正確性は測定可能な形で改善した。
リファレンス内の各主張には、実行時に測定したものか、コードから推論したものかを明示し、両者を混在させない。コードと記述が食い違う場合はコードを正とし、記述を修正する。

2026/07/06ドキュメントAINebula導入済み

レイアウト認識によるクロップと、領域種別に応じたルーティング

ページは単一の対象ではない。領域に分割し、各領域を切り出し、その領域に応じた指示で読み取る方式は、ページ全体に単一のプロンプトを適用する方式を上回る。

レイアウト検出によりページを領域に分割し、各領域を切り出したうえで、中央ストアから解決した領域別の指示で読み取る。運用者はデプロイなしに、領域種別ごとの読み取り方を変更できる。
手書き領域は、ページの他の部分を処理しているモデルに委ねるのではなく、それを最も正確に読めるモデルへ振り分ける。
OCRの前に向きを補正し、正しい向きにしてから読み取る。主モデルが失敗した場合はバックアップモデルへ切り替える。横向きに取り込まれたスキャン文書は、精度の問題ではなく、防止可能な種類の誤りである。
スループットは、モデル別の上限を持つ分散レートガバナー、バッチ単位のサブPDF、レンダリングとOCRのパイプライン化によって確保した。プロバイダーの制限に抵触せず高い密度を維持する。

2026/06/19モデルNebula導入済み

日本語ファインチューニングと、比較のための切り替え機構

フロンティアモデルは日本語のビジネス文書を十分に読める。しかし、日本語IR資料のレイアウトについては、それを学習したモデルには及ばない。そこで自ら学習させ、ベースエンジンをコマンド一つで呼び戻せる状態に保った。

オープンウェイトのビジョン言語モデルを、日本語のIR資料・財務資料でLoRAファインチューニングした。専用GPU環境で提供するため、スループットが外部の待ち行列に左右されない。
コマンド一つでベースモデルとファインチューニング版を切り替えられる。これがなければ比較は主張にとどまるが、あれば両者をまったく同一の入力で実行できる。
ページ単位のタイムアウトは設定可能である。情報密度の高い1ページがバッチ全体を占有することはない。平均ではなく最悪ケースに対する上限である。
ファインチューニング版はフロンティアモデルを置き換えるものではなく、併存させる。ルーティングは文書ごとに選択し、ファインチューニングの対象外であるページ種別には、利用可能な最良の汎用モデルを適用する。

行選択の失敗を検出できないベンチマーク