Build a document assistant you can inspect
Trace context, retrieval and evidence, then build a local keyword-search baseline with a manual handoff to a model.
For readers who know basic Python and want to inspect how a document becomes evidence for an answer.
Before you begin
The code assumes Python 3 and terminal familiarity; this tour does not teach them. Bring a basic understanding of prompts and the evaluation sheet linked below.
5 min preparation. This separate preparation read is not included in the four-read time estimate. It also applies if you skip straight to the build.
What you will be able to explain
Locate a retrieval or context mistake, inspect the evidence sent to a model and assemble a small, traceable document-answering experiment.
Read it, then decide what to try.
You can read every explanation without running code. Paper exercises and supplied examples help you follow the mechanism; label work you have not executed accordingly.
Optional exercises: setup and scope
The final script selects passages and prints a request. You paste that request into a model interface you already have permission to use; it does not call a model automatically.
- Python 3 and a terminal for the code exercises.
- The token counter installs a package. The embedding exercise also downloads a model, so allow network access and storage in a disposable environment.
- The evidence-packet and final keyword-search scripts use only Python’s standard library; no vector database is needed.
Start at the beginning, or where you left off.
This tour selects four readings from AI basics. Use Next in this tour to stay on this route; the full syllabus remains available alongside it.
No progress is stored. Every reading stays open; bookmark an article’s tour link if you want to return to it.
Tokens and context windows: what your model actually receives
See what the request contains and what can be lost when context is shortened.
Look for this: Identify everything in the request, including the instruction or exception that must survive a shorter context.
Read step 1 →Embeddings and vector search: finding the right passage
Understand how similarity finds candidate passages, and why applicability is a separate question.
Look for this: Keep passage identity and version with the ranking. Query and documents must use compatible embeddings.
Read step 2 →How RAG connects an answer to its sources
Follow selected passages into the evidence packet and check which claims they support.
Look for this: Inspect the packet and its source IDs before judging the answer. Retrieval and generation can fail in different places.
Read step 3 →Build a small document assistant with inspectable evidence
Build an inspectable keyword-search baseline. It does not require a vector database; keep your questions and failures with the result.
Look for this: Keep the exact question, selected notes, printed request and verdict together so a wrong answer can be traced.
Read step 4 →
Can you follow an answer back to its evidence?
Use these questions to find your next useful read, not to award yourself a score.
- Explain why a similar passage may still be the wrong version or apply to a different situation. Revisit the explanation →
- Distinguish a missing retrieved passage from evidence lost while assembling context or ignored in the answer. Revisit the explanation →
- Follow one question through passage IDs, the printed request, the answer and its evaluation verdict. Revisit the explanation →
If you ran the build, keep the script, fictional notes, evaluation sheet and failures with your requests and results. Without model calls, call it a retrieval-only test, not an end-to-end result.
This is an inspectable baseline. It does not add persistence, user authentication or production monitoring.