ASR Text Moderation
Update:
Full-text window mode
Asynchronous audio-on-demand moderation supports two text moderation modes, configured in the corresponding audio moderation policy in the Console. Continue to query the asynchronous result endpoint with the same taskId; no additional request parameters or signature changes are required.
Mode
Text moderation
Response behavior
Segment mode (default)
Moderates each original ASR segment independently, preserving the existing behavior.
Existing audioSpams, audioText, and result processing remain unchanged.
Full-text window mode
Combines ASR segments in chronological order, then moderates overlapping windows of at most 500 characters each, with approximately 100 characters of overlap. The ASR segments are not also submitted independently.
audioText contains the combined transcript. Text findings are mapped back to original ASR segments and returned in the existing audioSpams structure.
The character limit counts UTF-16 code units without splitting surrogate pairs such as emoji. Window boundaries may be adjusted at sentence boundaries. Long transcripts require multiple windows; this is not unlimited-length semantic analysis in a single request. This mode applies only to asynchronous audio-on-demand moderation, not synchronous or live audio moderation.
Mapping findings to original audio segments
A moderation window is a request unit, not an audio segment in the response. Each text spam retains the original ASR segment’s text, startTime, and endTime in seconds. Character offsets are not converted proportionally into word-level audio timestamps. Non-text findings, such as voiceprint findings, retain their existing response behavior. Mapped text findings also pass through the existing moderation policy processing.
Finding
audioSpams behavior
The same occurrence is detected in overlapping windows
Duplicate findings with the same full-text location, keyword, and label are merged. Window overlap does not duplicate the same segment. Separate occurrences of the same keyword retain separate candidate locations.
Multiple keywords occur in the same original ASR segment
Their findings are collected into one text spam, retaining the relevant tags, subTags, and wordList. The spam is not split by keyword or window count.
One expression spans multiple original ASR segments
All involved segments are associated with the finding. Each spam retains its own original text and timestamps. A segment may contain only part of the matched expression; it does not independently contain the complete expression.
Location precision: when the text moderation service does not provide an exact match offset, all candidate keyword occurrences within the source window are retained. A candidate is not proof that it is the unique matched occurrence. Semantic findings without an explicit keyword, or keywords that cannot be matched to the submitted text, are associated with the segments covered by that window rather than a precise word-level audio location.
Example: a finding spanning two ASR segments
Suppose the ASR text is “前文包含示例违规” at 32–38 seconds and “表达以及后续内容。” at 38–43 seconds. The combined transcript matches the placeholder expression “示例违规表达”, associating the finding with both segments. This excerpt shows only audioSpams; the placeholder and labels illustrate the response format, not an actual moderation decision.
{
"audioSpams": [
{
"startTime": 32.0,
"endTime": 38.0,
"text": "前文包含示例违规",
"tags": [
{
"tag": 160,
"level": 2,
"subTags": [
{
"subTag": 160001,
"wordList": [
"示例违规表达"
]
}
]
}
]
},
{
"startTime": 38.0,
"endTime": 43.0,
"text": "表达以及后续内容。",
"tags": [
{
"tag": 160,
"level": 2,
"subTags": [
{
"subTag": 160001,
"wordList": [
"示例违规表达"
]
}
]
}
]
}
]
}
Handling incomplete moderation
Continue to use the existing code, result, and audioSpams fields for the final business decision. Detailed window and segment-mapping diagnostics are kept in internal service logs and are not returned as public response fields.
A failed window audit or missing transcript returns code=1 and errorCode=-1, retaining known findings. Do not treat unchecked portions as approved; retry or route the task for manual review.
Full-text window mode
Asynchronous audio-on-demand moderation supports two text moderation modes, configured in the corresponding audio moderation policy in the Console. Continue to query the asynchronous result endpoint with the same taskId; no additional request parameters or signature changes are required.
| Mode | Text moderation | Response behavior |
|---|---|---|
| Segment mode (default) | Moderates each original ASR segment independently, preserving the existing behavior. | Existing audioSpams, audioText, and result processing remain unchanged. |
| Full-text window mode | Combines ASR segments in chronological order, then moderates overlapping windows of at most 500 characters each, with approximately 100 characters of overlap. The ASR segments are not also submitted independently. | audioText contains the combined transcript. Text findings are mapped back to original ASR segments and returned in the existing audioSpams structure. |
The character limit counts UTF-16 code units without splitting surrogate pairs such as emoji. Window boundaries may be adjusted at sentence boundaries. Long transcripts require multiple windows; this is not unlimited-length semantic analysis in a single request. This mode applies only to asynchronous audio-on-demand moderation, not synchronous or live audio moderation.
Mapping findings to original audio segments
A moderation window is a request unit, not an audio segment in the response. Each text spam retains the original ASR segment’s text, startTime, and endTime in seconds. Character offsets are not converted proportionally into word-level audio timestamps. Non-text findings, such as voiceprint findings, retain their existing response behavior. Mapped text findings also pass through the existing moderation policy processing.
| Finding | audioSpams behavior |
|---|---|
| The same occurrence is detected in overlapping windows | Duplicate findings with the same full-text location, keyword, and label are merged. Window overlap does not duplicate the same segment. Separate occurrences of the same keyword retain separate candidate locations. |
| Multiple keywords occur in the same original ASR segment | Their findings are collected into one text spam, retaining the relevant tags, subTags, and wordList. The spam is not split by keyword or window count. |
| One expression spans multiple original ASR segments | All involved segments are associated with the finding. Each spam retains its own original text and timestamps. A segment may contain only part of the matched expression; it does not independently contain the complete expression. |
Location precision: when the text moderation service does not provide an exact match offset, all candidate keyword occurrences within the source window are retained. A candidate is not proof that it is the unique matched occurrence. Semantic findings without an explicit keyword, or keywords that cannot be matched to the submitted text, are associated with the segments covered by that window rather than a precise word-level audio location.
Example: a finding spanning two ASR segments
Suppose the ASR text is “前文包含示例违规” at 32–38 seconds and “表达以及后续内容。” at 38–43 seconds. The combined transcript matches the placeholder expression “示例违规表达”, associating the finding with both segments. This excerpt shows only audioSpams; the placeholder and labels illustrate the response format, not an actual moderation decision.
{
"audioSpams": [
{
"startTime": 32.0,
"endTime": 38.0,
"text": "前文包含示例违规",
"tags": [
{
"tag": 160,
"level": 2,
"subTags": [
{
"subTag": 160001,
"wordList": [
"示例违规表达"
]
}
]
}
]
},
{
"startTime": 38.0,
"endTime": 43.0,
"text": "表达以及后续内容。",
"tags": [
{
"tag": 160,
"level": 2,
"subTags": [
{
"subTag": 160001,
"wordList": [
"示例违规表达"
]
}
]
}
]
}
]
}
Handling incomplete moderation
Continue to use the existing code, result, and audioSpams fields for the final business decision. Detailed window and segment-mapping diagnostics are kept in internal service logs and are not returned as public response fields.
A failed window audit or missing transcript returns code=1 and errorCode=-1, retaining known findings. Do not treat unchecked portions as approved; retry or route the task for manual review.