RAG for non-engineers.

RAG stands for retrieval-augmented generation. It's the technical name for a pattern most "chat with your documents" products use. Here's what it means without the jargon.

The problem it solves

A language model knows what was in its training data. It doesn't know what's in your company's private wiki, your specific PDF, or the article published yesterday. If you ask about those, the model has to either guess (bad) or say "I don't know" (correct but not useful).

How RAG works

RAG plugs a search step in front of the model. When you ask a question:

1. **Search**: The system searches through a specific document store (your wiki, your PDF library, your knowledge base) for passages relevant to your question. 2. **Retrieve**: Grabs the top few matching passages. 3. **Generate**: Sends the model your question AND those passages, saying "answer the question using this context."

The model's reply is grounded in the retrieved passages instead of relying only on what it learned during training.

Why it's better than just asking

For any question about specific documents, RAG produces more accurate answers with less hallucination. The model isn't guessing about what's in your wiki — it's reading the relevant passages that were just handed to it.

Where it fits in LADLE

LADLE's file upload is a simplified RAG pattern. When you attach a PDF to a chat, LADLE includes the document as context alongside your question. Not the full RAG pipeline (there's no vector database, no persistent index) — just "include the whole doc in context for this chat."

This works because Claude's 200K-token context window can fit a lot. A 200-page PDF is ~60-80K tokens — well within budget with room to spare for the conversation.

When simple context inclusion is enough

For most "chat with a specific document" use cases, just attach the file to the chat. LADLE's context window handles it, and you get the benefits of RAG without any of the infrastructure.

When real RAG is needed

For "chat with 10,000 documents" — a company wiki, a code repository, a research library — you can't fit everything in context. You need a real RAG pipeline: an embedding model that indexes the docs, a vector database that stores the index, and a retrieval step that picks the top matches per question.

Building that is engineering work; several products (Pinecone, Weaviate, Vercel's AI SDK) provide the pieces. It's a real project, not a LADLE feature.

Why "chat with your data" products vary in quality

Two RAG systems built on the same LLM can produce dramatically different answer quality because RAG has many moving parts: what chunks the docs get split into, how the embedding model was trained, what similarity threshold triggers retrieval, how many chunks come back, how they're ranked, how they're formatted for the model. Each is a knob; each affects output.

For a specific need, the right question isn't "does this product use RAG" (they all do) but "how well tuned is their retrieval for my kind of question."