Before Sending Logs to an LLM, Reduce the Noise Into a Question

Context is not evidence

Pasting thousands of log lines into an LLM is tempting, but timestamps, request IDs, repeated messages, and unrelated requests can obscure the actual question. A useful preprocessing step is to separate recurring structure from the values and examples that deserve investigation.

ctrlb-decompose is an open-source Rust project aimed at that step. Its README describes a pipeline that normalizes variable tokens, incrementally clusters similar lines, then reports typed variables, counts, quantiles, and anomaly hints. It documents human-readable, compact LLM-oriented Markdown, and JSON output.

Triage before interpretation

The practical value is not an automatic incident conclusion. A smaller handoff can ask concrete questions: Which error pattern increased? Which duration distribution changed? Which representative raw lines should be reviewed next?

That complements, rather than replaces, grep, log search, metrics, and traces. Compression can hide the rare detail that matters, and a summary is never proof of a production incident. Teams also need their own redaction and access controls before any logs enter an AI workflow.

An adoption boundary worth keeping

For high-volume application logs, this kind of structural triage may be worth evaluating on safe, non-production data. For audit-heavy work or a request that needs an exact causal chain, retaining and querying the original evidence is the simpler and safer default.

Not tested and not run. This article is based on public documentation and repository structure; it makes no independent claims about compression, performance, accuracy, security, or production suitability.

Sources: README, Cargo manifest, and MIT license.

AI-assisted disclosure: This draft was prepared with AI assistance and reviewed against the linked public sources.