Question 1

/O2 を使用した整数乗算ループで発生する MSVC ARM64 C1001 内部コンパイラエラーの修正方法

Accepted Answer

これは、Windows 11 ARM64 上の MSVC 19.51（ツールセット 14.51.36231）におけるオプティマイザのリグレッションです。/O2 /Ob2 を指定した環境で、定数で埋められたベクターを使用する呼び出し元に static_cast<int>(codes[i]) * codes[i] を含むループがインライン化されると、発生する可能性があります。

64 ビットの乗算を強制することで回避できます：

sum_squared += static_cast<int64_t>(codes[i]) * codes[i];

元の 8 ビット値では 32 ビットの積がオーバーフローしないため、結果は維持されます。その他の回避策としては、ループの前に #pragma loop(no_vector) を追加するか、ループを複数のステートメントに分割する方法があります。この問題は MSVC 19.44 では再現しません。

Question 2

MSVCでWindows ARM64向けにzvecをビルドする際に発生するCMakeエラー "Target zvec_ailego is required by zvec_ailego_shared" を修正する方法は？

Accepted Answer

これは zvec 0.5.1 で発生します。`src/ailego/CMakeLists.txt` が ARM64 上の MSVC に対して、`zvec_ailego` ターゲットを作成する前に `return()` を呼び出す一方、`BUILD_ZVEC_AILEGO_SHARED` が有効なままになっているためです。この問題は PR #352 で修正され、`main` にマージされています。

推奨される修正方法: zvec の依存関係を最新の `main` または PR #352 を含むリリースに更新してから、再構成してください。

```bat
rmdir /s /q build
cmake -B build -G Ninja ^
  -DCMAKE_SYSTEM_NAME=Windows ^
  -DCMAKE_SYSTEM_PROCESSOR=ARM64 ^
  -DBUILD_C_BINDINGS=ON ^
  -DBUILD_ZVEC_AILEGO_SHARED=ON
cmake --build build
```

zvec 0.5.1 を使い続ける必要があり、オールインワンの ailego 共有ライブラリが不要な場合は、これを無効にしてください。

```bat
cmake -B build -G Ninja ^
  -DCMAKE_SYSTEM_NAME=Windows ^
  -DCMAKE_SYSTEM_PROCESSOR=ARM64 ^
  -DBUILD_C_BINDINGS=ON ^
  -DBUILD_ZVEC_AILEGO_SHARED=OFF
```

あるいは、PR #352 をバックポートするか、`src/ailego/CMakeLists.txt` にパッチを適用してください。MSVC ARM64 で無条件に `return()` しないようにし、`cc_library(NAME zvec_ailego ...)` の呼び出しを維持し、`-march=armv8-a` などの GCC/Clang フラグは MSVC 以外のコンパイラにのみ適用してください。

Question 3

LinuxでexcludedFileTypesを指定してcontext()を使用した際にzvecでSIGSEGVネイティブスタックオーバーフローが発生する問題を修正する方法

Accepted Answer

このクラッシュは、`excludedFileTypes` が数千もの `file_id = ... OR ...` 述語に展開され、ネイティブの `sqlengine::QueryNode` パーサーがそれらを再帰的に処理し続けてスタックオーバーフローに至るために発生します。この問題はプルリクエスト #694 で修正されており、長い OR 式の処理が追加され、次回のリリースに含まれる予定です。そのリリースが利用可能になったら、`@zvec/zvec`、Linux x64 バインディング、および `@zvec/zvec-grep` をアップグレードしてください。例: `npm install @zvec/zvec@latest @zvec/bindings-linux-x64@latest @zvec/zvec-grep@latest`。`@zvec/zvec@0.7.0` や `@zvec/zvec-grep@0.2.1` などの影響を受けるバージョンでの一時的な回避策としては、`session.context()` から `excludedFileTypes` を省略し、取得後に JavaScript で除外対象のファイルタイプをフィルタリングするか、クエリの対象となるファイル数を減らしてください。

Question 4

IVF の `n_iters` が無視され、KMeans がデフォルトの反復回数を使用してしまう問題を修正する方法

Accepted Answer

これはパラメータ伝播のバグでした。`IVFIndexParam::n_iters` は IVF パラメータまでは到達していましたが、第1レベルの KMeans/OptKMeans クラスタラーには渡されていなかったため、クラスタリングではデフォルトの反復回数が使用されていました。PR `fix(core): IVF n_iters propagation to clusterer`（issue #729）を含むリリースにアップグレードするか、ソースからビルドする場合はその PR を cherry-pick してください。この修正では、`n_iters` を第1レベルのクラスタリングパラメータに転送し、ビルダーのパラメータ伝播に対するリグレッションカバレッジも含まれています。

Question 5

なぜ zvec の Collection.optimize() は upsert または delete の後にベクトルの欠落や誤りを引き起こすのですか？

Accepted Answer

これは zvec 0.6.0 および 0.7.0 における既知のインデックス再構築バグです。`optimize()` が不要になった行を削除すると、ベクトルファイルは有効なドキュメント数を使って再構築されますが、ルックアップには引き続き元のセグメント行 ID が使用されます。K 件の行が削除または上書きされている場合、有効なベクトルの末尾 K 件分がファイルの終端を超えて読み取られ、後続のドキュメント ID も誤ったベクトルにマッピングされる可能性があります。典型的なログには `Read vector failed`、`Failed to fetch vector`、`vector indexer fetch failed` が含まれます。

影響を受けるバージョンでの回避策:
1. `upsert()` による更新や `delete()` 操作を実行した後は、`Collection.optimize()` を呼び出さないでください。
2. `optimize()` がすでに実行されている場合は、最適化前に取得したバックアップから復元するか、同じスキーマで新しいコレクションを作成し、ソースデータからすべての有効なドキュメントを再度 upsert してください。
3. 修正 `preserve vector row mapping when rebuilding indexes with deleted rows`(issue #724 の修正)を含む zvec リリースにアップグレードしてください。`python -m pip install -U zvec` を使用し、リリースノートにその修正が含まれていることを確認してください。
4. アップグレード後、以前 `optimize()` によって破損したコレクションは再構築または再インポートしてください。アップグレードだけでは、すでに不正確になったベクトルマッピングは修復されない可能性があります。

`stats.doc_count` やスカラースキャンでは、ベクトル検索から欠落しているドキュメントが依然として報告される可能性があるため、スカラー結果と、ベクトルを含めた `fetch()` の両方を確認して復旧を検証してください。

zvec

概要

README プレビュー

FAQ (5)

同类型项目

browser-use

puppeteer

manim

PaddleOCR