Content Guard¶

Warning

You are using an EXPERIMENTAL processor! Experimental processors:

May have bugs or stability issues
May experience breaking API changes
May not produce the expected results

By using this experimental processor you acknowledge:

It should NOT be used in a production context
It is NOT covered under F5 support agreements
Some experiments are not successful - the functionality could be retired.

Before you begin¶

Follow the steps in the Install with Helm topic to run F5 AI Gateway.

This processor is not part of the default installation and must be enabled like this:

processorLabs:
  contentGuard:
    enable: true

Overview¶

Note

The Content Guard processor uses a large classification model and we recommend running it on GPU-backed hardware. Running this model on CPU-only hardware is not advised due to performance limitations.

Built with Llama, the F5 Content Guard processor runs as a standalone processor container in AI Gateway. This processor detects and indicates whether a given prompt or response is safe or unsafe, and if its deemed unsafe, lists the content categories violated. For more information on LLama follow this link.

Processor details	Supported
Deterministic	No
GPU acceleration support	Yes
Base Memory Requirement	4 GB
Input stage	Yes
Response stage	Yes
Recommended position in stage	Beginning
Supported language(s)	English, French, German, Hindi, Italian, Portuguese, Spanish, Thai.

Required processor order¶

The Content Guard processor only supports English, French, German, Hindi, Italian, Portuguese, Spanish, and Thai language prompts; unsafe topics in any other language will not be detected. For protection against unsafe topics, the F5 language-id processor must be configured to run in a stage before the content-guard processor and configured with reject: true and allowed_languages: [“en”, “fr”, “de”, “hi”, “it”, “pt”, “es”, “th”]. This will ensure that only prompts detected in the supported languages will be allowed to proceed in the processor pipeline to the content-guard processor, before being sent to a configured Service.

Language	Code
English	en
French	fr
German	de
Hindi	hi
Italian	it
Portuguese	pt
Spanish	es
Thai	th

Configuration¶

processors:
  - name: content-guard
    type: external
    config:
      endpoint: https://aigw-processor-labs-content-guard.ai-gateway.svc.cluster.local
      namespace: f5-processor-labs
      version: 1
    params:
      experimental: true
      reject: true

Parameters¶

Parameters	Description	Type	Required	Defaults	Examples
Common parameters
`experimental`	This flag acts as an acknowledgement that you are using an experimental processor. The processor will not run unless this is set to `true`.	boolean	Yes	`false`	`true`

When reject is set to true, this processor will reject the request when unsafe content is detected, otherwise it will add to the violation tag.

Tags¶

Tag key	Description	Example values
`violation`	Added if reject is set to false and unsafe topics are detected.	`["s2", "s10"]`

Safety labels¶

The processor will attempt to predict safety labels on the 13 categories shown below, this is based on the MLCommons taxonomy of 13 hazards.

Code	Description
S1	Violent Crimes
S2	Non-Violent Crimes
S3	Sex-Related Crimes
S4	Child Sexual Exploitation
S5	Defamation
S6	Specialized Advice
S7	Privacy
S8	Intellectual Property
S9	Indiscriminate Weapons
S10	Hate
S11	Suicide & Self-Harm
S12	Sexual Content
S13	Elections

Chunking input and batch processing¶

The Content Guard processor will split inputs and responses into overlapping chunks and perform inference on these chunks in batches. Chunks are designed to overlap so that context is preserved across boundaries; this ensures that if unsafe text occurs at the edge of one chunk, the overlapping region with the next chunk will still capture it.

Note

Always perform empirical tests on hardware with real or representative data. Profiling is the best way to see how changing chunk and/or batch sizes impacts performance.

Chunking input¶

Chunk size controls how much of the input is processed at a time. It’s based on the model’s maximum input limit and how much context the task needs. Larger chunks use more memory and may slow things down, while smaller chunks can be faster but might miss important context.

The Content Guard processor splits its input into chunks of a variable number of characters, between 32 and 512000 ( default: 4096). The number of tokens is configurable by setting CONTENT_GUARD_PROCESSOR_CHUNK_SIZE in the processors.f5.env section of the AI Gateway Helm chart.

The Content Guard processor implements a sliding window (overlap) for chunking input. A sliding window refers to the practice of dividing longer text into overlapping chunks so that a model can capture context that spans chunk boundaries. During inference, each chunk is fed separately into the classification model. Because each chunk is passed through the model (a forward pass), the process can increase memory usage as more chunks are generated and processed. Too much overlap can lead to repeated processing of the same tokens, which might not improve prediction efficacy and could even introduce redundancy in the predictions. Decreased overlap reduces redundancy in the processed data but with little or no overlap, the model might miss contextual cues that lie near the chunk boundaries, potentially reducing prediction consistency across segments.

The default chunk overlap size in tokens is half the value of the chunk size setting; to disable overlapping set the environment variable CONTENT_GUARD_PROCESSOR_CHUNK_OVERLAP: 0. This value must not be set to a value larger than chunk_size - 1.

Previous Next