Q: なぜ GLiNER2 のエンティティ抽出は、長いドキュメントの最初の 512 語以降にあるエンティティを見逃してしまうのですか？

修正前のバージョンでは、GLiNER2モデル(`fastino/gliner2-base-v1`、`fastino/gliner2-large-v1`)におけるエンティティ、リレーション、および構造化抽出で、各アイテムのテキストが`max_seq_length`(デフォルトで512語)の位置で通知なく切り詰められていたため、そのウィンドウを超えたコンテンツはモデルに一切届きませんでした。修正方法: PR #552(コミット`689e4d808cbd66008500da8f58d8fa6e71510b8f`)を含むビルドにアップグレードしてください。修正後は、長すぎるアイテムは暗黙の部分的な読み取りではなく、アイテムごとの明示的な`INPUT_TOO_LONG`エラーで失敗します。拒否されたアイテムはモデル呼び出しから除外され、入力トークン使用量はゼロとして報告されますが、同じバッチ内の有効なアイテムは結果と元の位置を保持します。オーバーラップするウィンドウによるドキュメント全体の抽出は、依然として未マージの機能強化(#649)です。これが導入されるまでは、`POST /v1/extract/{model}`を呼び出す前に、長いドキュメントを単語/サブワードのウィンドウに収まるチャンクに分割してください。

Q: gliner2 2.0.0にアップグレードした後の重複したNERエンティティと'structured extraction property must be a string'エラーを修正するにはどうすればよいですか？

gliner2 2.0.0 では、`fastino/gliner2-base-v1` と `fastino/gliner2-large-v1` の出力が2つの点で変更されました。(1) NER の重複排除キーが `text.lower()` から `(text.lower(), start, end)` に変更されたため、繰り返し出現するエンティティについて最初のメンションだけでなくすべてのメンションが返されるようになりました（長いテキストではエンティティ数が例えば 21 → 100 に跳ね上がることがあります）。(2) 構造化抽出が再スコアリングされ、一部のフィールドが `null` を返すようになりました。これは SIE の `GLiNER2Adapter` によって `GLiNER2 structured extraction property 'person' must be a string` というエラーで拒否され、リクエスト全体が失敗します。回避策：gliner2 を 1.x 系にピン留めします（`gliner2>=1.3.1,<2`、すなわち 1.3.2）。これはデフォルトバンドルとルートロックで行われていることです。注意：オプトインの entity LoRA アダプターは厳密に gliner2 1.3.2 を必要とするため、2.x では壊れます。2.0.0 を実行しなければならない場合は、1.x の動作を復元するために、小文字化した表層形でエンティティを自身で重複排除し、リクエストを失敗させるのではなく、`null` の構造化フィールドを適切に処理してください（プロパティを省略するか、アイテム単位のエラーを出力します）。これらのモデルの 2.x への移行は、メンションポリシー、null の扱い、再ベースライン化に関する決定がまだ下されていないため、保留中です。

Q: macOS arm64 (Apple Silicon) で mmap 経由で safetensors の重みを読み込む際に torch.nn.functional.linear が NaN/Inf を出力する問題を解決する方法

原因: 影響を受ける macOS arm64 スタック (例: torch 2.9.1、Python 3.12) では、メモリマップされた safetensors テンソルがアラインされていないアドレスから始まる場合があります (テンソルのファイルオフセットが 4/64 バイトアライメントされていないため、data_ptr % 64 != 0 となります)。このようなマップされた重みを `torch.nn.functional.linear` に渡すと、重み、入力、バイアスがすべて有限であるにもかかわらず、非有限 (NaN/Inf) の出力が生成されます。回避策: 使用前に重みのアラインされたインメモリコピーを強制的に作成する (`weight = weight.clone()`)、または `safe_open` や遅延テンソルフレームワークによる mmap ビューの代わりに、`safetensors.torch.load_file("model.safetensors")` でチェックポイントを読み込んでください。クローン後、バイト単位で同一の重みは非有限値が 0 となり、float64 NumPy リファレンスと一致します (最大絶対誤差 ~5.2e-6)。影響を受けるかどうかを確認するには、`tensor.data_ptr() % 64` を調べてください: マップされたテンソルでこの値が非ゼロの場合、リスクがあることを示しています。

Q: GPUがほとんどアイドル状態であるにもかかわらず、GLiFormerの推論が短いテキストで遅くなるのはなぜですか？また、どのように修正すればよいですか？

短い入力（40〜140トークン）では、GLiFormerの47 msの順伝播はカーネル起動によってCPUバウンドとなっており、約1,270個の小さなCUDAカーネルを発行し、約71回のストリーム同期（うち31回はタスクヘッド内の`.item()`呼び出しによるもの）が発生する一方、GPUがビジー状態にあるのは約8 msにすぎません。修正はCUDAグラフリプレイであり、#367のGLiClassのアプローチに倣ってPR #796で実装されました。順伝播の静的な部分（固定パディング形状のDeBERTaバックボーン）は一度だけ記録され、CUDAグラフとしてリプレイされる一方、データ依存の制御フローを持つタスクヘッドはeagerのまま残り、グラフの静的出力バッファを読み取ります。CUDAグラフはオプトインであり、デフォルトではOFFです。'exact shapes'モードを有効にすると、eager実行とビット単位で同一の出力で事前学習済みパリティチェックに合格します。バケット（パディング長）モードは、固定された数値許容誤差の制限を満たさなかったため、却下/利用不可となっています。メモリ使用量はモデルごとのバジェットによって上限が設けられ、記録は一度に1つのみ実行され、メモリ圧迫時には記録がスキップされ、モデルのアンロード時にグラフメモリが解放されます。

Question 1

なぜ Docker イメージのビルドでは uv.lock でピン留めされたバージョンよりも新しいパッケージバージョンがインストールされてしまうのか、また、pip インストールを再現可能にするにはどうすればよいですか？

Accepted Answer

これは、イメージビルドが範囲指定子（例：`gliner>=0.2.26,<1`）を使って `pip install -r` を実行する場合に発生します。pipはビルド時に一致する最新のリリースを解決するため、`uv.lock` にピン留めされた正確なバージョンが覆い隠され、同じコミットの2つのビルドが異なる、テストされていないバージョンを出荷する可能性があります。sie_serverでは、PR #653と#802によってこれが修正されました。バンドルイメージはビルド中に範囲を解決しなくなりました。代わりに、リリースされた11個のLinux amd64イメージすべてと、サポートされている4つのCPU arm64の組み合わせをカバーする、リポジトリにチェックインされた15個のターゲットロックから、保存された依存関係クロージャをインストールします。パッケージは、明示的で文書化されたバンドル例外が適用されない限り、ルートの `uv.lock` のピンを維持します。CIは古い、または不整合なロックを拒否し、イメージビルドはインストールされた `/app/bundle-libs` のインベントリ（`pip freeze`）を検証・保持するため、デプロイされたどのバージョンでも監査できます。自分のプロジェクトでこれを修正するには：(1) `uv export --frozen --no-hashes` でロックされたバージョンをエクスポートし、それをconstraintsファイルとしてpipに渡して（`pip install -c constraints.txt -r requirements.txt`）、ロックされたパッケージがピン留めされたバージョンを維持するようにする、(2) または、正確なバージョンをリポジトリにチェックインしたバンドルごとのロックファイルを維持する、(3) そして、イメージ内のインストールされたターゲットディレクトリの解決済み `pip freeze` を記録します。

Question 2

なぜ GLiNER2 のエンティティ抽出は、長いドキュメントの最初の 512 語以降にあるエンティティを見逃してしまうのですか？

Accepted Answer

修正前のバージョンでは、GLiNER2モデル(`fastino/gliner2-base-v1`、`fastino/gliner2-large-v1`)におけるエンティティ、リレーション、および構造化抽出で、各アイテムのテキストが`max_seq_length`(デフォルトで512語)の位置で通知なく切り詰められていたため、そのウィンドウを超えたコンテンツはモデルに一切届きませんでした。修正方法: PR #552(コミット`689e4d808cbd66008500da8f58d8fa6e71510b8f`)を含むビルドにアップグレードしてください。修正後は、長すぎるアイテムは暗黙の部分的な読み取りではなく、アイテムごとの明示的な`INPUT_TOO_LONG`エラーで失敗します。拒否されたアイテムはモデル呼び出しから除外され、入力トークン使用量はゼロとして報告されますが、同じバッチ内の有効なアイテムは結果と元の位置を保持します。オーバーラップするウィンドウによるドキュメント全体の抽出は、依然として未マージの機能強化(#649)です。これが導入されるまでは、`POST /v1/extract/{model}`を呼び出す前に、長いドキュメントを単語/サブワードのウィンドウに収まるチャンクに分割してください。

Question 3

gliner2 2.0.0にアップグレードした後の重複したNERエンティティと'structured extraction property must be a string'エラーを修正するにはどうすればよいですか？

Accepted Answer

gliner2 2.0.0 では、`fastino/gliner2-base-v1` と `fastino/gliner2-large-v1` の出力が2つの点で変更されました。(1) NER の重複排除キーが `text.lower()` から `(text.lower(), start, end)` に変更されたため、繰り返し出現するエンティティについて最初のメンションだけでなくすべてのメンションが返されるようになりました（長いテキストではエンティティ数が例えば 21 → 100 に跳ね上がることがあります）。(2) 構造化抽出が再スコアリングされ、一部のフィールドが `null` を返すようになりました。これは SIE の `GLiNER2Adapter` によって `GLiNER2 structured extraction property 'person' must be a string` というエラーで拒否され、リクエスト全体が失敗します。回避策：gliner2 を 1.x 系にピン留めします（`gliner2>=1.3.1,<2`、すなわち 1.3.2）。これはデフォルトバンドルとルートロックで行われていることです。注意：オプトインの entity LoRA アダプターは厳密に gliner2 1.3.2 を必要とするため、2.x では壊れます。2.0.0 を実行しなければならない場合は、1.x の動作を復元するために、小文字化した表層形でエンティティを自身で重複排除し、リクエストを失敗させるのではなく、`null` の構造化フィールドを適切に処理してください（プロパティを省略するか、アイテム単位のエラーを出力します）。これらのモデルの 2.x への移行は、メンションポリシー、null の扱い、再ベースライン化に関する決定がまだ下されていないため、保留中です。

Question 4

macOS arm64 (Apple Silicon) で mmap 経由で safetensors の重みを読み込む際に torch.nn.functional.linear が NaN/Inf を出力する問題を解決する方法

Accepted Answer

原因: 影響を受ける macOS arm64 スタック (例: torch 2.9.1、Python 3.12) では、メモリマップされた safetensors テンソルがアラインされていないアドレスから始まる場合があります (テンソルのファイルオフセットが 4/64 バイトアライメントされていないため、data_ptr % 64 != 0 となります)。このようなマップされた重みを `torch.nn.functional.linear` に渡すと、重み、入力、バイアスがすべて有限であるにもかかわらず、非有限 (NaN/Inf) の出力が生成されます。回避策: 使用前に重みのアラインされたインメモリコピーを強制的に作成する (`weight = weight.clone()`)、または `safe_open` や遅延テンソルフレームワークによる mmap ビューの代わりに、`safetensors.torch.load_file("model.safetensors")` でチェックポイントを読み込んでください。クローン後、バイト単位で同一の重みは非有限値が 0 となり、float64 NumPy リファレンスと一致します (最大絶対誤差 ~5.2e-6)。影響を受けるかどうかを確認するには、`tensor.data_ptr() % 64` を調べてください: マップされたテンソルでこの値が非ゼロの場合、リスクがあることを示しています。

Question 5

GPUがほとんどアイドル状態であるにもかかわらず、GLiFormerの推論が短いテキストで遅くなるのはなぜですか？また、どのように修正すればよいですか？

Accepted Answer

短い入力（40〜140トークン）では、GLiFormerの47 msの順伝播はカーネル起動によってCPUバウンドとなっており、約1,270個の小さなCUDAカーネルを発行し、約71回のストリーム同期（うち31回はタスクヘッド内の`.item()`呼び出しによるもの）が発生する一方、GPUがビジー状態にあるのは約8 msにすぎません。修正はCUDAグラフリプレイであり、#367のGLiClassのアプローチに倣ってPR #796で実装されました。順伝播の静的な部分（固定パディング形状のDeBERTaバックボーン）は一度だけ記録され、CUDAグラフとしてリプレイされる一方、データ依存の制御フローを持つタスクヘッドはeagerのまま残り、グラフの静的出力バッファを読み取ります。CUDAグラフはオプトインであり、デフォルトではOFFです。'exact shapes'モードを有効にすると、eager実行とビット単位で同一の出力で事前学習済みパリティチェックに合格します。バケット（パディング長）モードは、固定された数値許容誤差の制限を満たさなかったため、却下/利用不可となっています。メモリ使用量はモデルごとのバジェットによって上限が設けられ、記録は一度に1つのみ実行され、メモリ圧迫時には記録がスキップされ、モデルのアンロード時にグラフメモリが解放されます。

sie

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト