number_found_accuracy の理解は正しいです。あなたが観察している動作は、レプリケートされたクエリのフェールオーバーと、number_found_accuracy を指定するクエリが継続トークンを使用する将来のクエリに与える影響との間の驚くべき相互作用だと思います。
Search API を使用してドキュメントのインデックスを作成すると、高レプリケーション データストア (つまりMegastore ) と同じメカニズムを使用して、複数の異なるレプリカにドキュメントが保存されます。これらのドキュメントが各レプリカでライブになるまでの時間は、多くの要因によって異なります。通常は即時ですが、単一の (インデックス、名前空間) ペアにバッチ書き込みを行う場合、遅延はさらに長くなる可能性があります。
検索は、これらのレプリカのいずれかで実行できます。元の検索とは異なるレプリカで継続トークンを使用する検索を実行する可能性さえあります。元のレプリカや継続レプリカがインデックス作成作業に追いついている場合、ライブ ドキュメントのセットが異なる可能性があります。「最終的には」一貫性が保たれますが、常に即時であるとは限りません。
クエリで number_found_accuracy を指定すると、number_found_accuracy の結果を返すかのように、ほとんどのクエリを実行する必要があります。特に、一致するドキュメントを見つけてカウントするには、投稿リストのさらに下を読む必要があります。投稿リストを読み取ると、関連するファイル ブロックがさまざまなキャッシュに挿入されます。
次に、カーソルを使用して検索を行うと、元の検索に使用したのと同じレプリカで、実際のドキュメントをはるかに迅速に読み取ることができます。したがって、同じドキュメント セットのインデックス作成が完了していない別のレプリカに継続検索がフェールオーバーする可能性は低くなります。あなたが観察した一貫性のない結果は、この種の継続クエリのフェイルオーバーの結果だと思います。
要約すると、 number_found_accuracy を大きな値に設定すると、そのレプリカのキャッシュが効果的にプレウォーミングされます。したがって、継続検索の最速のレプリカになることはほぼ確実です。インデックス作成に追いつこうとしているレプリカに直面すると、number_found_accuracy が結果の一貫性に直接影響するように見えますが、実際には単なる副作用です。