マイルストーン
2026-09-11 までこのサイトが掲げていた KR1 基準のステップ一覧。記録として残すもの。
英語版が原文です。
indx は文書を読む費用を払う前に、どう読むかを決めます。そのうえで文書をテキスト、メタデータ、チャンク、埋め込みに変換し、利用者が管理するインデックスへ渡します。このページは 2026-09-11 までサイトが掲げていたステップ一覧を、記録として残したものです。作る順に並んだ 8 つの成果が、それぞれ動かす KR1 の目標を名指しします。現在のロードマップは代わりにプロダクトの青写真を基準に読みます。KR1 の 4 つの目標は暫定的なもので、設定した本人のレビューを受けていません。合意されたゴールではなく、ベンチマークが算出する数値として読んでください。各ステップは 1 つの成果です。開くと、何が可能になるか、KR1 のどの目標を動かすか、その前に何が必要かが読めます。どれも動かさないステップは、そう明記します。この順序の技術的な理由は実装順のページにあり、各ステップは機能一覧の該当項目にリンクしています。破線の 計画中 バッジは、まだ作られていないステップを示します。10 月 1 日に向けた週ごとの作業はスプリントのページで追います。
KR1 — 技術で勝つ
Section titled “KR1 — 技術で勝つ”この作業が貢献する会社の目標です。KR1 は 4 つの目標からなり、以下の各ステップは動かす目標をこの ID で名指しします。
| ID | 目標 |
|---|---|
| KR1.1 | 優先 10 データ形式でのルーティング精度 90% 以上 |
| KR1.2 | 標準的な文書の 70% 以上を CPU だけで処理 |
| KR1.3 | 固定パイプラインに対して推論費用を 40% 以上削減 |
| KR1.4 | 似た帳票を 1 日未満で立ち上げ |
1. 文書が CPU 上で計画・読み取りされ、その計画を確認できる。対応は 11 種類のファイル形式
できること。 PDF、画像、スキャン、スプレッドシート、Word や PowerPoint、テキストや CSV、メールを送ると、高価な処理が走る前に、どのページをどのリーダーが読むか、その理由、想定費用を示す計画が返ります。計画を実行すると、位置つきのテキスト・ページ・チャンクのブロック、文書メタデータ、検出された言語、任意の分類、埋め込みが得られます。請求書と認識された文書は専用パーサーへ送られ、汎用経路はその後ろに残ります。
KR1 の目標。 4 つすべてが測られる土台です。ベンチマークはすでに実文書に対して KR1.1 と KR1.2 を算出しています。KR1.3 はまだ見積もりで、KR1.4 はまだ存在しません。
前に必要なもの。 なし。現在提供されているものです。
2. 誰でもこのサイト上のページに文書を置き、計画・読み取り・検索される様子を見られる
できること。 サイト上のサンドボックスページが、サンプルまたはアップロードした文書を受け取り、計画を表示し、次に各ページとその上のチャンクを実際の位置に描き、それらを横断して検索できます。実際のサービスに対して動くので、顧客との打ち合わせで見せるものが製品そのものです。
KR1 の目標。 なし。見込み客に製品を見せるためのステップで、indx が読めるものも費用も変わりません。
前に必要なもの。 ステップ 1。
3. 品質が、表からの見積もりではなく、ラベル付き文書に対して実測される 計画中
できること。 ベンチマーク文書の小さな部分集合に、正しい読み取りが出すべきテキストと項目を持たせ、「どれだけ正しく読めたか」を計測値にします。その数値が、無料の Office リーダーで十分か、重いモデルが費用に見合うか、2 つの抽出器のどちらが良いかを決めます。まだ採点されていない 6 種類の読み取り可能な形式も採点され、対応範囲が主張ではなく集計になります。
KR1 の目標。 KR1.1（全優先形式の採点が必要）と KR1.3（信頼できるものになるには実測の品質側が必要）。
前に必要なもの。 ステップ 1 と、未採点の形式の公開文書。後者は現在調達中です。
4. すべての結果が、各部分を生成したコンポーネントを名指しする
できること。 結果が、どのローダーが文書を取得し、どの観測器が検査し、どのリーダーが各ページを読み、どのチャンカーが切り、どの分類器がラベルを付けたかを述べます。これが回答を監査可能にし、後で呼び出し側が特定のコンポーネントを名前で指定できるようにします。
現在地。 両側とも出荷済みです。計画はそれを生み出したローダー、sniffer、観測器を名指しし、エンコードのトレースはそれらに加えてチャンカー、言語検出器、分類器、固有表現抽出器を、それぞれを提供したディストリビューション名で名指しします。
KR1 の目標。 直接はなし。ステップ 5 から 8 が依存する基盤の作業です。
前に必要なもの。 ステップ 1。
5. ページとチャンクが分類され、人名・日付・金額が日本語と英語で抽出される 計画中
できること。 現在は文書全体にラベルを付けられます。このステップの後は各ページと各チャンクにも付けられ、人物、組織、場所、日付、金額が見つかり、元のテキストのどこかが指し示されます。費用の異なる 4 つの抽出エンジンが使え、ステップ 3 の実測セットがどれを使うべきかを示します。
現在地。 契約リリースは完了し、抽出は 4 つのエンジンすべてとともに出荷済みで、出荷済みの 3 つの分類器は文書ごとに加えてページごと・チャンクごとにも答え、すべてプレイグラウンドで見られます。測定もあります。ラベル付きセットは 6 つのスコープに固有表現のラベルを持ち、ベンチマークが各エンジンを単独でそれに対して採点します。帳票からなるこのコーパスではホストされたモデルが最も多く読み、費用のかかる唯一のエンジンです。次が無料のパターンエンジン、その次が ONNX モデル、辞書レーンが最も少なく、その大半は表現できない粒度によるものです。残るのは幅です。30 個は信頼する数ではなく、広げるべき数です。
KR1 の目標。 直接はなし。indx が文書から返すものを広げるステップで、その出力がどれだけ正しいかは、ステップ 3 のラベル付きセットで測ります。
前に必要なもの。 ステップ 3 と 4。このステップは保留中のワイヤー契約の変更をすべて 1 回のリリースにまとめるので、連携先はクライアントを 1 回だけ再生成すれば済みます。
6. フォルダやバケット全体が CPU 上で処理され、進捗・費用・失敗が報告される 計画中
できること。 indx にフォルダ、S3 プレフィックス、Google Cloud や Azure のコンテナを指すと、その中のすべてを処理し、進捗を報告し、失敗した文書を切り分け、CPU のみの割合と 1,000 文書あたりの費用を述べます。「CPU でのコーパス分類」という主張の裏付けになるコーパス規模の処理です。
KR1 の目標。 KR1.2 と KR1.3。どちらもコーパス規模で初めて実体を持ち、1,000 文書あたりで報告されます。
前に必要なもの。 実行を採点するハーネスとしてステップ 3、失敗した文書が何で失敗したかを名指しできるようステップ 4。
7. チャンクが文と段落に沿い、呼び出し側が大きさを選べる 計画中
できること。 現在 PDF は行単位で切られるので、折り返した 1 文が 2 チャンクになります。このステップの後はチャンクが文と段落に沿い、ページ上の位置も保たれ、呼び出し側は粗い・細かいチャンクを頼め、デプロイはどのチャンカーを使うか名指しできます。どの境界が検索に良いかは、ステップ 3 の実測セットが決めます。
KR1 の目標。 なし。利点は indx の出力に対する検索結果の質で、ステップ 3 に対して計測されます。
前に必要なもの。 ステップ 3 と 5。テキストを書き換えるチャンカーが、エンティティ抽出がすでに指している位置を動かしてはならないからです。
8. 出力が利用者管理のインデックスへエクスポートされ、似た新形式が数例から設定できる 計画中
できること。 処理済みコンテンツが、利用者所有のベクトルインデックスへ書き込まれ、埋め込み空間とクエリエンコーダーが名指しされるので、エージェントが検索できます。レシピ — 数個の例とスキーマ — が認識済み形式ごとに保存され、既知の形式に似た新しい文書タイプは、新しいパイプラインを組むのではなく数日で設定できます。認証、レート制限、メトリクスもここで加わります。サービスが状態を持ち始めるのがこの地点だからです。
KR1 の目標。 KR1.4。レシピはそのためのもので、ベンチマークは現在これを未実装として報告しています。エクスポートはどれも動かしません。
前に必要なもの。 ステップ 6。どちらも、コーパス実行が実測ベースラインを出してから決めるものだからです。