all projects
AIRAGLangChainpgvectorEvaluationClaude

Portfolio / Personal · Product Manager · AI Engineering · 2026

Hive

A production-grade RAG knowledge assistant, built to prove the AI engineering, not just use it

Every RAG system is a product decision, not just a technical one.

Hive

outcomes

  • Full ingest → embed → retrieve → generate pipeline shipped (Phase 2), running on pgvector + LangChain 0.3+
  • Every query scored live for faithfulness and relevance with RAGAs, using claude-haiku-4-5 as the judge model
  • query_log in Postgres records token counts and computed USD cost per query, next to the eval score
  • Prompt versions (v1 vs v2) logged per query, so answer quality can be compared across prompts after the fact
  • Context budget enforced in config: chunk_size 1000 chars, K=4 retrieval, not left to chance
  • 6 teaching notebooks, one per pipeline stage, each ending in a PM takeaway

pm skills

RAG architecture scopingeval framework designguardrails as requirementscontext-window budget managementphased roadmapcost-per-query instrumentationprompt version management

Problem

Non-technical teams drown in scattered docs across PDFs, Notion, and Confluence. Every time someone cannot find an answer, they interrupt a subject-matter expert. That is an invisible tax on institutional knowledge. Ask an LLM directly and it hallucinates, confidently, in the exact situations where a wrong answer costs the most.

The harder problem sits underneath: "we built a RAG system" is not a finish line. Without an eval strategy you cannot tell whether a change made answers better or worse. Without guardrails the system fabricates. Without cost instrumentation you find out what it costs from the invoice.

What I Built

Hive is a RAG pipeline that ingests documents, embeds them into a vector database, and answers questions in plain language with source citations. If the knowledge base does not contain the answer, it says so instead of guessing.

What makes it a portfolio artifact rather than a demo is everything around the pipeline. Every answer is scored the moment it is produced. Every query logs what it cost. Every architectural decision lives in a notebook that explains the tradeoff and closes with what a PM should take away from it.

I designed the eval strategy, the guardrail philosophy, and the phased roadmap before writing a line of pipeline code.

IngestPDF → chunksEmbedembedding-3-smallVector storepgvectorRetrieveK = 4Generateclaude-sonnet-4-6Cited answerwith sources
Hive's RAG pipeline. Every stage is a config-enforced contract, not an ad-hoc call.

Approach

Eval before features. Faithfulness asks whether the answer stuck to the retrieved context. Relevance asks whether it actually addressed the question. Both are scored live per query with RAGAs, judged by claude-haiku-4-5 because a fast, cheap judge that runs on every query beats a perfect judge that runs never.

compare versions, then tunePrompt vNqa_prompt.yamlCited answerFaithfulnessjudge: haiku-4-5Relevancejudge: haiku-4-5query_logscore · USD · version
Every answer is scored and priced the moment it is produced. The scores drive prompt iteration.

Guardrails as requirements, not polish. The prompt spec (prompts/qa_prompt.yaml, versioned) carries an explicit contract: answer only from retrieved context, and if the context does not support an answer, decline. The refusal path is a designed feature, tested, not an edge case.

yesnoContexttop-K chunksSupports it?guardrailAnswercite sourcesDecline"not in the KB"
The refusal path is a designed branch, tested like any other feature.

Context budget as a config, not a hope. Chunk size and retrieval K are set explicitly and enforced, so the window the model sees is a known quantity rather than whatever the last change happened to produce.

Cost is a first-class metric. query_log records token counts and computed USD cost per query, stored right next to the faithfulness and relevance scores, so quality and cost are read together.

Prompt versioning built in. PROMPT_VERSION selects which prompt spec loads, and every query records the version it ran. v2 is a terser prompt tested against v1 to see whether brevity hurts faithfulness. The data to answer that is being collected by design.

The 8 AI Engineering Fundamentals

#FundamentalWhere it lives in HiveStatus
1LLM APIs & prompt designVersioned prompt spec in prompts/qa_prompt.yamlDone
2RAGCore pipeline: ingest → embed → retrieve → generateDone
3Embeddings & vector DBsOpenAI text-embedding-3-small into pgvectorDone
4Agent orchestrationMulti-agent query decompositionRoadmap
5Evaluation & observabilityLive RAGAs scoring plus query_log cost trackingDone
6Guardrails & output validationPrompt-level guardrail now, hard validation nextDone (Phase 1 scope)
7Context-window managementConfig-enforced chunk size and retrieval KDone
8Fine-tuning vs promptingPrompt-only now, decision framework laterRoadmap

Being explicit about what is not built yet is the credibility. A roadmap with honest exit gates is a PM artifact. A pile of half-finished features is not.

Stack

LangChain 0.3+ for orchestration, Claude claude-sonnet-4-6 for generation, OpenAI text-embedding-3-small for embeddings, pgvector on Postgres for the vector store, RAGAs for evaluation, Streamlit for the UI, Docker for the dev environment, Jupyter notebooks as the learning layer.

Outcome

Phase 2 is shipped and running: the full pipeline, live eval on every query, and cost logging. Phases 3 and 4 (hard guardrail validation, multi-agent decomposition, the fine-tune decision) are scoped with exit gates. Built to demonstrate the difference between "I use AI" and "I can scope, build, and measure an AI system."