Definition Extraction Prompt for Knowledge Bases

This prompt is designed for a single, focused job: extracting one authoritative definition for a given term from a set of pre-retrieved documentation chunks. The ideal user is a technical writer maintaining a glossary, a support engineer building a tooltip system, or a knowledge base operator who needs to programmatically generate concise, context-aware definitions that are directly traceable to a source document. It assumes you have already solved the retrieval problem—using a vector store, keyword search, or hybrid approach—and have passed a set of relevant text chunks into the prompt as [CONTEXT]. The primary value is enforcing a strict output contract that prevents the model from hallucinating a general-purpose definition when a domain-specific one is required.

The prompt is built for a single-term, single-call workflow. You should invoke it once per term you need to define. It is not designed for open-ended Q&A where the user's intent is ambiguous, nor is it suitable for extracting multiple definitions in a single call, which often leads to scope creep and lower accuracy. The prompt is most effective when the [CONTEXT] contains explicit definitional content, such as a glossary page, an API reference 'Overview' section, or a paragraph that starts with a term followed by 'is' or 'refers to'. If the retrieved chunks only mention the term in passing without defining it, the prompt's abstention logic should trigger, returning a null or empty definition rather than fabricating one. This is a feature, not a bug, and it's critical for maintaining trust in a production knowledge base.

Do not use this prompt when you need to compare multiple terms, generate a list of all defined terms in a document, or produce a long-form explainer article. For those tasks, use a comparison table prompt, an entity extraction prompt, or a long-form synthesis prompt, respectively. Before wiring this into your application, ensure your retrieval pipeline is tuned to fetch definition-rich chunks. A common failure mode is passing a large, undifferentiated document as [CONTEXT], which dilutes the definitional signal. Instead, chunk your source documents with a strategy that respects semantic boundaries like headings and definition lists. The next step is to copy the prompt template and adapt the [OUTPUT_SCHEMA] to match your application's data contract.

This template is designed to be dropped directly into your prompt layer. It expects retrieved context chunks, a target term, and an output schema specification. The prompt enforces strict source grounding—definitions must be traceable to specific passages—and includes guardrails against scope creep, hallucinated qualifiers, and circular definitions. Replace each square-bracket placeholder with your application's runtime values before sending the request to the model.

textCopy
You are a technical definition extractor operating on retrieved knowledge base documents. Your task is to produce a precise, source-grounded definition for a target term.

## INPUT

**Target Term:** [TERM]

**Retrieved Context:**
[CONTEXT]

**Output Format:** [OUTPUT_SCHEMA]

## INSTRUCTIONS

1. Locate every passage in the retrieved context that defines, describes, or constrains the meaning of [TERM].
2. Synthesize a concise definition that captures the core meaning without introducing information absent from the context.
3. If the context contains multiple definitions or conflicting descriptions, include all variants and note the conflict.
4. If the context provides usage notes, scope boundaries, prerequisites, or domain qualifiers, include them.
5. If the context does not contain enough information to produce a reliable definition, respond with an explicit abstention rather than fabricating one.

## CONSTRAINTS

- Do not invent examples, use cases, or properties not present in the retrieved context.
- Do not resolve ambiguity by guessing. Flag ambiguity explicitly.
- Prefer the source's own phrasing for key definitional clauses. Do not paraphrase away precision.
- Include a confidence indicator for each definitional claim.
- Cite the specific source passage or chunk ID for every claim.

## OUTPUT

Return a valid JSON object matching [OUTPUT_SCHEMA]. If no definition can be extracted, return a JSON object with `"found": false` and a `"reason"` field explaining the gap.

Adaptation notes: Replace [TERM] with the term your system is looking up—this can come from a user query, a glossary build task, or an automated extraction pipeline. [CONTEXT] should contain the top-k retrieved chunks from your knowledge base, each with a stable chunk ID for citation. [OUTPUT_SCHEMA] should be a JSON Schema object or a plain-text description of the expected fields. Common fields include term, definition, variants, usage_notes, domain, source_chunks, and confidence. For high-stakes domains such as healthcare or legal, add a [RISK_LEVEL] placeholder and conditionally require human review when confidence is below a threshold. Wire the output through a JSON validator before ingestion. If validation fails, use a repair prompt or retry with the error message appended to the context.

The definition extraction prompt is not a standalone chatbot; it is a component inside a retrieval-augmented generation (RAG) pipeline. The application layer is responsible for retrieving the most relevant source chunks, assembling the [CONTEXT] variable, and injecting the target [TERM] before calling the model. Do not rely on the model to search a knowledge base or decide which documents to use—retrieval quality directly determines definition accuracy. For production use, implement a two-stage retrieval: a dense vector search for semantic relevance followed by a keyword or metadata filter to ensure the retrieved chunks actually contain the target term. If the term does not appear in any retrieved chunk, the pipeline should short-circuit and return a 'definition not found' response rather than forcing the model to guess.

After the model returns a definition, run a structured output validator before the response reaches any user or downstream system. The validator must check that the source_references array is non-empty, that each reference contains a valid document_id and excerpt field, and that the definition text does not contain placeholder language like 'according to the provided context.' Implement a retry loop with a maximum of two attempts: if validation fails, re-inject the same [CONTEXT] and [TERM] along with the specific validation error message into a retry prompt that instructs the model to fix the structural issue. If the retry also fails, escalate to a human review queue rather than silently dropping the request. Log every extraction attempt—including the retrieved context, model response, validation result, and final disposition—so that definition quality can be audited and retrieval gaps can be identified over time.

For high-stakes knowledge bases such as compliance documentation, clinical references, or legal glossaries, add a mandatory human approval step before publishing any new or updated definition. The review interface should display the term, the model-generated definition, the source excerpts side by side, and a confidence flag derived from the validator's checks. Reviewers should be able to approve, edit, or reject the definition, and their decision should be logged as training signal for future model selection or fine-tuning. Avoid deploying this prompt in fully autonomous mode for any domain where an incorrect definition could cause regulatory, safety, or contractual harm. Start with a shadow mode that logs definitions without publishing them, measure precision and recall against a golden set of human-authored definitions, and only remove the human review step once the pipeline consistently meets your accuracy threshold.