Compression Ratio vs Quality Trade-Off Prompt

This prompt is for AI engineers and operators who need to find the optimal balance between token cost and downstream task quality when compressing evidence. The job is not just to compress text, but to produce a tunable set of compressed outputs at different aggressiveness levels, each paired with a quality score measured against a task-specific rubric. You use this when you are building a production pipeline that must operate within a token budget, and you need data to decide where the knee in the quality curve sits before you hardcode a compression ratio.

The ideal user has a specific downstream task with measurable quality criteria—such as answer accuracy, recall of key facts, or citation precision—and a compression function that can accept a ratio parameter. You should bring your own quality metric definition, a representative sample of source documents, and a clear understanding of what 'good enough' looks like for your product. This prompt is not for one-off summarization or for cases where you lack a repeatable quality evaluation loop. If you cannot define what quality means for your task, you cannot tune the trade-off.

Do not use this prompt when the compression ratio is already fixed by infrastructure constraints, when the downstream task is too subjective for reliable scoring, or when the cost of running multiple compression passes exceeds the savings from optimization. It is also the wrong tool if your compression method is extractive-only and cannot vary its output length along a continuous spectrum. For those cases, use a simpler single-ratio compression prompt with a pass/factuality check. If the task involves regulated content where any compression carries compliance risk, pair this prompt with the Risk-Based Context Retention Prompt and require human review of the final operating point before deployment.

This prompt template is the core instruction set for the compression ratio vs. quality trade-off analysis. It instructs the model to take a source document, apply multiple compression ratios, and produce a structured report that includes the compressed text, a quality score, and a justification for each ratio. The output is designed to be machine-readable so you can programmatically select the best ratio for your cost, latency, and accuracy requirements.

textCopy
You are a context compression analyst. Your task is to compress the provided [SOURCE_TEXT] at multiple compression ratios and evaluate the quality of each compressed output against a task-specific quality rubric.

## INPUTS
- Source Text: [SOURCE_TEXT]
- Target Task Description: [TASK_DESCRIPTION]
- Quality Metric Definitions: [QUALITY_METRICS]
- Compression Ratios to Test: [COMPRESSION_RATIOS]
- Output Schema: [OUTPUT_SCHEMA]

## INSTRUCTIONS
1. For each ratio in [COMPRESSION_RATIOS], compress [SOURCE_TEXT] to achieve approximately that ratio (compressed_length / original_length).
2. For each compressed output, evaluate its quality against [QUALITY_METRICS] in the context of [TASK_DESCRIPTION].
3. Produce a structured report following [OUTPUT_SCHEMA] exactly.
4. If a compression ratio causes critical information loss that would make the output unusable for [TASK_DESCRIPTION], flag it with a quality score of 0 and explain why.
5. Do not introduce facts, claims, or entities not present in [SOURCE_TEXT].

## CONSTRAINTS
- Preserve all domain-specific terminology, named entities, numbers, and dates exactly as they appear in the source.
- If [SOURCE_TEXT] contains conflicting information, preserve the conflict rather than resolving it.
- Do not hallucinate citations or source references.
- If the source is too short to meaningfully compress at a given ratio, note this and return the full text.

To adapt this template, replace the square-bracket placeholders with your specific inputs. [SOURCE_TEXT] is the document or context you need to compress. [TASK_DESCRIPTION] should describe the downstream task that will consume the compressed output, such as 'question answering over financial filings' or 'summarization for a legal brief.' [QUALITY_METRICS] must define the scoring dimensions, such as factuality, completeness, and readability, with clear scoring criteria for each. [COMPRESSION_RATIOS] should be a list of target ratios like [0.1, 0.25, 0.5, 0.75]. [OUTPUT_SCHEMA] must specify the exact JSON structure you expect, including fields for the ratio, compressed text, quality scores per metric, an overall score, and a justification. After copying the template, validate that your quality metrics are measurable and that your output schema is strict enough to parse programmatically without manual cleanup.

This prompt is designed to be called in a sweep loop, not a single inference. The application layer iterates over a list of target compression ratios (e.g., 0.1, 0.3, 0.5, 0.7, 0.9) and calls the prompt once per ratio. Each call receives the same [ORIGINAL_CONTEXT] and [TASK_DESCRIPTION] but a different [TARGET_RATIO]. The model returns a compressed output and a quality score for that ratio. The harness collects all results into a sweep report, then either selects the best operating point automatically or presents the trade-off curve to a human operator for a decision. Do not try to compress to multiple ratios in a single call—the quality scoring becomes unreliable when the model must self-compare across compression levels.

Validation and retry logic must be strict because downstream tasks depend on the compressed context. After each call, validate that: (1) the output contains valid JSON with the required fields (compressed_context, quality_score, compression_ratio_achieved, information_loss_notes); (2) compression_ratio_achieved is within ±0.05 of the target ratio (if not, the model may have ignored the instruction—retry once with stronger constraint language); (3) quality_score is between 0.0 and 1.0; (4) compressed_context is not empty and is measurably shorter than the original (if it is longer, the model failed—retry or flag for review). For high-stakes domains, add a factuality preservation check by running a separate verification prompt that compares the compressed output against the original and flags additions, omissions, or semantic drift. Log every sweep result with the original context hash, target ratio, achieved ratio, quality score, token counts, and model version for later analysis.

Model choice matters. This prompt benefits from models with strong instruction-following and structured output capabilities. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro all handle the dual task of compression plus quality estimation reliably. Avoid smaller or older models that may conflate compression with summarization or produce hallucinated quality scores. If cost is a concern, run the sweep on a capable model to establish the trade-off curve, then use a cheaper model for production compression at the selected ratio—but validate the cheaper model's outputs against the original sweep baseline. Human review gating is required when the sweep shows a sharp quality cliff (score drops >0.3 between adjacent ratios) or when the selected ratio falls below 0.3 for regulated content. In those cases, surface the sweep report and the compressed output to a reviewer before the compressed context enters any downstream workflow.

Wiring into a RAG or agent pipeline is straightforward: the compressed output replaces the original context in the next stage's prompt. Store the compression_ratio_achieved and quality_score as metadata on the request so downstream evaluators can correlate compression decisions with end-to-end task quality. If you are running this sweep periodically to recalibrate compression settings (e.g., after a knowledge base update or model change), compare the new trade-off curve against the previous one and alert if the quality-at-ratio degrades by more than 0.1. This turns the prompt from a one-off tuning exercise into an ongoing quality control signal for your compression pipeline.