Skip to content

変更履歴

リリースされたもの、そしてそれがリリース判断にとって何を変えるか。

  1. SDK

    Oloproof が PyPI に公開されました

    oloproof 0.1.0a1 が公開されたので、ゴールデンパスはクリーンな環境での pip install oloproof から始まり、そのまま oloproof init と oloproof run に進みます。リリースは CI 上でタグ付きコミットからビルドされ、PyPI の Trusted Publishing によって公開されます。トークンは保存しません。

  2. ワークベンチ

    実行が判断に至った過程をリプレイする

    早期停止した実行や比較は、行ったすべてのルックを記録するようになり、ワークベンチがそれをリプレイします。動かないしきい値に対して、常時有効な区間がルックごとに狭まっていく様子と、各ルールが判断を下したルックです。描くのはエンジンが記録した区間だけです。固定サンプルの区間を、ライブであるかのようにアニメーション表示することはありません。良く見えるまで眺め続けると、その保証が失われるからです。

  3. ワークベンチ

    コマンドパレット、キーボード操作、エビデンスチェーン

    ⌘K または Ctrl+K で、表示できるすべての移動先が一覧され、実行 ID や比較ダイジェストを貼り付けるとそれが開きます。g に続けて文字を押すと移動し、j と k で表の行を移動し、? ですべてのショートカットが一覧されます。ケースは実行の横に開き、そのエビデンスチェーンとラベルを付けた人が表示されます。動きを減らす設定では、すべてのアニメーションが止まります。

  4. ホスト型

    oloproof.com のホスト型ワークベンチ

    ワークベンチは oloproof.com で提供されるようになり、エンドツーエンドのゴールデンパスもそのホスト上で通りました。レビュアーがワークスペースの抽出した 80 件のケースにラベルを付け、ジャッジが合格にしていた誤答を 7 件見つけ、ワークスペースは検証済みサンプルに基づいて合格と判断しました(91.2%、区間 74.5% から 100.0%)。プッシュされた実行だけでは、エビデンスが不十分でした。アクセスは招待制です。

  5. トレース

    OpenTelemetry のトレースを oloproof collect へ

    oloproof collect は標準の OpenTelemetry SDK から OTLP/HTTP を受け取り、GenAI と OpenInference のスパンをコンテンツアドレス方式のトレースにまとめ、その内容をお手元のマシンに保持します。プッシュはエグレスポリシーに従います。oloproof traces promote はトレースを来歴付きのテストケースに変換し、重複は拒否します。

  6. トレース

    本番トラフィックのサンプルに基づく判断

    コレクターは、1 時間ごとに封印したすべてのトレースに対するコミットメントに署名します。ワークスペースは自身の乱数でサンプルを抽出し、抽出した各トレースをコミットメントと照合するため、トレースを出し惜しみしてサンプルを選り好みすることはできません。oloproof traces evaluate は記録済みの出力でサンプルを判定し、ワークスペースはオーナーが固定した評価のもとでそれを判断し、信頼系列がプロジェクトの「本番」ページでサンプルをまたいで各メトリクスを追跡します。

  7. レビュー

    ブラウザで使えるレビューキュー

    オーナーまたは管理者がキューを開いてレビュアーを割り当て、レビュアーはキーボードでラベルを付けます。合格か不合格か、宣言された尺度でのスコア、または 2 つの実行のブラインドでの選好で、いずれもアカウントごとに記録されます。レビュアーのブラウザは、5 分間有効な署名付きチケットで、お客様側の oloproof collect からケースの内容を取得するため、ワークスペースがそれを保持することはありません。

  8. ゲート

    検証済みの実行

    実行には、オーナーが登録したランナーキー、またはマネージドワーカーが署名できます。オーナーは評価全体(スイート、評価器、メトリクス、ベースライン実行)とそのゲートポリシーを固定し、ワークスペースは各システムバージョンについて、まさにその評価を初めて実行したときに、固定された実行と比較して判断します。人手のラベルは独立したラベラーのものだけが、アカウント単位で数えられます。

  9. ジャッジ

    ワークスペースが抽出する人手のサンプル

    PPI 区間は人手ラベルのランダムサンプルでジャッジを補正しますが、その保証には誰も選んでいないサンプルが必要です。ワークスペースは、実行のエビデンスがそこで凍結された後にそのサンプルを抽出し、シードを自分だけで保持し、補正された区間を自らのエンジンで検証するようになりました。実行ページには、ワークスペースが区間を検証したかどうかが示されます。お手元のマシンで抽出したサンプルは、引き続き善意によるものと表示されます。

  10. 評価

    早期停止と、人によって補正されたジャッジの率

    early_stopping: true を指定したポリシーは、シード付きのバッチでケースを実行し、すべてのルールが判断を下した時点で、実行を、または候補とそのベースラインを足並みをそろえて停止し、不要だったケースとともに DECIDED_EARLY として記録します。停止した率には常時有効なベッティング区間を使うため、バッチごとに確認してもその保証は保たれます。ジャッジの合格率は、ジャッジと人手ラベルのブラインドなランダムサンプルを組み合わせた PPI 区間でゲートでき、ジャッジのみの区間、人手のみの区間と並べて表示されます。

  11. メール

    メールによる通知

    4 種類の通知があり、いずれもメンバーがメールから直接オフにできるカテゴリです。マネージドジョブの完了または失敗、ゲートがリリースをブロックしたプッシュ済みの実行または比較、無料枠の 80% と 100% に達した使用量、そしてメンバーの参加です。ゲートのメールは保存された判断を引用して実行にリンクし、ケースの内容は含みません。メールのみで、Slack、ページャー、webhook には対応しません。

  12. アカウント

    パスワードとアカウントの削除

    プロバイダーでのサインインに加えて、メールアドレスとパスワードでもサインインでき、アドレスの確認とリセットにも対応します。本人が自分のアカウントを削除できます。そのユーザーと、そのユーザーだけが所属していたすべてのワークスペースは即座に削除され、ワーカーがそれらのワークスペースのエビデンスを消去します。

  13. ジャッジ

    確率ジャッジ、キャリブレーション、カスケード

    ジャッジは型付きの質問(はいかいいえ、選択肢、レベルに照らしたスコア)に、すべての回答に対する確率付きで答えられます。確率は、ローカルモデルのトークン確率から 1 回のフォワードパスで読み取ります。そのキャリブレーションは人手のラベルに対して測定されてレジストリのエントリーに記録され、カスケードは安価なジャッジが確信を持てないケースだけをより強いジャッジに回します。学習済み分類器も、キーもネットワークもなしで評価器になれます。

  14. ジャッジ

    人手のラベルを基準に問われるジャッジ

    実行のケースにファイルまたはターミナルからラベルを付け、ドラフトのジャッジを採用する前にそのラベルで試せます。ジャッジは一致度と並べてバイアスを報告し、バイアスが宣言されたマージンを超えるジャッジはゲートに使えません。また、測定したモデルが変わると、その検証は数えられなくなります。ラベル不要のプローブは、重要なことが何も変わっていないのに判定が動くかどうかを確かめ、ペアワイズ比較は両方の順序で尋ねるため、位置だけで選ばれた回答は誰もラベルを付けなくても浮かび上がります。

  15. エージェント

    マルチエージェントのエビデンス

    トラジェクトリは、各ステップをどのエージェントが実行したかと、すべての引き継ぎを記録します。評価器はルーティング(リクエストが処理すべきエージェントに届いたか)、ツール権限(自分が呼ぶべきでないツールを呼んだエージェントがいたか)、そしてエージェントが完了せずに制御を行ったり来たりさせていないかを判定し、スライスはケースをルートごとにまとめます。

  16. 評価

    反復測定と不安定件数

    スイートは各ケースを複数回測定できます。反復測定はどの区間よりも先にケースごとに集約され、比較ではそれらを割合としてペアにし、実行は自分自身と食い違ったケースが何件あったかを報告します。システムは失敗を一時的なものとしてマークし、ランナーに再試行させることができます。実稼働の RAG システムでは、これで欠損ケース 22 件のうち 18 件が回復し、区間が 39% 狭まりました。