Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

SOTA privacy experiment: decouple stored embeddings with shadow queries

Aperta
#970 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

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

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:

  1. inversion recovery falls by at least 50% relative to ordinary document embeddings
  2. retrieval quality loses no more than 1 absolute point of MAP@10 or recall@10 against the stronger baseline
  3. p95 query latency regresses by less than 10%
  4. index storage stays below 3 times the document-embedding baseline
  5. generation cost is amortized within the declared customer workload horizon
  6. 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

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ruvnet/RuVector

Tutte le issue di ruvnet/RuVector

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.