Production RAG, from Scratch: A Document Chatbot Tutorial

• RAG
• Hybrid search
• Reranking
• Vector databases
• Embeddings
• Query rewriting
• Semantic caching
• RAG evaluation
• Remotion
• three.js
• Qwen3-TTS

What problem this series solves

Building a document chatbot is easy now. Upload a PDF to a ready-made tool, ask a question, get a good answer. The hard part starts after the demo: a wrong answer with full confidence, the wrong clause, a table read as random numbers, a follow-up question that gets an unrelated reply, and a bill that keeps growing.

The dangerous part is that a wrong answer sounds exactly like a right one. In a real company, one confident wrong answer about a notice period can turn into an angry employee, a legal problem, or a client who stops trusting your product.

This series is for developers and technical founders who want to understand why a RAG chatbot fails and which part of the pipeline to fix. It is also for anyone who has to decide whether a ready-made tool is enough for their company, or what to ask for when they hire someone to build one. I kept it in plain English, with one example the whole way through, and each part opens with a short recap so you can start anywhere.

The running example

Every part uses the same case: a 1000 page company handbook, and one question, "What is my notice period?" The answer sits in clause 14.3 on page 412, and then comes the follow-up, "and what about contractors?"

One example keeps the series simple. You see the same question go wrong in different ways, and each time the fix lives in a different part of the system.

How the pipeline works

A RAG system (retrieval augmented generation) is eight steps. Think of a librarian setting up a new library: read every book, cut the content into small cards, give each card an address by meaning, and file the cards where they can be found fast. Then, when a question arrives, pull the right cards, put the best on top, write the answer from them, and check it. The same map is shown in every video, with the current block highlighted.

Parse → Chunk → Embed → Store → Retrieve → Rerank → Generate → Validate

• Parse: read the document properly, including tables and scanned pages.
• Chunk: cut it into small pieces, ideally along the document's own structure.
• Embed: turn each chunk into numbers that capture its meaning.
• Store: keep the text, the numbers and the metadata (page, section, version) in a vector database.
• Retrieve: find candidate chunks with meaning search, keyword search or both.
• Rerank: a second model reads the question and each candidate together and picks the best few.
• Generate: the language model writes the answer from those chunks only.
• Validate: check the answer against its sources before the user sees it.

Three topics cut across all eight blocks: memory (a chat that keeps growing), speed and cost. They are the subject of the last part.

Which failure lives in which box

The most useful habit the series teaches is to ask, when an answer is wrong, which box broke:

• A table answered with the wrong number: parsing. The table was read as flat text and the rows lost their columns.
• Clause 14.2 returned instead of 14.3: retrieval. Search matched the meaning and ignored the number.
• "Ninety days, or sixty if you are on probation" when the text never mentions probation: generation. The model added a detail that is not in the document.
• A follow-up that returns an unrelated answer: memory. Search never saw the earlier question.
• "Can I prove it?" and "will it still be right after the handbook is updated?": citation, validation and evaluation.

Where to go next: Part 1 gives the map, Part 2 covers Parse to Store, Part 3 covers Retrieve and Rerank, Part 4 covers Generate and Validate, and Part 5 covers memory, speed and cost, and ends with the whole map put together.

Part 1: Why a document chatbot gives wrong answers

A chatbot answers "sixty days" with full confidence. The real answer is ninety, and it is on page 412. Part 1 sets the foundation for the whole series: why a language model does not know your documents, what RAG is, the eight-step map above, and how to think about ready-made tools before you pick one.

Why the model does not know your documents

A language model is like a brilliant new employee on their first day. It has read half the internet and can write, summarise and explain almost anything, but it has never opened your handbook. So when you ask about your notice period, it does what a nervous new employee does: it guesses what notice periods usually look like.

The obvious fix is to paste the whole handbook into the chat. But a thousand pages is a lot of text. Many models cannot take that much at once, the ones that can charge you for every page on every question, and one key line buried in the middle is still easy to miss.

What RAG is

RAG is an open book exam. The student does not memorise the textbook. When a question comes, they flip to the right page, read the relevant paragraph and write the answer from it. A RAG system searches your documents, picks the few passages that matter, and puts them in front of the model with one instruction: answer using this. The model never needs to know a thousand pages. It needs to read the right three or four paragraphs, which means the whole game is finding them.

Ready-made tools: RAGFlow and EuroRAG

Eight steps can mean weeks of work, but ready-made tools package the whole pipeline. Part 1 looks at two with very different philosophies, on purpose:

• RAGFlow is an open source platform. Its belief is that if you do not understand the document, nothing after that matters, so it puts serious effort into ingestion and many file formats. It combines meaning search with keyword search, reranks the results, and has a visual builder for agents. You can try it on its cloud (which has a free plan) or run it yourself.
• EuroRAG is a paid, self-hosted boilerplate for developers. Think of a house frame with the plumbing and wiring done, which you finish for your own client. You clone it, fill in a settings file and start it with one docker compose command. Parsing uses Docling, with OCR for scanned pages, and the focus is privacy: it can run fully local or with European model providers, and it ships GDPR tools such as data deletion and audit logs.

Which one should you pick? It depends on one honest question: who is going to own this system? A platform suits you or a non-technical team who want to upload documents and get answers with little setup. A boilerplate suits a developer building chatbots for clients where privacy rules matter. Either way, you are standing on someone else's defaults for chunk sizes, search settings and prompts, chosen for an average document. Your document is not average. Check pricing and licences on the tools' own sites before you use either.

Key takeaways

• A model has never read your handbook, so it guesses.
• Pasting the whole handbook into the chat is slow and costly, and one key line in the middle is easy to miss.
• RAG hands the model only the few passages that matter, so the real job is finding those passages.
• When an answer is wrong, a ready-made tool cannot tell you why. Knowing the eight boxes can.

Part 2: Parsing, chunking, embeddings and vector databases

Most failures happen before the first question: a table read as random numbers, a heading glued to the wrong paragraph, a clause cut in half. After that, it does not matter how smart the model is, because it is answering from damaged material. Part 2 opens the first half of the pipeline, where a thousand pages become something a machine can search.

Parsing: a PDF is not text

A PDF is closer to a set of instructions for a printer than to a text document. A simple tool can read a two-column page straight across and mix sentences from both columns, repeat the company name from the header on every page, or put page numbers in the middle of a sentence. To a human the page looks perfect. To the machine it is a scrambled puzzle.

Tables are where it falls apart. Some tools read a table column by column: first the grades A, B, C, then the numbers twelve, eighteen, twenty-four. The link between a grade and its number is gone, so a question about grade B becomes a guess. Sometimes the guess is right, the tests pass, and then it fails in front of a real employee.

The fix is a layout-aware parser, such as Docling, which finds headings, columns and tables and keeps each table as rows and columns with its headers. Scanned pages need OCR first, and OCR can misread a number, so check that too. The rule that matters most: open the parsed output and read it yourself. If it looks broken to you, the model gets it broken too.

Metadata: save where every piece came from

While you parse, keep the page number, section title, document name and the date it was last updated. Later this is what lets the chatbot say "page 412, section 14", and what lets you ignore the old version when HR uploads a new one. If you throw it away now, you cannot get it back without parsing everything again.

Chunking: four methods and when to use each

A chunk is the smallest thing your system can ever find. If an answer is split across two chunks, the system may find one half and miss the other. There is no magic size: too big and one chunk covers five topics so it matches everything weakly, too small and a sentence like "this applies to all permanent employees" loses the paragraph that explains what "this" is. You find the right size by testing.

• Hard cuts: cut every few hundred words regardless of content. Fast and cheap, but it can slice your most important line in half. Fine for a quick prototype or short, uniform text.
• Overlap: each chunk repeats a little of the end of the previous one, like a recap at the start of an episode. A sensible default when there is no clear structure, such as a meeting transcript.
• Cutting along the structure: chunk by the chapters, sections and numbered clauses the author already gave you, so clause 14.3 stays together with its heading. Right for handbooks, contracts and policies. A useful trick is to search small chunks but hand the model the larger parent section.
• Summarise with AI: for sections too long to be one chunk, a language model writes a short summary that becomes the chunk, linked back to the original. Search with the summary, but give the model the original text, because a summary can drop exact numbers. It costs one model call per long section.

You can mix methods in one system, then test with real questions and keep whatever finds the right chunk.

Embeddings: from chunk to numbers

Computers understand numbers, not meaning. An embedding model turns a chunk into a long list of numbers, like coordinates on a giant map of meaning. Chunks about similar ideas land close together: a paragraph about resigning sits near a paragraph about notice periods even when they share no words. A question gets coordinates on the same map, and finding relevant chunks becomes a question of distance.

It happens in three steps: the text is split into tokens, the model reads all the tokens together so each one takes its meaning from its neighbours, and the results are combined into one list. Each number in the list is a dimension. Embeddings have hundreds or thousands of them, no single one means something you can name, and more is not automatically better because it costs storage and speed. Many smaller models only read the first part of a chunk, which is one more reason chunk size matters.

Three practical rules for choosing a model: documents and questions must use the same model, changing the model means re-embedding every chunk, and you should test candidates on your own questions rather than trust a public leaderboard.

Vector databases

A normal database is brilliant at exact questions: find this employee ID, find every row where the grade is B. Our question is different: which chunks are closest in meaning to this one? A vector database stores each chunk's text, numbers and metadata together, and keeps an index to find the nearest chunks fast. A common method, HNSW, builds layers of shortcuts, like taking the highway to the right city and then local roads to the right street. It can occasionally miss the absolute closest chunk, but it is dramatically faster, and the saved metadata lets you filter, for example to the latest handbook only.

For a thousand page handbook almost any option is fast enough, so the real question is what your team can run. Chroma is simple for a laptop prototype, pgvector adds vector search to a Postgres you already run, Pinecone is a managed cloud service, Qdrant and Milvus are open source options for large scale or data that must stay on your servers, and OpenSearch or Elasticsearch work if you already use them for keyword search.

Key takeaways

• Use a layout-aware parser for tables, OCR for scans, and read the parsed output yourself.
• Save metadata (page, section, name, version) while you parse.
• Chunking has no magic size. Structure-based cutting suits handbooks and contracts.
• Use the same embedding model for documents and questions, and test models on your own questions.
• Pick the vector database your team can run. For a handbook this size, most are fast enough.

Part 3: Hybrid search and reranking

An employee asks what clause 14.3 says. The bot answers instantly, clearly and confidently, and it quotes clause 14.2. Nothing crashed and the model did not make anything up: it summarised exactly the text it was given. The problem is that it was given the wrong paragraph, and no bigger model fixes that. Part 3 fixes the search side.

Dense search: great at meaning, blind to exact things

Dense (semantic) search compares meaning, not spelling. "How long do I have to stay after resigning?" finds "the notice period for confirmed employees is ninety days" even though almost no words match. That is why it feels smart in demos: real users never use the document's exact wording.

The same strength is a blind spot. Clause 14.2 and clause 14.3 are both numbered paragraphs about leaving the company, so their coordinates land almost on top of each other and the number barely moves the dot. The same happens with product codes, names, amounts and grades like L4 and L5, and with rare words the embedding model has never seen.

Keyword search: BM25 and sparse retrieval

Keyword search is the index at the back of a textbook. BM25, the classic version, finds chunks containing your words and gives more weight to rare ones: a match on "employee" counts for little, a match on "gratuity" counts for a lot. It is called sparse retrieval because each chunk is described only by the few words it contains. Ask it the notice question in different words and it misses the clause completely. Each method fails exactly where the other wins, and real users mix both kinds of question on the same day.

Hybrid search: reciprocal rank fusion and alpha

Hybrid search runs both searches and merges the lists. The catch is that the scores sit on different scales, and adding them is like adding kilometres to kilograms. Reciprocal rank fusion ignores the scores and only looks at positions: a chunk earns points for how high it ranks in each list, and one that is high in both rises to the top. It needs almost no tuning, which is why many systems start with it.

Other systems keep the scores and balance them with a dial. Pinecone, for example, can hold both the dense and the sparse vector for a chunk in one index, and the dial is called alpha: lean towards meaning for casual questions, towards exact words for a handbook full of clause numbers. The scores must be brought to the same scale first, and the right setting is found by testing. In the example, keyword search ranks clause 14.3 first, dense search ranks it sixth, and after merging it is first and the wrong neighbour drops down.

Filter before you search

The metadata from Part 2 pays off here. Before searching, narrow the pool: only the current handbook, only the policy for this office, only the documents this employee is allowed to see. A search cannot return the wrong version if the wrong version is not in the pool, and it gets faster because there is less to compare.

Reranking: fast search is rough search

Both searches are built for speed, so they notice that a topic matches but cannot check whether a chunk actually answers. For a harder question such as "can I use my unused leave to shorten my notice period?", the one paragraph that combines both rules can sit at position seven. With a top k of five, the model never sees it, and sending fifty chunks to be safe is slow, costly and buries the answer in noise.

A reranker fixes this. It is a separate model, often a cross encoder, that reads the question and one chunk together and scores how well that chunk answers that question. Think of hiring: a recruiter skims hundreds of resumes for keywords (retrieval), then the best few get a real interview (reranking). Production systems use two stages because careful reading is slow: cheap search narrows thousands of chunks to dozens, and the expensive judgement turns dozens into a handful. How many go in and how many come out are knobs you tune by testing.

Making the context coherent

The last step before the model is tidying the chosen chunks: remove duplicates, pull in the neighbouring chunk when one starts mid-thought, keep a general rule together with its exception, and put the chunks in document order so the model reads a story and not a shuffled pile of notes.

Key takeaways

• Dense search matches meaning and goes blind on clause numbers, codes and names. Keyword (BM25) search is the opposite.
• Hybrid search runs both and merges them, by rank (reciprocal rank fusion) or with a dial like alpha.
• Metadata filters narrow the search before it starts.
• A reranker reads the question and each candidate together, so a two-stage design works well.
• Tidy the final context: no duplicates, complete thoughts, rule next to exception, document order.

Part 4: Stopping made-up answers, and measuring quality

The exact paragraph is in front of the model and it says ninety days. The chatbot replies, "ninety days, or sixty days if you are still on probation." The handbook never mentioned probation. The model made that part up, so confidently that nobody would think to check. Part 4 covers the last two blocks, Generate and Validate, and how to tell whether your system is getting better or slowly worse.

Why the model adds things

A language model is at heart a very good guesser of the next word. Answers about notice periods very often mention probation, so probation feels natural and slips in. It is not lying and it does not know it did anything wrong: it is completing a pattern. Making something up like this is called a hallucination. Newer models do it less often, but no model never does it, so the answer is not to wait for a perfect model but to build a system around it that keeps it honest.

Rules, temperature and handing over the text properly

The first tool is the simplest: tell the model the rules. Use only the text provided, say you could not find it if the answer is not there, and add nothing from memory. A witness in court says only what they saw, a storyteller fills the gaps, and models lean towards storytelling by default. A low temperature helps too, because it keeps the wording plain and likely instead of creative. But rules are only requests, and the model can still break them.

The second tool is how you hand over the text, with three small habits: label every chunk with document name, page and date, do not send too much because models often pay less attention to the middle of a long pile (five good chunks beat twenty average ones), and when two chunks disagree, such as last year's policy and this year's, tell the model which one wins, usually the newest.

Citations, and why they can be wrong

Ask the model to attach a source to every fact: "notice period is ninety days, Employee Handbook, section 14, page 412." The user can click and read the original line, and you can see in seconds whether search brought the wrong page or the model misread the right one. An answer without a source asks you to trust it, and one with a source lets you check it.

But a citation is also just a claim. A model can attach a nice sentence to a chunk that says something slightly different. A cheap check works well: ask the model to copy the exact sentence it used, then let plain code confirm that the sentence really exists in the source. If the quote is not there, the answer does not go out.

Response validation and the no-answer gate

Response validation is an editor who reads every answer before it is printed. Split the answer into single statements and check each one against the text you provided. In the example, "notice period is ninety days" passes and "sixty days if you are on probation" fails. You can then remove that statement, ask the model to write the answer again, or, if too much is wrong, say "I could not find a reliable answer." Add simple rule checks as well, such as whether there is a source and whether anything private is in the answer. It adds a little time and cost, and for answers about money, law or HR it is worth it.

Sometimes the best answer is no answer. Search always returns the closest chunks, even when none of them is close, and the model will happily try to answer from them. A gate before the model looks at the reranker's score for the best chunk, and if even that one scores low, the system skips the model and replies that it could not find this and suggests asking HR. Where to draw the line is found by testing, and a polite "I could not find this" that points to a real person builds more trust than a smooth guess.

Four kinds of mistakes

• Made up: a fact that appears nowhere in the text. Fix it with clear rules and the validation check.
• Blended: two correct chunks mixed into one wrong sentence. Send less text and check each statement.
• Outdated: a correct quote from a document that has since been replaced. Keep dates in metadata and remove old versions.
• Wrong chunks: search brought the wrong text and the model summarised it faithfully. This is not the model's fault, and the fix is back in search (Part 3).

No single setting makes mistakes disappear, so you need layers.

Drift, the golden test set and two separate scores

Even if the chatbot is perfect on launch day, it slowly gets less right: new documents arrive, old ones stop being true, users ask questions you never tested, and someone changes a model or a chunk size. This slow decline is called drift, like a printed map of a growing city.

You cannot stop the city from changing, but you can measure how far behind you have fallen. Build a golden test set: a list of real questions, each with the correct answer and the exact page where it lives, checked by a person who knows the handbook. Start small, include the hard ones (tables, clause numbers, follow-ups, and a few questions whose answer is not in the documents at all, to test the gate), and run the same exam whenever anything changes.

Give the chatbot two separate scores: did search bring the right chunk into the top results, and was the final answer correct and backed by its sources. If the answer is wrong but the right chunk was found, the problem is on the model side. If the right chunk never showed up, no prompt will save you and the search needs fixing. Because checking answers by hand is slow, many teams use a second model as a judge with a simple checklist, and a person still reads a sample to make sure the judge is fair.

After launch, keep watching real traffic: save each question, the chunks found and the answer, add thumbs up and down, and look closely at the questions where the chatbot said "I could not find this", because they often reveal a document you forgot to add. Each week, add a few real failures to the exam.

Key takeaways

• Hallucination is pattern completion, not lying. Build a system around the model instead of waiting for a perfect one.
• Grounding rules, low temperature, labelled context, fewer chunks, and newest version wins.
• A citation is a claim too. Check the exact quote, then validate the whole answer before it goes out.
• A gate before the model lets the chatbot say "I could not find this".
• Keep a golden test set, score search and answers separately, and keep watching real users.

Part 5: Memory, speed, caching and cost

The first question comes back in two seconds, clean, correct, with a source. By the thirtieth message in the same chat the answer takes much longer, the bill keeps climbing, and when the user asks "and what about contractors?" the chatbot answers about something from twenty minutes ago. Nothing is broken: this is what happens when a chatbot meets real conversations. Part 5 fixes memory, speed and cost, shows that they are really one problem wearing three masks, and ends by putting the whole series together.

The model does not remember

A language model does not remember your chat. Every time you press send it starts from zero, and the chat only feels continuous because the app resends the old messages with the new one, every time. Message thirty carries messages one to twenty-nine, plus the chunks from search, plus your instructions. That text is counted in tokens, small pieces of words, and this is the hidden link between the three problems: more tokens mean more to read, so a slower answer, and you pay for every token you send, so a bigger bill.

Follow-ups break search, and query rewriting fixes it

A user asks about the notice period for permanent employees and gets a perfect answer. Then they ask "and what about contractors?" The model reads the whole chat, so it understands, but search does not read the chat. It looks up only those words and brings back chunks about contractor invoices. The fix is query rewriting: before searching, one quick model call looks at the chat and writes a full question, "what is the notice period for contractors?", which search can actually answer.

Managing memory

Sending everything forever is slow, costly and makes the model miss details in the middle. There are three simple ideas: a sliding window that keeps only the last few messages in full, a summary that squeezes older messages into a short note (the small talk disappears and the important facts stay), and long-term memory, where facts about the user, such as department or language, are stored separately and added only when needed. Recent messages in full, older ones as a summary, permanent facts on file.

Where the time goes, and making it faster

One answer is a chain of steps: rewrite the question, search, rerank, write the answer, check it. Each takes time and they add up, so measure each step on its own, because you cannot speed up what you have not measured. Often people blame the model when the reranker or the check is the slow part. Once you know, the fixes are simple: run independent steps at the same time (meaning search and keyword search do not need each other), keep the expensive steps small (rerank fifty chunks, not five hundred, and use a fast search index), and stream the answer so the user starts reading right away. The total time is the same, but it feels much faster.

Caching and its danger

The biggest shortcut is not doing the same work twice. An exact cache returns the saved answer when the same question comes again, and a semantic cache also catches questions that mean the same, such as "how long is the notice" and "notice period duration". You can cache smaller things too, like the numbers made for a document.

The danger is a stale answer. If HR updates the handbook but the cache still holds the old answer, it is served instantly, with full confidence, and it is wrong. This is the same drift problem from Part 4, so every cache needs a rule for when to forget: save each answer with the version of the document it came from, and clear those answers when the document changes. A fast wrong answer is worse than a slow right one.

Where the money goes, and cutting cost

Often the biggest cost is the text sent to the model on every question: the instructions, the chat history and the chunks from search. Send ten large chunks instead of four focused ones and you pay for more than twice the text, and often get a worse answer because the right paragraph is lost in the noise. Better search is not only about quality, it also saves money.

The fixes: send fewer, better chunks (this is where reranking pays for itself), send easy questions to a smaller, cheaper model, use prompt caching if your provider offers it, make embeddings once in batches when a document is added, and track the cost of every question, because a monthly bill does not tell you where the money is burning.

The triangle: quality, speed and cost

Quality, speed and cost pull against each other. More chunks can improve quality but cost more and slow things down, checking answers catches mistakes but adds time, and a bigger model thinks better but costs more per answer. No setting wins all three, so a good system is one where you choose the trade-off on purpose: a legal assistant should accept slower, costlier answers for accuracy, while a support bot should be quick and cheap. Same system, different dials.

You can only turn those dials if you can see them. For every question, log how long each step took, how much text went in, what it cost, whether the cache helped, and whether the answer passed the checks. Look at it every week, fix one thing, and run the test questions again to make sure nothing else broke. This is what turns a chatbot from a demo into a real product.

The whole map

The series ends by opening every box again: parse the document properly, chunk it into useful pieces, embed and store them, retrieve the right pieces with meaning and keywords together, rerank to pick the best few, generate the answer from those pieces only, and validate it before anyone sees it. Around all of it sit memory, speed, cost and a test list that tells you when quality slips. No single block is magic: a chatbot you can trust is every block doing its job, and you measuring all of them. And back to the first question, "what is my notice period?": ninety days, clause 14.3, page 412, with a source you can click.

Key takeaways

• The model does not remember. The app resends the chat, so long chats cost more and run slower.
• Query rewriting turns a follow-up into a full question before searching.
• Sliding window, summary and long-term facts are three ways to manage memory.
• Measure each step before speeding it up. Parallel steps, small expensive steps, streaming.
• Exact and semantic caches save work, but every cache needs a rule for when to forget.
• Send fewer, better chunks, route easy questions to a smaller model, and track the cost of every question.
• Choose the quality, speed and cost trade-off on purpose, and log every question.

How the series was made

The narration is a clone of my own voice, made with Qwen3-TTS. The animation is built in Remotion and timed to the words, with 3D scenes in three.js. Everything uses my brand colours (black, white, yellow, blue) and Poppins, so all five parts look like one series. Each part opens with a short recap and shows the same pipeline map with the current block highlighted, so it works on its own and as a playlist.

Sound effects are from Kenney (CC0) plus my own recordings. Part 3 uses stock footage from Pexels, and Part 1 shows the RAGFlow logo and an EuroRAG screenshot to identify those products. The scripts, the examples and the pipeline map are mine.

Questions people ask

What is RAG in simple words?

RAG (retrieval augmented generation) is an open book exam for a language model. Instead of expecting the model to know your documents, the system searches them, picks the few passages that matter, and gives them to the model with the instruction to answer from them.

Why does a document chatbot give wrong answers even when the model is good?

Usually the mistake happens somewhere else in the pipeline: a table that was parsed badly, a chunk cut in the wrong place, search that returned the wrong paragraph, or a model that added a detail that is not in the text. The series shows which box each failure lives in, so you know what to fix.

Do I need to code to follow the series?

No. Each idea is explained with an analogy and one running example. The ideas apply whether you build a chatbot yourself or choose a ready-made tool.

Is this about one specific tool or vector database?

No. Parts 1 and 2 mention RAGFlow, EuroRAG and several vector databases, and Part 3 shows hybrid search with Pinecone as one example. The pipeline and the failure points are the same whichever tool you use.

Are the numbers in the videos real benchmarks?

No. Ninety days, page 412, 50 versus 500 chunks, 10 versus 4 chunks and the timeline bars are illustrative examples. The right values depend on your documents and models, and you find them by testing.

Should I start with Part 1?

If RAG is new to you, yes. If you already know the basics, jump to the part that matches your problem: wrong chunks in Part 3, made-up answers in Part 4, slow or costly chats in Part 5.

Related work

I build AI assistants that work on real data. Two examples from the portfolio: Milo, a real estate assistant for Charleston County, and self-hosted AI agents that work as teammates in a private chat workspace.

Want a document chatbot like this for your company?

If you have handbooks, contracts or manuals that people keep searching by hand, I can build a chatbot that answers from them and shows where each answer came from. Tell me about your documents on the contact page, and we can talk through what fits.