Finish the project: a demonstrable assistant and an interview story

Build the smallest complete demonstration

Use the three fictional policies, your ingestion records, a retrieval path, an answer contract, source validation, and the read-only order tool. Start with the offline reference lab available from the course directory. It demonstrates retrieval, conservative abstention, and authorization without an API key. It is a transparent lexical baseline, not an LLM or vector-search implementation.

Replace one boundary at a time if you want the full GenAI version: use real embeddings for retrieval, the structured-output example for generation, and a bounded tool loop for mixed questions. Preserve the offline checks so you can tell which behavior changed. Do not describe a mock or untested integration as a deployed production system.

Show five cases in a short walkthrough

First ask about an ordinary unopened return and inspect the cited source. Then ask about clearance items and check the exclusion. Ask about bank refund timing and expect insufficient evidence. Look up an owned order and then attempt another user's order. Finally, simulate a failed dependency and show the limited response.

For each case, show the input, selected evidence or tool result, final behavior, and relevant check. A screen recording is useful, but keep a reproducible text transcript and setup instructions too. Use fictional data throughout. The demonstration should reveal why the system made a permitted decision without exposing credentials or private logs.

Prepare answers that connect concepts to decisions

If asked “Why RAG?”, explain that policy facts must be updateable and attributable, then show a source revision. If asked “Why this vector database?”, describe the filtering, update, and operations requirements you measured. If asked “How do you reduce hallucinations?”, identify evidence checks, unsupported-case handling, and the remaining limitations instead of promising elimination.

For “How do you evaluate?”, show labeled cases and separate retrieval from answer quality. For “What does MCP add?”, distinguish the connection protocol from authorization. For “When would you fine-tune?”, name a stable behavioral failure and the baseline it must beat. For “How does this scale?”, discuss bottlenecks, quotas, caching scope, and operational measurements before listing cloud products.

Keep a compact concept reference

Embeddings represent inputs for comparison. A vector index retrieves nearby representations. RAG supplies selected evidence to generation. Reranking orders an existing candidate set. A tool request proposes an operation; application code authorizes and executes it. Memory stores selected state with an owner and lifecycle. Fine-tuning adapts model behavior through training. Evaluation tests explicit claims about system performance.

These definitions become useful when paired with tradeoffs. Larger chunks may preserve context but introduce noise. More candidates may improve recall while increasing cost. More memory may aid continuity while increasing staleness and privacy risks. Explain the decision you made, the evidence behind it, and what would make you change it.

Extend the project with a clear next question

A document assistant, internal knowledge search, product support tool, or research-paper summarizer can reuse parts of this architecture. Choose an extension with a measurable question: does hybrid retrieval improve exact product-code queries, or does a checked conversation summary preserve follow-up accuracy?

Publish your architecture, setup steps, test cases, observed results, known limitations, and one failed experiment. Honest limitations make the work easier to assess. Do not manufacture usage numbers or claim that a local lab meets production or regulatory requirements. A small system whose behavior you can explain is a strong foundation for the next project.

References and further reading

Use these primary references for deeper study and current API details. Examples in this lesson use fictional Northstar data.

• Research paper — 2005.11401
• MCP architecture — architecture