RAG Architecture

Knowledge Base

VenomX grounds every response in a 250,000+ record security corpus (CVEs, exploits, and attack techniques) retrieved semantically and re-ranked before the model ever sees them.

330k+
CVE Records
50k+
Exploit Entries
700
MITRE Techniques
1024
Embedding Dims

Corpora

Three Knowledge Bases

Each corpus is domain-specific, embedded offline, and HNSW-indexed for sub-millisecond retrieval at query time.

NVD Daily Feed
CVE Knowledge Base
330k+
vulnerability records

Sourced from the National Vulnerability Database, updated daily as NVD publishes new CVEs. HNSW indexing (not IVFFlat) was chosen specifically because IVFFlat degrades with incremental inserts. NVD publishes hundreds of CVEs daily.

Schema Fields

  • CVE ID (e.g. CVE-2021-44228)
  • Description text (embedded)
  • CVSS score + vector string
  • Severity: LOW / MEDIUM / HIGH / CRITICAL
  • Affected products array
  • Published & modified timestamps
Exploit-DB
Exploit Entries
50k+
exploit entries

Full Exploit-DB dump with working code text, platform metadata, and CVE cross-references. Enables retrieval of actual exploit code alongside the vulnerability context: not just descriptions, but working proof-of-concept material.

Schema Fields

  • EDB ID (Exploit-DB identifier)
  • Title & platform
  • Exploit type classification
  • Author
  • Full code text (embedded)
  • CVE cross-references
MITRE ATT&CK
Techniques & Tactics
700
technique entries

Complete MITRE ATT&CK framework covering every technique, sub-technique, tactic, detection method, and mitigation. Grounds the model's adversarial reasoning in the industry-standard taxonomy used by red teams, SOCs, and threat intel teams worldwide.

Schema Fields

  • Technique ID (e.g. T1059.001)
  • Name & tactic
  • Description (embedded)
  • Detection methods
  • Mitigation guidance

How It Retrieves

The Retrieval Pipeline

From raw query to LLM context in five steps. The full round-trip adds less than 200ms.

Step 1
Query Embedding
bge-m3 encodes the user's query into a 1024-dimensional dense vector
~50ms · CPU
›
Step 2
Hybrid Search
pgvector HNSW cosine search + SQL metadata filters (CVSS ≥ threshold, product match, severity)
<10ms · PostgreSQL
›
Step 3
Top-20 Candidates
Broad recall: semantic similarity surfaces the most relevant records across all three corpora
results in memory
›
Step 4
Cross-Encoder Re-rank
ms-marco-MiniLM-L-6-v2 scores each (query, doc) pair, dramatically improving version/product precision
~100ms · CPU
›
Step 5
Top-5 to LLM
Highest-precision results injected into the model's context window before generation
injected into prompt

Example Hybrid Query

SQL · pgvector 
-- Find CVEs relevant to a scan result, filtered by severity and product
SELECT c.cve_id, c.cvss_score, c.severity, c.description,
       1 - (e.embedding <=> $query_vec) AS similarity
FROM  cve_embeddings e
JOIN  cves c ON c.cve_id = e.cve_id
WHERE c.cvss_score  >= 7.0
  AND c.affected_products @> ARRAY['apache']
ORDER BY similarity DESC
LIMIT 20;  -- retrieve 20, re-rank to top 5

Model Choices

Embedding & Re-ranking

BAAI/bge-m3

Primary embedding model. bge-m3 supports dense, sparse, and ColBERT retrieval in a single model with hybrid retrieval built in. At 1024 dimensions it significantly outperforms general-purpose models like all-MiniLM-L6-v2 on technical security terminology.

The full 250k+ embedding corpus (~800MB at 1024-dim × 4 bytes) stays resident in PostgreSQL shared buffers, hot in RAM with zero disk I/O at query time.

1024 dims dense + sparse + colbert ~50ms / query CPU inference ~800MB resident

cross-encoder/ms-marco-MiniLM-L-6-v2

Re-ranking model. After pgvector returns 20 candidates via approximate nearest-neighbor search, the cross-encoder rescores each (query, document) pair with full attention, dramatically improving precision for specific version/product queries where semantic similarity alone frequently surfaces outdated or patched CVEs over current ones.

This is the single highest-impact quality step in the pipeline.

20 candidates → top 5 ~100ms / batch CPU inference ms-marco trained

Infrastructure Decisions

Why PostgreSQL + pgvector

Pure vector stores like ChromaDB are built for one thing: semantic search. VenomX's queries are more complex than that, and the data scale doesn't forgive naive architecture choices.

Hybrid Queries

SQL metadata predicates combined with vector cosine search in a single query. ChromaDB can't filter by CVSS score, product array, or severity efficiently at 330k+ scale. PostgreSQL handles both natively.

Daily Updates

NVD publishes new CVEs every day. IVFFlat requires re-clustering when data changes significantly. HNSW handles incremental inserts cleanly with no re-index required when new CVEs arrive.

Single Stack

One database process handles both structured relational data and vector similarity search. No separate ChromaDB/Weaviate/Pinecone process, no sync overhead, no additional failure point.

HNSW vs IVFFlat

Index Dynamic updates Query speed Build time Verdict
IVFFlat Requires re-cluster Fast Fast Wrong for daily CVE ingestion
HNSW ✓ Clean incremental inserts Fast Slower Correct for dynamic CVE updates

Memory footprint: 250k vectors at 1024 dims × 4 bytes ≈ ~800MB. PostgreSQL shared buffers keep the entire embedding set hot in the 32GB DDR4 system RAM. No VRAM consumed (both GPUs are fully allocated to vLLM inference). At query time, retrieval is pure in-memory with no disk I/O.