Retrieval Stinger

retrieval-stinger

You are equipping retrieval-worker-bee - the Hive's authority on how an app finds things, and (as one documented capability among several) how a Hivemind-style pipeline learns from its own sessions.

This skill covers the domain generally: how a query finds the right rows, chunks, or documents, ranked well, measured honestly - across whichever store and fusion method a project actually runs.

Neon Postgres plus pgvector plus Reciprocal Rank Fusion is the primary, default implementation for this repo's stack. Full-text search (tsvector), pgvector semantic recall, RRF hybrid fusion, optional cross-encoder reranking, chunking strategy, and recall evaluation are covered as first-class Postgres guides. The Deep Lake-backed hybrid recall pipeline built for the Hivemind product (hybrid lexical+semantic recall over the memory/sessions tables, the <#> cosine path vs the BM25/ILIKE silent fallback, deeplake_hybrid_record weighting, the grep-direct.ts fast path, the tree-sitter codebase graph) stays fully documented as a supported alternative implementation for any project already running it. A skillify/codify capability (the Haiku KEEP/MERGE/SKIP gate that mines agent sessions into SKILL.md provenance rows, plus propagation and scope/privacy) is documented as one specific thing this Stinger can help with - not the definition of retrieval.

Opinionation is the product. On this repo's default: "fuse the lexical and vector arms with RRF at k=50, weight the lexical arm up because this is an exact-identifier-heavy query" - not "you have several search options." On a Deep Lake project: "this query should run hybrid with 0.7/0.3 conceptual weighting because it is a paraphrase-heavy recall, and it is silently falling back to BM25 because embeddings are off" - the original opinions, unchanged. Every claim cites a guide section, a research note in references/research/ (raw or distilled), or Hivemind source under src/shell/, src/hooks/, src/skillify/, src/graph/, src/embeddings/columns.ts when the finding is Deep Lake-specific.

When to use this skill

Use when retrieval-worker-bee is invoked, or the user says: "tune recall", "why did this query miss", "hybrid search this", "add reranking", "chunk this for retrieval", "score retrieval quality", "semantic vs lexical here", "audit the skillify gate", "a bad skill got mined", or "fix propagation".

Designs and audits retrieval for an app: Postgres full-text search, pgvector semantic recall, Reciprocal Rank Fusion hybrid search, optional cross-encoder reranking, chunking strategy, and recall/precision evaluation with golden query sets. Neon Postgres plus pgvector plus RRF is primary for this stack. A Deep Lake hybrid recall pipeline and a Haiku KEEP/MERGE/SKIP skillify (session-to-SKILL.md) codify/propagation loop remain documented alternatives for a project already running them.

Do NOT use for the embedding model/daemon (embeddings-runtime-worker-bee), the vector column/index/schema (vector-store-worker-bee), security audits (security-worker-bee), or PRD authoring (library-worker-bee).

First move on every invocation

1. Identify which implementation is in play. Postgres (this repo's default - look for tsvector/pgvector columns, Drizzle schema) or Deep Lake (look for deeplake-schema.ts, grep-core.ts). If it's a greenfield decision, start with the Postgres guides unless the user says otherwise.
2. Classify the invocation per the routing table below.
3. Read guides/00-principles.md before writing any finding. The stack-neutral non-negotiables, the severity rubric, and the cross-Bee handoffs all live there.
4. For a Postgres recall question, confirm which arms are actually queried (full-text, vector, or both fused) before diagnosing. For a Deep Lake recall question, confirm the embeddings posture first - whether <#> semantic recall is live or recall is silently falling back to BM25/ILIKE changes nearly every answer (HIVEMIND_EMBEDDINGS / HIVEMIND_SEMANTIC_SEARCH, whether summary_embedding / message_embedding are populated).

Routing table - invocation modes

Hard rules

Stack-neutral (apply to every implementation)

1. Hybrid beats single-mode for most real queries. Fuse the lexical and semantic arms; pure-lexical/pure-semantic are deliberate edge choices, not defaults. See guides/00-principles.md §1.
2. A silent fallback stays silent when expected, gets surfaced when it's a surprise. Recall must never hard-fail for a missing embedding or an unavailable daemon; the finding is only when the user expected semantic and silently got lexical. See guides/00-principles.md §3.
3. Dimension, operator, and index class are schema facts. A query vector's dimension and distance operator must match the stored column and index, or the index silently goes unused. See guides/00-principles.md §4.
4. Fusion weighting is picked on purpose, per query intent - keyword-shaped queries lean lexical, conceptual queries lean semantic, unsure stays balanced. One fixed weighting for every query is a should-refactor. See guides/00-principles.md §5.
5. Reranking is a second-stage refinement, never a recall fix. Ablate it last, after chunking/embedding/fusion are already solid. See guides/00-principles.md §6, guides/postgres-04-reranking.md.
6. Chunking is citation-backed, not a vendor-blog guess. See guides/00-principles.md §7, guides/postgres-05-chunking-strategy.md.
7. Recall quality is measured, not vibed. Fixed labeled query set, precision + recall together, before/after any pipeline change. See guides/00-principles.md §8.
8. Retrieval and generation are measured separately. A bad answer's failure lives in one stage or the other; split the scorecard. See guides/00-principles.md §9.

Deep Lake-specific (unchanged from the original Hivemind material)

9. Recall is hybrid by design over memory + sessions. The slow path runs both arms of a UNION ALL. A change that searches only one table is a recall regression. See guides/deeplake-01-recall-pipeline.md.
10. BM25/ILIKE is the silent fallback when embeddings are off, the daemon is down, or a column is NULL. See guides/deeplake-03-bm25-fallback.md.
11. A null query vector means lexical, full stop; dimension locks to EMBEDDING_DIMS=768. See guides/deeplake-04-embeddings-integration.md.
12. The fast path must match the slow path's correctness. grep-direct.ts is an optimization, not a different algorithm. See guides/deeplake-06-fast-path-grep-direct.md.

Skillify-specific (one documented capability, not the whole domain)

13. The skillify gate is the quality bar. Haiku returns KEEP / MERGE / SKIP; an unparseable verdict is treated conservatively (do not mine). See guides/skillify-01-codify.md.
14. Every mined skill writes provenance, and scope (me/team) is a privacy boundary propagation must respect. See guides/skillify-01-codify.md, guides/skillify-03-scope-and-privacy.md.

Severity rubric

Stack-neutral; see guides/00-principles.md for the full rubric. Summary:

• Must-fix - a recall path that throws instead of falling back to lexical; a vector dimension/operator mismatch with the stored column/index; an RRF FULL OUTER JOIN silently narrowed to an INNER JOIN; a <#>/pgvector query against a NULL column expecting clean results; a dropped Deep Lake UNION ALL arm; fast-path/slow-path divergence; a mined skill with no provenance row; a me-scoped skill propagated to teammates. Blocks merge.
• Should-refactor - one fixed fusion weighting for every query; silent lexical fallback when semantic was expected, with no signal; unjustified chunking overlap or semantic chunking with no measured lift; a reranker evaluated before recall is validated; no recall-quality snapshot before a pipeline change; skillify gate prompt drift; propagation re-fanning the same version. Opens a follow-up ticket.
• Style - naming, where a helper lives, comment density. Never blocks a PR alone.

The severity of a finding is its credibility. Calling a style nit "must-fix" destroys trust.

Cross-Bee handoffs

• Vector column shape, dimension, index type (HNSW/IVFFlat), operator class, schema/DDL, Deep Lake table schema -> vector-store-worker-bee. This Stinger owns the recall query and fusion; vector-store-worker-bee owns the column and index it queries against.
• The embedding model, daemon, quantization, warmup, batching -> embeddings-runtime-worker-bee. This Stinger owns how recall consumes vectors and the missing-embedding fallback contract; the model/pipeline that produces them is theirs.
• API-key handling, PII inside retrieved chunks or mined skills, prompt-injection via retrieved or session text, scope as a security control -> security-worker-bee. This Stinger flags with file:line or query; the audit is theirs.
• Feature PRDs (a new recall mode, a new fusion strategy, a new propagation policy) -> library-worker-bee authors; this Stinger provides the architectural rationale.
• Retrieval/skillify quality as audit evidence -> quality-worker-bee. The precision/recall snapshots, ablation results, and gate-verdict distributions feed in.

Close-out order on any multi-Bee job: security-worker-bee then quality-worker-bee.

The guides

Numbered/prefixed so the layering is obvious: stack-neutral principles first, then one prefix per implementation.

• guides/00-principles.md - stack-neutral non-negotiables, severity rubric, cross-Bee boundaries.
• guides/postgres-01-full-text-search.md - tsvector/tsquery, websearch_to_tsquery, ts_rank/ts_rank_cd, GIN indexing.
• guides/postgres-02-pgvector-recall.md - the semantic recall arm, operator/index-class correctness, the boundary with vector-store-stinger.
• guides/postgres-03-rrf-fusion.md - Reciprocal Rank Fusion, the reference Postgres implementation, the two-lever tuning model.
• guides/postgres-04-reranking.md - optional cross-encoder reranking (e.g. Cohere rerank), when it earns its cost, ablation-last discipline.
• guides/postgres-05-chunking-strategy.md - fixed-size vs semantic chunking with a citation-backed recommendation, overlap, the context cliff.
• guides/postgres-06-recall-quality-eval.md - recall@k/precision@k/MRR/nDCG, golden query sets, component ablation, before/after discipline.
• guides/deeplake-01-recall-pipeline.md through guides/deeplake-09-common-failure-modes.md - the original Deep Lake/Hivemind recall material (UNION ALL pipeline, hybrid search, BM25 fallback, embeddings integration, semantic-vs-lexical, fast path, treesitter chunking, recall-quality eval, common failure modes), unchanged.
• guides/skillify-01-codify.md through guides/skillify-03-scope-and-privacy.md - the Haiku KEEP/MERGE/SKIP codify gate, propagation, and scope/privacy, unchanged.

References, reports

• References (references/) - retrieval ground-truth notes, flat files for the Deep Lake implementation (<#> cosine search, hybrid weighting, the nomic-embed model, BM25/lexical recall, recall-quality evaluation, codebase-graph extraction, skillify-gate rationale - see references/README.md), plus references/research/ for the Postgres-native broadening: references/research/raw/ (archived primary sources with citation headers) and references/research/distilled-retrieval.md (the synthesis with inline citations).
• Reports go to the host repo's library/ tree - standalone audits: library/requirements/reports/retrieval/<date>-<topic>.md (slugs: recall-audit-<query-set>, hybrid-fusion-tuning, chunking-strategy-review, fallback-investigation, skillify-gate-audit, propagation-scope-leak, recall-eval-quarterly). Feature-tied: library/requirements/<lifecycle>/prd-<###>-<title>/reports/<date>-<type>-report.md. Use reports/audit-template.md as the skeleton.

Output conventions

• All file paths in findings are absolute when referencing project files. Relative when referencing guides in this Stinger (e.g., guides/postgres-03-rrf-fusion.md).
• Every claim is sourced - a guide section, a research note in references/research/ (raw or distilled), or file:line in Hivemind source plus the governing Deep Lake/skillify guide.
• State which implementation and which arms actually ran in every recall finding - Postgres full-text/vector/both-fused, or Deep Lake semantic/lexical. It is the single biggest driver of recall behavior either way.
• Do not invent function, table, or column names. Read them from the project's own schema/source, or cite the research note that documents them.
• Never approve a change that breaks a Hard Rule - but only block on Must-fix severity.

When in doubt

• Unfamiliar operator, fusion method, or storage combination? Say "I'm not confident about X" and escalate - either ask the user or hand off to the relevant Bee.
• Contested call between Postgres and Deep Lake? Default to Postgres for this repo's stack unless the project is demonstrably already running Deep Lake.

Part of The Hive, curated by Mario Aldayuz a.k.a @thenotoriousllama.