SOTA privacy experiment: decouple stored embeddings with shadow queries
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- wasm
- Ambito
- databases, machine-learning, performance, security
Direzione di ricerca
Non sono indicati file di implementazione o test. Inizia mappando le cinque condizioni congelate e l'attacco adattivo a livello di set rispetto all'indicizzazione RuVector esistente, quindi definisci gli input e le misurazioni del benchmark elencati nel report. Il lavoro è completato quando viene soddisfatto ogni promotion gate, preservando l'eliminazione e l'isolamento dei tenant, oppure quando viene documentata la falsificazione e il design viene rifiutato senza modificare i valori predefiniti di produzione.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Finding
Shadow Queries for Private Retrieval in Vector Databases, submitted 2026-09-04, targets embedding inversion rather than query privacy. Instead of storing a document embedding directly, SHAQ generates diverse semantically relevant shadow queries per document and stores embeddings of those queries. The originating team reports text recovery as low as 0.2104, up to 19.50% more defended tokens than baseline defenses, MAP@10 up to 0.7967, and up to 5.53% utility improvement over the compared defense.
Evidence class: originating-team measured, not independently reproduced by RuV. The arXiv manuscript is under the arXiv perpetual non-exclusive license. No implementation license suitable for code reuse was verified in this cycle, so this issue imports no source code.
RuV implication
This is orthogonal to issue #967. #967 addresses outsourced query privacy under a two-server non-collusion model. This issue addresses stored-embedding inversion if an attacker obtains or queries the vector representation itself.
Potential reuse: RuVector hosted indexes, Core Memory enterprise memory, Cognitum RAG, MCP retrieval, RVF provenance, and bounded RuVector WASM stores.
Reversible experiment
Compare five frozen conditions:
A. ordinary document embeddings
B. additive-noise defense at matched retrieval utility
C. vector scaling or normalization defense at matched retrieval utility
D. one shadow-query embedding per document
E. diverse multi-shadow-query indexing with a fixed generation budget
Use at least two embedding models and three corpora with materially different document length and semantic density.
Attack model
Reproduce a modern embedding inversion baseline such as vec2text, then add an adaptive attacker that knows the defense architecture and generation prompt family but not secret tenant data.
Required benchmark report
Record corpus digest, embedding model and version, shadow generator and version, prompts, seeds, document count, query count, index size, construction latency, generation tokens and cost, MAP@10, recall@10, p50/p95/p99 query latency, storage multiplier, inversion recovery, defended-token rate, CPU, memory, and energy where measurable. Include malformed documents, low-information documents, duplicate content, updates, deletes, distribution shift, and adversarial query patterns.
Promotion gate
A shadow-query design advances only if all are true:
- inversion recovery falls by at least 50% relative to ordinary document embeddings
- retrieval quality loses no more than 1 absolute point of MAP@10 or recall@10 against the stronger baseline
- p95 query latency regresses by less than 10%
- index storage stays below 3 times the document-embedding baseline
- generation cost is amortized within the declared customer workload horizon
- deletion and tenant isolation semantics remain exact
Falsification
The defense may simply move sensitive information from a document embedding into several semantically revealing query embeddings. Test an adaptive attacker over the entire per-document shadow set, not one vector at a time. If privacy gain disappears under set-level attacks, reject the design.
A cheaper dimensionality reduction or quantization baseline must also be included. If it performs within variance at lower cost, prefer the simpler defense.
Security and governance
Shadow queries are derived sensitive artifacts and inherit the source document's tenant, retention, deletion, and access policy. They cannot be logged or reused across tenants. Retrieval quality is not evidence of privacy. Privacy measurements cannot authorize release or declassification.
Existing RuVector indexing remains the rollback path. No production format migration or default change is authorized.
- Lingua principale
- Rust
- Stelle
- 4.5k
- Fork
- 603
- Merge medio
- 1g 11h
- PR unite (30g)
- 56
Preparare l'ambiente
Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ruvnet/RuVector
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di ruvnet/RuVector
Issue simili
-
Fix large enum variantAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
software-challenge/player_rust#22 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
foundry-rs/foundry#17175 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
state:triage-needed
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
github/copilot-sdk#2793 ·
I maintainer di solito rispondono entro 1 giorno