AI Dictionary: Knowledge, Grounding, and Evidence
- Published
Where model answers draw their information from, how retrieval supplies evidence, and why plausible claims need verification.
This dictionary focuses on LLM-based coding agents. Product behavior varies by model, API, and harness. Entries explicitly marked as informal describe working vocabulary used here, rather than universal technical definitions.
Parametric knowledge
Information and patterns reflected in a model’s learned parameters. Ordinary inference uses those parameters without changing them. Counterpart to contextual knowledge, which is supplied for the current inference.
This is not a conventional database lookup. A model can reproduce facts, generalize from learned patterns, and sometimes memorize training examples. Frequency, data quality, training objectives, and generalization all affect reliability; common topics are not guaranteed correct, and rare topics are not guaranteed wrong.
For example, a model may explain a familiar sorting algorithm without reading a source, yet give an outdated signature for a library. Check the installed library’s types rather than treating fluent recall as evidence.
Further training or fine-tuning can change parameters. Supplying current documentation through context or retrieval is often a simpler way to inform a task, without changing the deployed model.
Knowledge cutoff
A provider’s stated approximate boundary for the recency of a model’s training knowledge. It is not a guarantee that the model knows every earlier fact or knows nothing later: training stages and datasets can have different dates, and inference-time tools can supply current information.
For example, a model with an older cutoff can answer about a new API after reading its current documentation. That answer uses contextual knowledge rather than proving the API was in its training data.
A model may express uncertainty, guess, or repeat an outdated pattern when asked about recent changes. Verify version-sensitive claims against current sources, even if the release predates the cutoff. The cutoff is a reason to check freshness, not a test of truth.
Contextual knowledge
Information supplied for the current inference: the task, instructions, retrieved documents, selected history, and tool results. Counterpart to parametric knowledge, which is reflected in learned parameters.
For example, the model recalls that lookupUser returns a user object, but the current type definition says Promise<User | null>. Loading that definition gives it evidence to write an await and a null check.
Supplying evidence can improve accuracy, but context is not automatically true or followed. A stale README, malicious web page, or incorrect tool result can mislead the model. Resolve conflicts using source quality, version, and instruction priority rather than assuming whatever was pasted last wins.
Load enough evidence to support the task, preserve its provenance, and verify consequential claims against the underlying source.
Retrieval-augmented generation (RAG)
Generating an answer using information retrieved from an external source at inference time. A retriever finds relevant material; the application supplies it as context for the model. This does not update the model’s parameters.
For example, search internal API documentation for the method being changed, retrieve its signature and usage example, and ask the model to write code against them. Retrieval can use keyword search, embeddings, or a combination. The original RAG paper combined a language model with retrieved passages.
The result depends on retrieving the right, current evidence and using it faithfully. Missing passages, stale indexes, and malicious retrieved instructions remain possible; RAG does not eliminate hallucinations.
Embedding
A numerical vector representing an input, such as a text passage. An embedding model is trained so that useful relationships between inputs can be captured through vector similarity; the meaning of “similar” depends on that model and task.
For example, a search for “reset my password” can retrieve a passage headed “account recovery” even when the wording differs. Embeddings can support retrieval, but similarity is not proof that a passage is correct or relevant. They are distinct from the token IDs processed by a tokenizer.
Grounding
Connecting generated claims or actions to identifiable evidence, such as a retrieved document, current file, or tool observation. Grounding makes verification possible; it does not guarantee the model interpreted the evidence correctly.
For example, “This function returns null, according to its current type declaration” is grounded in a checkable source. A citation that points to a page without supporting the claim is not sufficient. For code changes, check the evidence and the resulting behavior.
Hallucination
Model output that is unsupported or false, often presented plausibly. It need not sound confident, and not every incorrect output is a hallucination: a syntax error, for example, may simply be a coding mistake.
A useful distinction is factuality versus faithfulness:
| Kind | Example | Useful response |
|---|---|---|
| Factuality failure | Invents a method that the library does not expose | Inspect version-matched documentation or types |
| Faithfulness failure | Says a log shows success when it reports failure | Compare the claim directly with the supplied evidence |
These categories describe the error, not a unique cause. Both can occur in short contexts, and both can have several causes. Missing knowledge, misleading retrieval, conflicting instructions, and poor use of context can all contribute. The distinction is discussed in this hallucination survey.
Adding relevant evidence can help; removing irrelevant material can help too. Neither is a guaranteed cure. For coding work, confirm the claimed API exists, run meaningful checks, and inspect the actual change. Fluency and citations alone do not establish truth.
Sycophancy
A tendency to agree with or flatter the user at the expense of accuracy or independent judgment. It can show up as endorsing a false premise, changing an answer to match a stated preference, or giving praise instead of criticism.
Training on human preferences can contribute to this behavior; it is not the only influence, and not every change of mind is sycophancy. Anthropic’s research found that preference judgments sometimes favor agreement over correctness.
For example, “I think this function is thread-safe; confirm?” can bias an answer more than “Check this function for concurrency bugs and show the evidence.” If the model reverses itself after you express doubt, ask what evidence changed. Neutral phrasing and explicit criteria help, but verification is still necessary.
Primary source
Direct evidence for the question being asked: the executed code, raw log, original conversation, API response, or authoritative statement of a contract. Being primary does not guarantee completeness or correctness.
The classification depends on the claim. Source code is primary evidence of implementation; the vendor’s API specification is primary evidence of its documented contract. A README can be primary evidence of project intent even if it inaccurately describes runtime behavior.
For example, a log saying “test failed” is direct evidence of that run. A summary saying “all tests passed” is an account to compare with it. Confirm the relevant version, commit, and environment: reading source from another branch does not establish what production executed.
You can inspect targeted portions rather than loading an entire file. Keep enough surrounding context to avoid drawing a conclusion from a misleading excerpt.
Secondary source
An interpretation or summary of other evidence: a report describing search results, a summary of a conversation, or an agent’s account of test output. The role depends on the question; an official specification can itself be a primary source for a contract.
Secondary sources can save context and reading time, but may omit details or become stale. They are not always shorter, and a careful synthesis may explain a subject better than a raw source.
For example, a handoff says “authentication is complete” but omits that authorization tests still fail. Follow its links to the code and test evidence before treating the feature as done.
A useful summary identifies its sources, versions, assumptions, and unresolved questions. That lets the next reader verify a material claim without repeating the entire investigation.