Lee Siang Fong

Blog

LLM Roadmap for Beginners: Build a Document Assistant

Follow a beginner LLM roadmap by planning a small document assistant, learning retrieval and testing its answers before connecting real company data.

A practical LLM roadmap for beginners is to learn a few concepts, build one small application and test where it fails. A document assistant is a useful project because it connects prompts, source material, retrieval and answer review in one workflow.

Start with documents you created or are permitted to use. Keep real customer records and confidential company files out of the learning project until you understand the complete data flow.

Define a small learning project

Imagine a fictional office with an equipment guide, visitor instructions and a room-booking policy. Write those three documents yourself so there is no uncertainty about permission or correctness.

Your assistant's task is to answer questions from those documents and identify its source. It should say when the collection does not contain the answer.

That is a useful boundary. The first version does not need to book rooms, send messages or update a company system.

Stage 1: Learn the minimum vocabulary

An LLM, or large language model, generates language from its input. A prompt is the instruction and information you give it. Tokens are the units the model processes; they are not always complete words.

The context is the information available for a particular request. If your documents are not included in that context or made available through retrieval, the model cannot be assumed to know them.

You will also encounter embeddings: numerical representations used for comparing similarity. You do not need to start by training an embedding model. First understand what the search step is trying to find.

The vector database explainer provides a plain introduction to that part of the system.

Stage 2: Test a prompt with one document

Before adding search, give the model a short sample policy and ask a question whose answer is clearly stated. Request an answer based on the supplied policy and a reference to the relevant section.

Then ask something that is not in the policy. For example, ask whether visitors can park overnight when the document discusses only daytime access.

Inspect the result. Does it explain the missing information, or invent a likely rule? Write down the failure rather than immediately changing several parts of the prompt.

Try an ambiguous question too. A useful assistant may need to ask which office or equipment item the person means.

Stage 3: Learn the request and response boundary

Choose a learning setup you can operate. You might call a model through an approved hosted service or use a locally running model. Review the provider's current setup instructions and the features you enable.

For local experimentation, Ollama's documentation explains its configuration and operating options. Local and cloud features need different consideration; check what the selected request actually uses.

Whichever approach you choose, learn where the prompt goes, how errors are returned and how usage is limited. Keep credentials in the application's protected server-side environment rather than in browser code or a shared repository.

Use the same sample question repeatedly until you can distinguish an application error from an incorrect model answer.

Stage 4: Add retrieval for several documents

RAG, or retrieval-augmented generation, searches your collection for relevant material before the model answers. It is a way to supply evidence for a question without placing every document into every request.

Microsoft's RAG design guide describes a design and evaluation process for this pattern. For your learning project, focus on the boundary between the search results and the final answer.

Display the retrieved passages while testing. If the assistant gives the wrong room-booking rule, first inspect whether it retrieved the correct office policy.

The RAG and agents comparison explains how this differs from an agent that can choose tools or perform actions.

Stage 5: Build a small test set

Write expected results before running the assistant. You are checking behavior, not trying to make a demonstration look impressive.

Question type What you are testing
An answer stated in one document Basic retrieval and reading
A question using different wording Whether search finds the relevant passage
A question requiring two facts Whether the answer covers both
A question absent from the collection Whether the assistant admits the limitation
Two conflicting policy versions Whether the conflict is surfaced or handled by an approved rule
An instruction hidden inside a document Whether source content is treated as evidence rather than authorization

Keep the question, retrieved passages, answer and review notes together. Change one relevant part of the application, then repeat the same tests.

Stage 6: Review evidence and completeness separately

An answer may match a supplied passage but still omit an important condition. It may also contain a correct general explanation that does not answer the actual question.

Microsoft's RAG evaluation reference distinguishes retrieval, groundedness, relevance and completeness. Use those categories to make your review more specific.

Open every citation in your small test set. Check that the source supports the attached claim and that the version is the one you intended to use.

For the next step, follow the enterprise AI roadmap to connect technical testing with a real workflow owner and launch decision.

Stage 7: Add actions only when the project needs them

A document assistant can be useful without becoming an autonomous agent. If the next requirement is preparing a booking request, start by drafting it for a person to review.

Before connecting a tool, list the operations it permits. Remove permissions the project does not need. OWASP's excessive-agency guidance is a useful reference for this boundary.

A successful answer test does not establish that a write action is safe. Test permissions, approval and duplicate requests separately before allowing changes to an external system.

Finish with a project you can explain

At the end of this beginner LLM roadmap, you should be able to show where the evidence came from, why the answer was accepted and what happens when the assistant cannot answer.

Keep the scope modest. One document assistant with clear limitations teaches more than several unfinished agents whose behavior you cannot investigate.

Quick answers

Do I need to train a model first?

No. You can learn prompting, retrieval, application integration and evaluation using an existing model. Training is a separate topic that may not be needed for the project.

Do I need advanced mathematics?

It depends on your goal. Building a small application and understanding its boundaries is different from researching or training models.

Which model should I start with?

Choose one that fits your available hardware or approved service access, then evaluate it on your sample questions. There is no single best choice for every beginner project.

When can I connect real company documents?

After you have permission and understand storage, model requests, access controls and logging. Treat that as a separate deployment decision rather than a routine tutorial step.

Sources