santifer/cv-santiago: The CV That Behaves Like a Production AI System
An interactive portfolio that turns a personal resume into a live demo of agentic RAG, voice latency control, security defenses, and eval-driven LLMOps.
- This repo turns a resume into proof by embedding the same AI engineering discipline it claims to have.
- The chatbot is a real system with hybrid retrieval, reranking, observability, and security layers, not a decorative wrapper.
- Voice mode changes the architecture because latency, not just accuracy, becomes the controlling constraint.
- The private ops loop closes the gap between production traces, evaluation, and test generation, which is what makes the project feel like software instead of a page.
A CV That Proves Itself
Most portfolios describe capability. santifer/cv-santiago does something sharper: it demonstrates capability in the product itself. The CV is not the point. It is the front door to a system that can be queried, stress-tested, traced, and defended like a real AI application.
A production-grade interactive portfolio that **demonstrates the skills it describes**
That inversion matters. A static CV can list RAG, voice, observability, and security. It cannot show whether those claims survive a hostile prompt, a slow retrieval path, or a real evaluation gate. This repo answers those questions by making the portfolio itself the test harness.
Why a Static Portfolio Was the Wrong Shape
A conventional portfolio optimizes for presentation. This one optimizes for evidence. It is built for the question hiring managers and technical peers actually care about: can this person ship an AI product that behaves well under pressure?
| Capability | Static portfolio | Basic chatbot embed | santifer/cv-santiago | Real LLMOps app |
|---|---|---|---|---|
| Interactivity | Read-only pages | Single chat box | Text and voice, with portfolio context | Multi-surface product experience |
| Retrieval quality | None | Usually none or naive | Hybrid search with reranking | Retrieval tuned through traces and evals |
| Safety layers | Manual content control | Minimal filtering | Multi-layer defense against injection | Defense-in-depth with monitoring |
| Observability | Page analytics | Often absent | Langfuse traces, costs, and ops views | Production telemetry and debugging |
| Eval loop | None | Rare | 71 automated evals and CI gating | Continuous quality checks |
| Forkability | Looks polished | Sometimes copyable | Fully open and inspectable | Usually internal and complex |
The point is not that this repo is bigger. It is that the extra machinery is aligned with proof. Every added layer answers a failure mode that a normal portfolio never exposes.
The Chatbot Is a Stack, Not a Widget
The chatbot is the core exhibit, but it is not a toy. It starts with a tool decision, then moves through hybrid retrieval, reranking, generation, tracing, and cost accounting. The architecture is split so text and voice can share business logic while still taking different paths when constraints differ.
That duality is the real product insight. Text mode can afford a richer reasoning chain. Voice mode cannot, because human speech punishes hesitation. So the system adapts, not just by swapping output formats, but by changing how much work it does before it speaks.
// Pseudocode for the latency-aware voice path
if (mode === 'voice') {
const results = await searchDocuments(query, { timeout: 1500 });
if (results.timedOut) {
return fallbackToRawChunks(results.partialContext);
}
return generateWithRerank(results.context);
}
return generateWithRerank(await searchDocuments(query));The Voice Mode Has a Different Constraint: Time
This is where the project stops feeling like a chatbot and starts feeling like an engineered interface. Voice interaction is governed by latency budgets, so the system is willing to sacrifice depth when retrieval takes too long. That is a product decision expressed as architecture.
In practice, that means the pipeline can degrade gracefully. Instead of waiting for the perfect answer and missing the conversational moment, it returns something usable, then keeps the experience alive. That choice is subtle, and it is exactly the kind of trade-off strong AI product teams have to make.
Security Is Built In, Not Added Later
The security story is unusually serious for a personal portfolio. The README describes a 6-layer defense, and the implementation reflects the same mindset: detect risky intent, protect system instructions, watch for canary leaks, and alert when something looks adversarial.
AI Chatbot "Santi" — Text (Claude Sonnet) + Voice (OpenAI Realtime API). Responds in first person as Santiago. Agentic RAG with hybrid search (pgvector + BM25) and Haiku reranking
This matters because prompt injection is not a theoretical risk here. A public-facing portfolio chatbot invites curious, weird, and sometimes hostile inputs. Treating defense as part of the feature set, rather than an afterthought, is what makes the repo credible as a production demo.
LLMOps, but for One Person
The private ops layer is the quietest part of the project and maybe the most important. It tracks traces, costs, performance, and evaluation signals so the system can be inspected like a product in active use. That is the difference between a flashy prototype and an artifact of engineering discipline.
| Ops primitive | What it does | Why it matters here |
|---|---|---|
| Tracing | Captures steps across tool use, retrieval, and generation | Makes failures inspectable instead of mystical |
| Cost accounting | Estimates the dollar cost of messages by model | Forces the team to see the economics of every interaction |
| Evals | Checks factuality, persona, safety, and retrieval quality | Turns quality into a gate, not a vibe |
| Closed loop | Can turn weak production traces into new tests | Lets the system improve from real failure modes |
The closed loop is the thesis-level move. When traces can generate tests, the portfolio is no longer just documenting skill. It is manufacturing more skill evidence over time. That is unusually mature for a personal site, and it is why the repo feels more like a product team in miniature.
What Makes It Different From Other Portfolios
Compared with static portfolio generators, this repo has state, memory, and behavior. Compared with a basic chatbot embed, it has retrieval quality, safety, observability, and a fallback strategy. Compared with no-code chatbot platforms, it is open, inspectable, and forkable. Compared with most LLMOps demos, it has a real user-facing purpose.
| Question | Most portfolios | cv-santiago |
|---|---|---|
| Does it prove skill or only list it? | Mostly lists it | It proves it through the app itself |
| Can it survive adversarial input? | Rarely tested | Built with layered defenses |
| Can it explain its own answers? | Not really | Yes, through retrieval and tracing |
| Can it adapt to voice latency? | Usually not applicable | Yes, with a fast fallback path |
| Can you inspect the system end to end? | Usually no | Yes, from UI to ops to evals |
That is the real differentiator. The repo is not trying to be the prettiest CV on the internet. It is trying to be the most believable evidence that the builder can design, ship, and operate an AI system.
