LLM terms builders actually meet
The core language-model concepts you run into the first week of building with AI tools: retrieval, hallucinations, embeddings, foundation models, and when fine-tuning beats prompting.
retrieval-augmented generation (rag).
Retrieval-augmented generation (RAG) is a technique where a language model's prompt is augmented with documents fetched from an external knowledge source at query time, so answers draw on retrieved facts rather than only on what the model memorised during training.
The technique comes from a 2020 paper by Lewis and colleagues at Facebook AI Research, which showed that bolting a retriever onto a generator beat both pure retrieval and pure generation on knowledge-heavy tasks (arXiv:2005.11401). In practice the pipeline is three steps: your documents are chunked and turned into embeddings, a query pulls back the closest chunks, and those chunks are pasted into the prompt ahead of the question.
You meet RAG in vibe coding the moment an AI tool answers questions about your own codebase or docs. When Cursor indexes your repository, or a support bot built on an app platform answers from your help articles, that is RAG. The quality ceiling is almost always the retrieval step, not the model: if the wrong chunks come back, the best model in the world summarises the wrong thing.
When it matters: any feature that must answer from private or fresh content, because training data is neither. When it does not: questions the base model already answers well, where adding a retrieval layer only adds latency, cost, and a new place to break. Start by asking whether a plain prompt with the document pasted in already works; RAG is what you build when the corpus stops fitting in the cost envelope of every request.
ai hallucination.
An AI hallucination is output a model states confidently but that is false or unsupported by its training data or provided context, such as an invented API, citation, or statistic. It is a byproduct of next-token prediction, not a database lookup error.
Language models generate the next likely token, not the next true one. When the training distribution offers a plausible-sounding continuation, the model produces it with the same fluent confidence whether it is right or invented. The research literature catalogues the failure in depth; a widely cited survey by Huang and colleagues taxonomises the causes across data, training, and decoding (arXiv:2311.05232).
In a coding session hallucination has a specific shape: an import from a package that does not exist, a method that was never in the API, a config key from a different framework, a citation to documentation that returns 404. It is the reason the compile-run-test loop matters more in AI-assisted work, not less: the type checker and the test suite are your hallucination detectors, and a generated claim is unverified until one of them has seen it.
What actually reduces it: grounding the model in real context (open files, docs, retrieved chunks), asking for sources you then check, and lowering the stakes per step so a wrong guess fails fast. What does not: asking the model whether it is sure. Our prompt engineering guide covers the grounding patterns that survive contact with real repositories.
embeddings.
Embeddings are numeric vector representations of text, code, or other data in which semantic similarity becomes geometric closeness. Systems compare the vectors to find related content, which powers semantic search, clustering, deduplication, and the retrieval step in RAG pipelines.
An embedding model maps a piece of text, an image, or a code snippet to a list of numbers, typically a few hundred to a few thousand dimensions. Content with similar meaning lands close together in that space, so nearest-neighbour search over vectors becomes semantic search over meaning. Provider documentation, such as OpenAI's embeddings guide (platform.openai.com), lists the standard applications: search, clustering, recommendations, classification, and deduplication.
For builders, embeddings are the invisible half of every “chat with your data” feature. The visible model answers the question; an embedding model chose what the answering model got to read. They are billed separately and cheaply relative to generation, but the choices around them, chunk size, overlap, which embedding model, when to re-embed after edits, decide retrieval quality more than anything you do in the prompt.
When this matters to you: the moment search by keyword stops being good enough, or a RAG feature returns confidently wrong chunks. When it does not: small corpora. A few dozen documents fit straight into a modern context window, and skipping the vector database entirely is the simpler, cheaper system.
foundation model.
A foundation model is a large model trained on broad data at scale that serves as a base for many downstream tasks, adapted through prompting or fine-tuning rather than built per task. The GPT, Claude, Gemini, and Llama families are foundation models.
The term was coined by Stanford's Center for Research on Foundation Models in 2021 to name the shift from task-specific models to broad pretrained bases adapted for many uses (arXiv:2108.07258). The economics follow from the definition: pretraining is enormously expensive and done by a handful of labs; everyone else adapts the result through prompting, fine-tuning, or tool wiring.
Practically, every tool in the vibe-coding stack is a wrapper of workflow around someone's foundation model. The app builder, the coding agent, and the chat sidebar differ in scaffolding, but the raw capability comes from the same short list of base models, which is why tool choice is mostly a choice about workflow, price, and integration rather than about raw intelligence.
Why the term earns a place in your vocabulary: pricing pages, model pickers, and changelogs all assume it. When a tool says it upgraded its underlying model, your costs, your context window, and your failure modes all move at once, and knowing the base model behind a tool tells you more about its behaviour than the tool's own marketing does.
fine-tuning vs prompting.
Fine-tuning further trains a model's weights on your own examples; prompting steers a frozen model with instructions and context at request time. Prompting is cheaper and faster to iterate; fine-tuning suits stable, high-volume tasks where prompt engineering has plateaued.
These are the two standard ways to specialise a foundation model, and they sit at opposite ends of a cost curve. Prompting, including system prompts and few-shot examples, changes nothing about the model and iterates in seconds. Fine-tuning runs additional training on your example pairs and produces a variant model you then host or call; provider guides describe the workflow and its costs (platform.openai.com).
The honest default for builders is prompting, and the industry's own guidance agrees: fine-tuning is recommended after prompt engineering, few-shot examples, and retrieval have been tried, because those are cheaper, faster to debug, and do not freeze your behaviour into a model you must retrain to change. Most production “customisation” you see in vibe-coded apps is a well-built system prompt plus RAG, not a custom model.
Fine-tuning earns its cost when the task is stable and high-volume, the target behaviour is hard to describe but easy to demonstrate with hundreds of examples, or you need a small cheap model to imitate an expensive one on a narrow task. If your requirements are still changing weekly, you are not there yet.