No edges found when using manually extracted models

[Retreatcost]

Using a provided vindex (hf://chrishayuk/gemma-3-4b-it-vindex) seems to work perfectly fine, however when trying to extract a standalone safetensors model (for example mistralai/Mistral-7B-Instruct-v0.3) vindex doesn't seem to have knowledge graph.

./larql repl

   ╦   ╔═╗ ╦═╗ ╔═╗ ╦
   ║   ╠═╣ ╠╦╝ ║═╬╗║
   ╩═╝ ╩ ╩ ╩╚═ ╚═╝╚╩═╝
   Lazarus Query Language v0.1

larql> USE "mistral7b.vindex";
Using: mistral7b.vindex (32 layers, 458.8K features, model: mistralai/Mistral-7B-Instruct-v0.3)
larql> DESCRIBE "France";
France
  (no edges found)
larql> STATS;
Model:           mistralai/Mistral-7B-Instruct-v0.3

Features:        458.8K (14.3K x 32 layers)

Knowledge Graph:
  (no relation clusters found)

  By layer band:
    Syntax (L0-13):     200.7K features
    Knowledge (L14-27): 200.7K features
    Output (L28-33):    57.3K features

Index size:      27.04 GB
Path:            mistral7b.vindex

Other features seem to work fine, however describing and querying does not.

I found that there is a file, that is missing - feature_labels.json - it is present in your example vindex, but not in local extracted one:

./larql verify mistral7b.vindex
Verifying: mistral7b.vindex (8 files)
  attn_weights.bin ... OK (5.00 GB)
  norms.bin ... OK (1.0 MB)
  down_weights.bin ... OK (7.00 GB)
  lm_head.bin ... OK (512.0 MB)
  embeddings.bin ... OK (512.0 MB)
  gate_vectors.bin ... OK (7.00 GB)
  down_meta.bin ... OK (38.5 MB)
  up_weights.bin ... OK (7.00 GB)

All 8 files verified.

As I understood it should be used for best feature description and is used in higher priority over discovered relation clusters, but those were also not created in the first place.

If there are additional mandatory steps, I haven't found them.

If you have any pointers to how to proceed or fix this issue, it would be really helpful. Thanks.

[metavacua]

metavacua#152 testing and inspection indicates that the larql-cli extract command silently fails to produce the feature_labels.json and the Rust source code does not appear to produce the feature_label.json. However, apparently the larql-python and larql-knowledge source handles this.

There's an implicit and undeclared dependency on a wikidata dump and related data dumps that are responsible for some of the LQL verb's behaviors.

Presently, the extract command is over 18 K lines of code, some portion of the larql-knowledge subproject, and sprawling disorganized documentation.

[Retreatcost]

metavacua#152 testing and inspection indicates that the larql-cli extract command silently fails to produce the feature_labels.json and the Rust source code does not appear to produce the feature_label.json. However, apparently the larql-python and larql-knowledge source handles this.

There's an implicit and undeclared dependency on a wikidata dump and related data dumps that are responsible for some of the LQL verb's behaviors.

Presently, the extract command is over 18 K lines of code, some portion of the larql-knowledge subproject, and sprawling disorganized documentation.

Thank you for your response.
Thanks to linked issues I found out about knowledge submodule and I am currently building labels for the model.

It seems that binary expects the data folder with prepared categories (clustering submodule).

It needed some additional work:

• manual creation of probe_templates.json (was handled via simple script and external LLM)
• probe/scripts/probe_mlx.py - works only on Apple silicon, so I had to modify it to support cuda via torch.

When I complete the process and verify that everything works, I am planning to create a proper merge request.

[metavacua]

I have identified in metavacua#173 that there's currently a potential data licensing issue with the knowledge pipeline. WordNet and wikidata seem compatible data sets with the existing Apache 2.0 licensing.

[metavacua]

metavacua#152 testing and inspection indicates that the larql-cli extract command silently fails to produce the feature_labels.json and the Rust source code does not appear to produce the feature_label.json. However, apparently the larql-python and larql-knowledge source handles this.
There's an implicit and undeclared dependency on a wikidata dump and related data dumps that are responsible for some of the LQL verb's behaviors.
Presently, the extract command is over 18 K lines of code, some portion of the larql-knowledge subproject, and sprawling disorganized documentation.

Thank you for your response. Thanks to linked issues I found out about knowledge submodule and I am currently building labels for the model.

It seems that binary expects the data folder with prepared categories (clustering submodule).

It needed some additional work:

• manual creation of probe_templates.json (was handled via simple script and external LLM)
• probe/scripts/probe_mlx.py - works only on Apple silicon, so I had to modify it to support cuda via torch.

When I complete the process and verify that everything works, I am planning to create a proper merge request.

Let me know if you come across any anomalies or difficulties with the Mistral-7B-Instruct-v0.3 or any other language models that you try extracting and labeling for LQL.

I have preliminary results on smollm2-360m that seem to indicate a possible problem with the way that the wikidata_triples.json is constructed or used in probing and labelling arbitrary language models; alternatively, feature_labels.json might be questionable in how it is constructed.

I'm testing against BitNet, qwen 3, and possibly a few other models to try to get more representative sample of data, and at the least, it seems there's a possible robustness improvement evident here.

[metavacua]

Cross-reference from metavacua/larql-to-sparql:

The validation audit (2026-06-19) found several gaps specifically relevant to this issue
("No edges found when using manually extracted models"). The root causes are tracked as:

For the lm_head-specific failure case:

• convert: lm_head format-tag collision detectable only via manual larql parity metavacua/larql-to-sparql#203 — lm_head format-tag collision detectable only via manual
  larql parity --component lm-head.

The larql dev fidelity command (7-case functional validation plan) is also unimplemented —
tracked at metavacua#207.