Content Filtering › Filter Placement

Where in the request-response pipeline you place a content filter matters as much as how you build it. A filter can sit at four distinct points: before the user input reaches the model, within the model's generation process, after the model produces output but before it is returned, or asynchronously after the response is already delivered.

Input filters screen user messages before they reach the model. If the input is flagged as harmful, the system can refuse to process it, respond with a canned refusal message, or route the request to a human reviewer.

Input filtering is the most common placement and has clear advantages. It prevents the model from being exposed to prompt injection payloads, jailbreak attempts, and requests for dangerous information. It is also computationally cheaper than output filtering, because you only need to run the filter once per request.

The limitation of input-only filtering is that it leaves output quality entirely to the model. Even with a clean input, the model might produce harmful outputs through hallucination, mode collapse, or unexpected generalization. A model asked to write a fictional story might produce deeply disturbing content even from an innocuous prompt. An adversary who understands that only input is filtered can craft inputs that are superficially benign but steer the model toward harmful completions through indirect means.

Input filters also face the challenge of ambiguity. A question about medication dosages could come from a pharmacist, a patient, a caregiver, or someone planning self-harm. A question about firearm modifications could come from a gunsmith, a competitive shooter, or someone planning violence. Input filters that are too aggressive block legitimate users; input filters that are too permissive pass requests that produce harmful outputs. The right calibration depends on knowing your user population, which is often difficult.

Output filters screen the model's response before returning it to the user. If the output is flagged, the system can either suppress the response entirely (returning a refusal message) or attempt to regenerate a safer alternative.

Output filtering is essential for catching cases that input filtering misses. A model might produce harmful content in response to a seemingly benign request ("Write a story about a character who explains how to..."), and an input filter would never detect this. Output filters catch the actual harmful content regardless of how it was elicited.

The main cost of output filtering is latency and resource usage. You must run the entire model generation before you can evaluate the output. If you detect a problem and need to regenerate, you have doubled (or more) your latency and compute cost. For streaming responses (where tokens are returned to the user as they are generated), this creates additional complexity: you cannot filter a response that is still being generated.

Some systems address the streaming problem with a speculative approach: run the output filter on the first 50-100 tokens as they arrive, and if the early tokens look dangerous, interrupt the stream and send a refusal. This adds slight latency to the first tokens but avoids the full cost of generating a complete harmful response before filtering. The effectiveness of this approach depends on how early in the response the harmful content typically appears; if a model front-loads its refusals or preambles before the harmful content, early-token filtering may miss it.

Another approach is to buffer the stream entirely on the server side before forwarding it to the client, applying the output filter to the complete response before any tokens reach the user. This sacrifices the perceived interactivity of streaming but keeps the filtering logic simple. Which approach you choose depends on how important the streaming experience is to your users and how latency-sensitive your filtering requirements are. Consumer chat applications tend to prioritize streaming interactivity; high-stakes enterprise applications may prefer the safety of buffered output filtering.

Output filtering also creates a decision about what to do with filtered responses. You can replace the harmful response with a canned refusal ("I can't help with that request."), attempt to regenerate a safer alternative, or return nothing at all. Each choice has tradeoffs. Canned refusals are fast and predictable but may frustrate users with legitimate requests. Regeneration addresses the user's underlying need but doubles latency and may still fail if the model keeps producing similar outputs. Returning nothing at all maximizes safety but is the worst experience for users whose requests were blocked incorrectly.

Production systems typically use both input and output filters. Input filtering catches the obvious harmful requests before wasting compute on model inference. Output filtering catches the subtler cases where the model produces harmful content despite a clean input. The combination provides defense in depth: an attacker must craft a prompt that bypasses both the input filter and the model's own safety training, and produce an output that also bypasses the output filter.

The value of bidirectional filtering compounds with the diversity of the two filters. If both input and output filters use the same underlying model, they will likely share the same blind spots, and an adversary who defeats one will likely defeat both. Using architecturally distinct filters (e.g., a fast keyword classifier at input and a fine-tuned transformer at output, or an embedding-based classifier at input and an LLM judge at output) means that a bypass technique targeting one filter's specific weaknesses is less likely to defeat the other.

Not all filtering needs to happen in real time. Asynchronous filters run after the response is already delivered to the user, usually for monitoring and retrospective analysis. They can flag conversations for human review, update training data for filter improvement, or trigger account actions (warnings, suspensions) based on patterns of behavior over time.

Asynchronous filters can afford to be much more expensive and accurate than real-time filters, because they are not in the critical latency path. You can run a large LLM-based judge, apply multiple classifiers in parallel, or perform complex multi-turn analysis on entire conversation histories. The tradeoff is that harmful content may have already reached the user before the flag is raised. For most categories this is acceptable (retrospective action is still valuable), but for categories where real-time prevention is critical (e.g., CSAM, bioweapon synthesis instructions), asynchronous-only filtering is insufficient.

Asynchronous filters are also the most practical mechanism for maintaining and improving your real-time filters. By continuously reviewing a sample of production traffic with high-quality classifiers, you build a feedback loop: edge cases found by the async filter become training data for the next version of the real-time filter. This feedback loop is one of the most important architectural features of a mature content filtering system.

The choice of filter placement depends on the threat model, the latency budget, and the acceptable false-positive rate. The key considerations are:

• Input filters are fast and cheap, but they miss output-side failures
• Output filters provide broad coverage but add latency and complexity for streaming
• Both together provide defense in depth at higher total cost
• Async filters are expensive and accurate, but reactive rather than preventive

---