Agentic Systems

Research Brief — Enterprise RAG in Production (2026): Reference Architecture, Off-the-Shelf Components, and the NVIDIA Stack

Working research note — source-verified but not part of the reviewed reference site; citations resolve within this document's own Sources section.

Prepared: 2026-07-13. Audience: agentic-systems knowledge base; the whiteboard companion to retrieval-rag-sota.md — that brief owns the methodology (index internals §3, vector-DB landscape §4, quality stack §5, agentic RAG §6.3); this one owns the production system: the end-to-end architecture, real named components for every box, and the NVIDIA mapping. All component names, model ids, versions, and quotes were verified against the cited pages on 2026-07-13. Companion briefs: retrieval-rag-sota.md, orchestration-algorithms-sota.md, paper-reviews.md.


1. Executive summary

  1. The pipeline is standardized: ingestion/parsing → chunking → embedding → vector store
    • lexical hybrid → fusion → rerank → generation with citations, wrapped by evals, observability, and guardrails. Every box has 2–4 credible off-the-shelf options (§2).
  2. The frontier moved from the pipeline to the loop. Agentic RAG makes retrieval a tool the model calls, grades, and retries — LangGraph's canonical graph is retrieve/grade/rewrite/generate (§3). Fixed pipelines still win on latency, cost, and auditability for single-hop traffic.
  3. NVIDIA ships the whole diagram as one artifact. The RAG Blueprint (v2.6.0) pins NeMo Retriever extraction/embedding/reranking NIMs, an Elasticsearch default with GPU-accelerated Milvus (cuVS/CAGRA) as the alternative, Nemotron 3 Super for generation, optional reflection and guardrails; AI-Q builds the deep-research flavor on top (§4).
  4. Production RAG is an evals-and-security problem wearing an IR costume: RAGAS-style and retrieval metrics belong in CI (§5.4), and retrieval is an untrusted-content channel — indirect prompt injection arrives inside the documents you retrieve (§5.5).
  5. Scale and cost decisions are already tabulated — reuse retrieval-rag-sota.md §4's selection heuristics and §3's quantization lens rather than re-deriving them (§5.1).

2. Reference architecture, end to end

flowchart LR
  subgraph ingest[Ingestion path]
    A[Sources: PDF, HTML, wikis, tickets] --> B[Parsing / extraction]
    B --> C[Chunking]
    C --> D[Embedding]
    D --> E[(Vector index)]
    C --> F[(Lexical index BM25)]
  end
  subgraph serve[Query path]
    Q[User query] --> G[Query processing]
    G --> E
    G --> F
    E --> H[Fusion RRF]
    F --> H
    H --> I[Reranker]
    I --> J[LLM generation + citations]
    J --> R[Answer with sources]
  end
  subgraph platform[Platform]
    V[Evals in CI] -.-> serve
    O[Observability / tracing] -.-> serve
    S[Guardrails: input, retrieval, output] -.-> serve
  end

Each stage: what it does, the component menu (all verified to exist), one gotcha.

2.1 Ingestion and parsing

What: turn heterogeneous enterprise documents into structured text + tables + figures with metadata (source, ACLs, timestamps). Menu: Docling — "Get your documents ready for gen AI" (IBM Research; PDF, DOCX, PPTX, XLSX, HTML, images; exports Markdown/HTML/lossless JSON) [docling-github]; Unstructured — "Convert documents to structured data effortlessly" (open-source ETL: parsing, partitioning, chunking for LLM/RAG pipelines) [unstructured-github]; NVIDIA NeMo Retriever extraction — "content and metadata extraction from various media types (PDFs, HTML, Word docs, Powerpoint, audio, video, and image files)," extracting "text, tables, charts, infographics, and transcripts" [nemo-retriever-docs]. Gotcha: most RAG quality loss happens before retrieval — a parser that flattens a table into word soup poisons every downstream stage (that is why the specialized table/chart/OCR models of §4.2 exist); budget parsing evaluation like retrieval evaluation.

2.2 Chunking

What: split parsed documents into retrievable units sized for the embedder and the generator's context budget. Menu: LlamaIndex node parsers — "a simple abstraction that take a list of documents, and chunk them into Node objects, such that each node is a specific chunk of the parent document" (SentenceSplitter, TokenTextSplitter, SemanticSplitterNodeParser, MarkdownNodeParser) [llamaindex-node-parsers]; Unstructured's chunking within its ETL flow [unstructured-github]; semantic/late/contextual chunking strategies are owned by retrieval-rag-sota.md §5.1. Gotcha: chunk boundaries sever context — "it fails when the flag is set" retrieves badly because "it" lost its referent; fixes in retrieval-rag-sota.md §5.1, and chunk size is tuned against retrieval metrics, not intuition.

2.3 Embedding

What: encode chunks (index time) and queries (query time) into vectors with the same model. Menu: OpenAI text-embedding-3-small / text-embedding-3-large ("our newest and most performant embedding models," 8192-token inputs, dimension-reduction parameter) [openai-embeddings]; NVIDIA NeMo Retriever embedding NIMllama-nemotron-embed-1b-v2, the RAG Blueprint default [nvidia-rag-blueprint]; open-weight leaders and the MTEB/BEIR selection discussion are in retrieval-rag-sota.md §7 and §2.2. Gotcha: the embedding model is part of your schema — swap it and every stored vector must be recomputed, because query and corpus vectors are only comparable within one model; version-pin it and plan re-embedding as a migration (§5.2).

2.4 Vector store + lexical hybrid

What: ANN search over vectors plus a BM25 index — enterprise queries are full of exact identifiers (SKUs, error codes, names) that dense embeddings blur. Menu: Elasticsearch — "Hybrid search runs full-text search and vector search in one request… you return one ranked list that combines keyword matching with similarity search" [elastic-hybrid]; Milvus — GPU indexes GPU_CAGRA, GPU_IVF_FLAT, GPU_IVF_PQ, GPU_BRUTE_FORCE, "contributed by Nvidia RAPIDS team" [milvus-gpu-index]; Qdrant — payload-partitioned multi-tenant collections [qdrant-multitenancy]; pgvector — "Open-source vector similarity search for Postgres" (HNSW, IVFFlat) [pgvector-github]. Landscape and choose-by-scale heuristics: retrieval-rag-sota.md §4; internals and quantization: its §3. Gotcha: dense-only retrieval silently fails on out-of-vocabulary exact terms — hybrid is the enterprise default, not an optimization (BM25 formula in retrieval-rag-sota.md §9.1).

2.5 Fusion

What: merge the dense and lexical result lists into one ranking. Menu: Elasticsearch RRF — "We recommend implementing hybrid search with the reciprocal rank fusion (RRF) algorithm. This approach merges rankings from the full-text and vector queries, giving more weight to documents that score well in either one" [elastic-hybrid]; the RAG Blueprint's built-in hybrid dense+sparse search [nvidia-rag-blueprint]; or application-level RRF — a few lines of arithmetic (formula and the canonical k = 60 in retrieval-rag-sota.md §9.3). Gotcha: score-based fusion is fragile because BM25 scores and cosine similarities live on incomparable scales — rank-based fusion (RRF) sidesteps calibration entirely, which is why it is the default recommendation.

2.6 Reranking

What: re-score the fused top-k with a cross-encoder that reads query and document together, buying precision bi-encoders cannot express. Menu: Cohere Rerank — "Given a query and a list of documents, Rerank indexes the documents from most to least semantically relevant to the query" (current model rerank-v4.0-pro, multilingual) [cohere-rerank]; NVIDIA NeMo Retriever reranking NIMllama-nemotron-rerank-1b-v2, the Blueprint default [nvidia-rag-blueprint]; open-weight cross-encoders and the ColBERT late-interaction alternative: retrieval-rag-sota.md §5.3. Gotcha: rerank latency is linear in candidate count — wide cheap first stage (hundreds), narrow cross-encoder pass (top 50–100); rerank depth is a knob with a latency budget.

2.7 Generation with citations

What: answer strictly from retrieved context and attribute each claim to a source span, so answers are auditable. Menu: Anthropic Citations — "Ground Claude's responses in your source documents. Citations return the exact passages that support each claim, so you can verify answers and surface sources to your users" [anthropic-citations]; Nemotron 3 via NIM — the Blueprint's default generator nemotron-3-super-120b-a12b behind OpenAI-compatible APIs [nvidia-rag-blueprint]; any OpenAI-compatible endpoint slots into the same seam. Gotcha: citations requested only via prompt are unverified by construction — the model can fabricate the claim-to-source mapping; prefer structural citation APIs that return actual spans, and back-stop with a faithfulness metric in evals (§5.4).

2.8 Evals, observability, guardrails

What: the wrapper that makes the pipeline operable — measured quality, traced requests, policy enforcement. Menu (evals): RAGAS — retrieval-side Context Precision, Context Recall, Context Entities Recall, Noise Sensitivity; generation-side Faithfulness and Response Relevancy [ragas-metrics]. Menu (observability): Arize Phoenix — open-source "AI observability platform designed for experimentation, evaluation, and troubleshooting," built on OpenTelemetry/OpenInference [phoenix-github]; LangSmith — "full visibility into your LLM application: from individual traces to production-wide performance metrics" [langsmith-docs]. Menu (guardrails): NeMo Guardrails — "an open-source toolkit for easily adding programmable guardrails to LLM-based conversational systems" (input, dialog, retrieval, execution, output rails) [nemo-guardrails-github]; Llama Guard 3 — a safety classifier for "both LLM inputs (prompt classification) and… LLM responses (response classification)" across 14 MLCommons hazard categories [llama-guard-hf]. Gotcha: LLM-judged metrics inherit judge biases (position, verbosity, self-enhancement — paper-reviews.md §6.4); anchor suites with the deterministic retrieval metrics of retrieval-rag-sota.md §2.1 and keep a human-labeled golden set.


3. The agentic-RAG upgrade

3.1 Retrieval as a tool in a loop vs a fixed pipeline

The fixed pipeline of §2 executes retrieve → generate once, unconditionally. Agentic RAG hands the retriever to the model as a tool: the model decides whether to retrieve, judges what came back, reformulates queries, and iterates — the 2025–26 mainstream shift documented in retrieval-rag-sota.md §6.3 (research lineage — self-reflective/corrective pipelines — in its §6.1). When each wins:

  • Fixed pipeline: single-hop factual traffic at volume — one retrieval round means predictable latency and cost, cacheable stages, an auditable data path. If retrieval quality problems are systematic (bad chunking, missing hybrid), fix the pipeline: a loop on top of bad retrieval just burns tokens re-retrieving badly.
  • Agentic loop: multi-hop questions (evidence for step 2 depends on step 1's findings), heterogeneous sources the model must choose among, and vague queries needing rewriting. The price: extra LLM calls per round, and reliability now compounds per decision — the failure math of orchestration-algorithms-sota.md §7 applies to every added iteration.

3.2 The LangGraph shape of it

LangGraph's agentic-RAG tutorial fixes the canonical graph (node names verified against the tutorial) [langgraph-agentic-rag]:

  • generate_query_or_respond — entry LLM call; answers directly or emits a retriever tool call.
  • retrieve — executes the retriever tool against the vector store.
  • grade_documents — a structured-output LLM check on whether retrieved documents are relevant; a conditional edge, not a generation step.
  • rewrite_question — on a failed grade, reformulates the query and loops back to generate_query_or_respond.
  • generate_answer — on a passing grade, produces the final grounded response.

Two decision points shape control flow: after generate_query_or_respond, route on whether a tool call was made; after grade_documents, route on relevance (generate vs rewrite-and-retry) [langgraph-agentic-rag]. The pattern to name: grade-then-branch — a cheap judgment node deciding between "use it" and "try again," CRAG's corrective idea productized (retrieval-rag-sota.md §6.1). In production the loop gets a retry budget — ungated rewrite loops are unbounded token spend.


4. The NVIDIA mapping

Everything here was verified against NVIDIA repositories, docs, or pages on 2026-07-13.

4.1 The RAG Blueprint

github.com/NVIDIA-AI-Blueprints/rag, current release v2.6.0 (June 2026): a reference pipeline connecting the NIMs below, with multimodal extraction (text, tables, charts, infographics, audio), hybrid dense+sparse search, reranking, optional reflection and guardrails, multi-turn support, OpenAI-compatible APIs, and an agentic plan-and-execute mode for multi-hop queries [nvidia-rag-blueprint]. Default models: generation nemotron-3-super-120b-a12b, embedding llama-nemotron-embed-1b-v2, reranking llama-nemotron-rerank-1b-v2 [nvidia-rag-blueprint].

4.2 NeMo Retriever NIMs (extract, embed, rerank)

The NeMo Retriever Library is the ingestion-to-retrieval layer: "content and metadata extraction from various media types," pulling "text, tables, charts, infographics, and transcripts" out of enterprise documents, with nemotron_parse as a model-based PDF extraction path [nemo-retriever-docs]. The Blueprint wires extraction to specialized NIMs — Nemotron Page Elements, Nemotron Table Structure, Nemotron Graphic Elements, Nemotron OCR — before chunking, embedding (llama-nemotron-embed-1b-v2), and reranking (llama-nemotron-rerank-1b-v2) [nvidia-rag-blueprint].

4.3 Vector search: Elasticsearch default, Milvus on GPU

"The default is Elasticsearch. Another alternative is Milvus (GPU-accelerated)" — the Blueprint uses a "cuVS accelerated Vector Database" for "GPU-accelerated indexing and retrieval for low-latency performance" [nvidia-rag-blueprint]. Milvus's GPU support is "contributed by Nvidia RAPIDS team," with GPU_CAGRA ("a graph-based index optimized for GPUs"), GPU_IVF_FLAT, GPU_IVF_PQ, and GPU_BRUTE_FORCE [milvus-gpu-index]. Whiteboard sentence: CPU HNSW is the industry default; CAGRA is its GPU-native graph counterpart for high-QPS or fast-rebuild regimes (HNSW internals in retrieval-rag-sota.md §3.1).

4.4 Generation: Nemotron 3

The Blueprint generates with Nemotron 3 Super (nemotron-3-super-120b-a12b) [nvidia-rag-blueprint]. Family facts: "Nemotron 3 family of models utilize a hybrid Mamba-Transformer MoE architecture," with "Super and Ultra utiliz[ing] Latent MoE, a novel hardware-aware expert design" [nemotron3-research]. The announced lineup [nemotron3-newsroom]: Nano ("a small, 30-billion-parameter model that activates up to 3 billion parameters at a time"), Super ("approximately 100 billion parameters and up to 10 billion active per token"; the shipped id reads 120b-a12b), Ultra ("about 500 billion parameters and up to 50 billion active per token"); Nano shipped December 2025, Super/Ultra "expected to be available in the first half of 2026" — and Super is now the Blueprint default [nvidia-rag-blueprint]. Positioning: "Nemotron 3 Super excels at applications that require many collaborating agents to achieve complex tasks with low latency" [nemotron3-newsroom].

4.5 NeMo Guardrails around it

NeMo Guardrails is "an open-source toolkit for easily adding programmable guardrails to LLM-based conversational systems" [nemo-guardrails-github]. Its five rail categories map onto the §2 diagram: input rails ("can reject the input… or alter the input"), dialog rails, retrieval rails — "applied to the retrieved chunks in the case of a RAG (Retrieval Augmented Generation) scenario" — execution rails around tool calls, and output rails ("can reject the output… or alter it") [nemo-guardrails-github], authored in Colang, its Python-like dialogue-flow language. Retrieval rails are the architecturally interesting one for RAG: a policy checkpoint between retriever and prompt (§5.5).

4.6 AI-Q: the deep-research flavor

The AI-Q blueprint (github.com/NVIDIA-AI-Blueprints/aiq, v2.1.0, May 2026) is "an open reference example for building intelligent AI agents that connect to your enterprise data, reason using state-of-the-art models, and deliver trusted business insights" [aiq-github]. It builds a research assistant on LangChain Deep Agents plus the NVIDIA NeMo Agent Toolkit — "an open-source library for efficiently connecting and optimizing teams of AI agents," framework-agnostic across LangChain, LlamaIndex, CrewAI, Semantic Kernel, Google ADK [nemo-agent-toolkit] — with an orchestration node that classifies intent and sets research depth, a bounded shallow-research agent, and a deep-research agent with planning, iteration, and citation management over pluggable RAG backends [aiq-github]. Read it as §3's agentic loop scaled into orchestrated multi-agent research (fan-out economics: orchestration-algorithms-sota.md §5).

4.7 Stage → NVIDIA component table

Pipeline stage (§2) NVIDIA component Verified identifier
Parsing / extraction NeMo Retriever extraction (NRL) + extraction NIMs Nemotron Page Elements / Table Structure / Graphic Elements / OCR NIMs [nvidia-rag-blueprint] [nemo-retriever-docs]
Embedding NeMo Retriever embedding NIM llama-nemotron-embed-1b-v2 [nvidia-rag-blueprint]
Vector store Elasticsearch (default) / Milvus GPU cuVS; GPU_CAGRA [nvidia-rag-blueprint] [milvus-gpu-index]
Hybrid + fusion Blueprint hybrid dense+sparse search RAG Blueprint feature [nvidia-rag-blueprint]
Rerank NeMo Retriever reranking NIM llama-nemotron-rerank-1b-v2 [nvidia-rag-blueprint]
Generation Nemotron 3 Super NIM nemotron-3-super-120b-a12b [nvidia-rag-blueprint]
Guardrails NeMo Guardrails input/dialog/retrieval/execution/output rails [nemo-guardrails-github]
Agentic / deep research AI-Q blueprint + NeMo Agent Toolkit AI-Q v2.1.0; NAT [aiq-github] [nemo-agent-toolkit]
Whole pipeline RAG Blueprint v2.6.0 [nvidia-rag-blueprint]

5. Production concerns

5.1 Scale and cost heuristics

Do not re-derive these on the whiteboard — point at the tables: retrieval-rag-sota.md §4 owns store selection by corpus size and ops posture, and its §3.3 owns the memory arithmetic of quantization (binary/rotational quantization as the 2025–26 cost lever). The two levers specific to this brief: GPU indexing (CAGRA) trades hardware cost for QPS and index-build time (§4.3), and rerank depth (§2.6) is the per-query knob moving quality and latency together.

5.2 Freshness and re-indexing

Enterprise corpora churn, so ingestion is a continuously running pipeline, not a one-time script: upsert changed documents (delete-then-add at chunk level), carry updated_at metadata so retrieval can filter or decay stale chunks, and treat vector + lexical indexes as one atomic unit — a document present in one but not the other yields fused rankings that are quietly wrong. The expensive event is embedding-model change, which forces full re-embedding (§2.3); plan blue/green index swaps for it and re-run the §5.4 eval suite before cutover. (Engineering practice argued from the §2 architecture, not a cited benchmark.)

5.3 Multi-tenancy and ACLs on retrieval

The standard pattern is one shared index partitioned by metadata, not per-tenant deploys: Qdrant's guidance is "a single collection per embedding model with payload-based partitioning for different tenants and use cases," reserving separate collections for "a limited number of users and you need isolation" [qdrant-multitenancy]. Two hard rules follow from the architecture: enforce tenancy and document ACLs as mandatory retrieval-time filters — the generator cannot leak a document that was never retrieved — never as prompt instructions; and check ACLs at query time rather than baking them into the index, because permissions change faster than embeddings.

5.4 Evals in CI

Gate changes (prompt, chunking, embedder, index config) on a fixed eval suite the way code is gated on tests, measuring both layers separately: retrieval with classic IR metrics (recall@k, MRR, nDCG — formulas and a worked example in retrieval-rag-sota.md §2.1), and generation with RAGAS-style metrics — Context Precision/Recall and Noise Sensitivity on the retrieval side, Faithfulness and Response Relevancy on the generation side [ragas-metrics]. Wire tracing (Phoenix on OpenTelemetry/OpenInference [phoenix-github], or LangSmith [langsmith-docs]) so production failures can be replayed into the eval set — that loop, not the initial golden set, keeps evals honest. Judge caveats: paper-reviews.md §6.4; RAGAS/ARES methodology: retrieval-rag-sota.md §2.3.

5.5 Security posture: retrieval is an untrusted-content channel

OWASP's LLM01 names the channel: "Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files. The content may have in the external content data that when interpreted by the model, alters the behavior of the model in unintended or unexpected ways" [owasp-llm01]. In RAG that is not an edge case — it is the design: the pipeline's job is to fetch external content into the prompt, so every retrieved chunk is attacker-reachable input if anyone untrusted can write to the corpus (wikis, tickets, inbound email). Posture, mapped to this brief's boxes: sanitize and provenance-tag at ingestion (§2.1); apply retrieval rails — "applied to the retrieved chunks in the case of a RAG (Retrieval Augmented Generation) scenario" [nemo-guardrails-github] — between retriever and prompt; separate instructions from data in the prompt template and keep the generator least-privileged (an agentic-RAG loop with tools turns an injected chunk into an injected action); screen outputs with output rails or Llama Guard 3 [llama-guard-hf]; log full traces (§5.4) so incidents are reconstructable. The interview sentence: RAG converts a content-management problem into a prompt-injection attack surface — treat retrieved text with the trust you give user input, which is none.


Sources (references.yaml format; all URLs fetched and verified 2026-07-13)

nvidia-rag-blueprint: {title: "NVIDIA RAG Blueprint — NVIDIA-AI-Blueprints/rag (GitHub, v2.6.0; README defaults: nemotron-3-super-120b-a12b, llama-nemotron-embed-1b-v2, llama-nemotron-rerank-1b-v2)", url: "https://github.com/NVIDIA-AI-Blueprints/rag", accessed: "2026-07-13"}
nemo-retriever-docs: {title: "NeMo Retriever Extraction Overview — NVIDIA Documentation", url: "https://docs.nvidia.com/nemo/retriever/extraction/overview/", accessed: "2026-07-13"}
nemotron3-newsroom: {title: "NVIDIA Debuts Nemotron 3 Family of Open Models — NVIDIA Newsroom (Dec 2025)", url: "https://nvidianews.nvidia.com/news/nvidia-debuts-nemotron-3-family-of-open-models", accessed: "2026-07-13"}
nemotron3-research: {title: "NVIDIA Nemotron 3 Family of Models — NVIDIA Research (hybrid Mamba-Transformer MoE, Latent MoE)", url: "https://research.nvidia.com/labs/nemotron/Nemotron-3/", accessed: "2026-07-13"}
milvus-gpu-index: {title: "GPU Index — Milvus Documentation (GPU_CAGRA, GPU_IVF_FLAT, GPU_IVF_PQ, GPU_BRUTE_FORCE)", url: "https://milvus.io/docs/gpu_index.md", accessed: "2026-07-13"}
nemo-guardrails-github: {title: "NeMo Guardrails — NVIDIA (GitHub; input/dialog/retrieval/execution/output rails, Colang)", url: "https://github.com/NVIDIA/NeMo-Guardrails", accessed: "2026-07-13"}
aiq-github: {title: "AI-Q NVIDIA Blueprint — NVIDIA-AI-Blueprints/aiq (GitHub, v2.1.0; LangChain Deep Agents + NeMo Agent Toolkit)", url: "https://github.com/NVIDIA-AI-Blueprints/aiq", accessed: "2026-07-13"}
nemo-agent-toolkit: {title: "NVIDIA NeMo Agent Toolkit — NVIDIA (GitHub)", url: "https://github.com/NVIDIA/NeMo-Agent-Toolkit", accessed: "2026-07-13"}
langgraph-agentic-rag: {title: "Agentic RAG — LangGraph Documentation (generate_query_or_respond / retrieve / grade_documents / rewrite_question / generate_answer)", url: "https://docs.langchain.com/oss/python/langgraph/agentic-rag", accessed: "2026-07-13"}
docling-github: {title: "Docling — Get Your Documents Ready for Gen AI (GitHub, IBM Research / LF AI & Data)", url: "https://github.com/docling-project/docling", accessed: "2026-07-13"}
unstructured-github: {title: "Unstructured — Convert Documents to Structured Data (GitHub)", url: "https://github.com/Unstructured-IO/unstructured", accessed: "2026-07-13"}
llamaindex-node-parsers: {title: "Node Parser / Text Splitters — LlamaIndex Documentation", url: "https://developers.llamaindex.ai/python/framework/module_guides/loading/node_parsers/", accessed: "2026-07-13"}
openai-embeddings: {title: "Vector Embeddings Guide (text-embedding-3-small / -large) — OpenAI API Documentation", url: "https://developers.openai.com/api/docs/guides/embeddings", accessed: "2026-07-13"}
cohere-rerank: {title: "Rerank Overview (rerank-v4.0-pro) — Cohere Documentation", url: "https://docs.cohere.com/docs/rerank-overview", accessed: "2026-07-13"}
elastic-hybrid: {title: "Hybrid Search (full-text + vector, RRF) — Elasticsearch Documentation", url: "https://www.elastic.co/docs/solutions/search/hybrid-search", accessed: "2026-07-13"}
pgvector-github: {title: "pgvector — Open-Source Vector Similarity Search for Postgres (GitHub)", url: "https://github.com/pgvector/pgvector", accessed: "2026-07-13"}
qdrant-multitenancy: {title: "Multitenancy (Single Collection, Payload Partitioning) — Qdrant Documentation", url: "https://qdrant.tech/documentation/guides/multiple-partitions/", accessed: "2026-07-13"}
ragas-metrics: {title: "Available Metrics — Ragas Documentation (Context Precision/Recall, Faithfulness, Response Relevancy, Noise Sensitivity)", url: "https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/", accessed: "2026-07-13"}
phoenix-github: {title: "Arize Phoenix — AI Observability (GitHub; OpenTelemetry/OpenInference)", url: "https://github.com/Arize-ai/phoenix", accessed: "2026-07-13"}
langsmith-docs: {title: "LangSmith — Observability and Evals for LLM Applications (Documentation)", url: "https://docs.langchain.com/langsmith/home", accessed: "2026-07-13"}
llama-guard-hf: {title: "Llama Guard 3 8B — Model Card (Hugging Face; prompt/response safety classification, MLCommons hazards)", url: "https://huggingface.co/meta-llama/Llama-Guard-3-8B", accessed: "2026-07-13"}
owasp-llm01: {title: "LLM01:2025 Prompt Injection — OWASP Top 10 for LLM Applications", url: "https://genai.owasp.org/llmrisk/llm01-prompt-injection/", accessed: "2026-07-13"}
anthropic-citations: {title: "Citations — Claude Platform Documentation", url: "https://platform.claude.com/docs/en/build-with-claude/citations", accessed: "2026-07-13"}