從誤判到精準：遊戲社區 AI 審核的工程化實踐詳情 - 人工智能亞馬遜雲開發者博客

引言

遊戲社區作為典型的 UGC（用户生成內容）場景，用户遍佈全球，涉及中、英、日、韓、俄、西班牙語、阿拉伯語、法語等多種語言。討論氛圍活躍，但其中不可避免會夾雜辱罵、仇恨、色情、暴力、涉政等違規言論。

平台需要在不傷害社區氛圍的前提下，做到及時、準確的內容審核。但傳統規則引擎容易出現“誤殺”或“漏判”，直接依賴大語言模型審核又存在準確率不高、分類不穩定的問題。

我們遇到的客户需求還有一些額外挑戰：

審核對象是長文本（動輒上千字符）；
無法通過向量檢索或 RAG 切片，因為長文本拆分後上下文丟失，相關度很差；
模型需要一次性給出 判定結果（Pass/Reject ），並在 Reject 時指定 10 種違規分類之一。

在這樣的背景下，我們為一家遊戲公司落地了一套 提示詞工程 + ReAct 框架 + 工程化架構 的 AI 審核方案。最終整體準確率提升到了 81% 。需要説明的是，對比基準是客户的人工審核數據，而人工標註過程存在“多人多日、缺乏複核”的情況，口徑並不完全統一。因此，我們只能説模型的 81% 一致性大體上達到了人工審核的水平，具體效果還需結合更嚴格的標註體系進一步驗證。

📢限時插播：無需管理基礎設施，利用亞馬遜技術與生態，快速集成與部署生成式AI模型能力。
✨ 精心設計，旨在引導您深入探索Amazon Bedrock的模型選擇與調用、模型自動化評估以及安全圍欄(Guardrail)等重要功能。
⏩快快點擊進入《多模一站通 —— Amazon Bedrock 上的基礎模型初體驗》實驗構建無限, 探索啓程！

整體方案架構

工程化落地能力

在文本審核項目中，提示詞優化只是其中一步。真正支撐業務落地的，是一整套 可觀測、可回滾、可擴展 的工程架構：

藍綠部署：通過 Amazon Bedrock 的多版本部署機制，提示詞優化和模型更新可以安全上線，支持灰度/回滾。
日誌與判例庫：所有審核請求和結果寫入 DynamoDB / OpenSearch，用於後續的回溯分析與提示詞再訓練。
配置與流控：Amazon AppConfig + 控制 Lambda，保證在高併發/大流量場景下系統穩定。
端到端可監控：從請求入口到最終存儲都有日誌鏈路，方便快速排查問題。

提示詞冷啓動階段：提示詞從 0 到 1

在沒有任何“黃金提示詞”的前提下，拿到可用的提示詞方法有很多種，甚至可以直接讓AI生成一個。

但我們這裏採用冷啓動的辦法，先讓模型把客户給的幾千條樣本過一遍。每跑一條，就拿它的結果和人工標註比對，把提示詞裏有問題的地方修掉。這樣循環一輪，等於幫我們湊出了一個“能跑”的初始版本，後面再慢慢打磨。

我們的做法是：

讓大模型逐條讀取客户提供的數千條人工審核樣本（每條都包含文本、判定結果以及違規分類）。
在閲讀過程中，模型會嘗試基於已有樣本生成提示詞。
每讀取一條樣本，就對提示詞做一次微調，逐步修正不合理的部分。
完成一輪全量樣本後，就得到一個 初始提示詞，作為進一步優化的基線。

例如，最初我們生成的提示詞大致如下：

You are a content moderation model.
## Task
Analyze the following user-generated text.
1. Classify it as "Pass" or "Reject".
2. If "Reject", assign one of these categories:
   - Hate Speech
   - Sexual Content
   - Violence
   - Political Sensitivity
   - Spam / Ads
   - Self-harm
   ...
## Output Format (JSON)
{"result": "Reject", "category": "Hate Speech"}

在冷啓動階段，這個提示詞的準確率並不算高，容易出現 灰色語境誤判（例如把二次元梗誤判成色情內容），或者 多語言覆蓋不足（對阿拉伯語、西班牙語等的判定不穩定）。但它為後續優化奠定了基礎。

ReAct 框架引入：讓模型“先思考，再行動”

冷啓動階段得到的提示詞雖然能跑通流程，但在一些關鍵問題上仍然存在不足：

灰色語境：例如二次元梗、諷刺語氣，容易被誤判為違規。
多語言一致性：某些語言（如阿拉伯語、西班牙語）分類不穩定。
輸出隨機性：相同輸入多次測試，結果可能不同。

為了解決這些問題，我們在提示詞中引入了 ReAct （Reason + Act）框架。

ReAct 的核心思想是讓大模型先進行顯式的“推理”步驟，再做最終的“行動”輸出。這樣可以減少隨機性，並提高可解釋性。

ReAct 框架在審核場景中的拆解

1、 Reasoning （思考）：

Step 1: 確定文本語言
Step 2: 提取潛在違規關鍵詞或短語
Step 3: 將關鍵詞與違規類別進行匹配
Step 4: 根據上下文和類別，決定 Pass /Reject

2、 Action（行動）：

輸出最終 JSON 結果（判定 + 類別）。

示例提示詞片段

下面是我們在 ReAct 框架下的一部分提示詞（簡化版）：

You are a professional content moderation assistant.  
Follow the steps below before giving the final output:  

Step 1: Identify the language of the text.  
Step 2: Extract any potentially offensive or sensitive words.  
Step 3: Match the extracted words to one of the violation categories.  
Step 4: Decide whether the text is "Pass" or "Reject".  

Finally, output ONLY in the following JSON format:  
{"result": "Reject", "category": "Hate Speech"}

這樣設計後，準確率雖不高，容易把二次元梗當成色情，或對小語種判定不穩。但它給我們提供了一個起點。

ReAct 框架下的實現示例（Python 偽代碼）

在工程落地中，我們通過 Agent 框架調用大模型，來執行上述 ReAct 推理：

from strands import Agent, tool
@tool
def moderation_tool(text: str) -> dict:
    """
    Classify the input text into Pass/Reject and category using ReAct framework.
    """
    reasoning_prompt = f"""
    Step 1: Identify language.
    Step 2: Extract potentially offensive words or sensitive context.
    Step 3: Match with violation categories.
    Step 4: Decide Pass or Reject.
    Text: {text}
    """
    # 調用大模型
    result = llm_call(reasoning_prompt)
    return result
# 示例調用
print(moderation_tool("This game sucks, I hope the devs all die in a fire."))
# 輸出示例: {"result": "Reject", "category": "Hate Speech"}

在 ReAct 機制下，我們觀察到模型的表現明顯更加穩定：

對多語言輸入的分類一致性增強；
對灰色語境（如“玩梗”）的誤判顯著減少；
審核理由透明，可以覆盤和解釋。

多輪循環優化：從 3 輪到 10+ 輪，我們如何選定 5 輪

在引入 ReAct 之後，我們對“每輪：全量跑樣本 → 糾錯 → 修提示詞”的閉環進行了系統化實驗，對比不同輪數的收益與成本：

3 輪：欠擬合
- 典型問題：仍然存在多語言一致性不足、灰色語境誤判偏多。
- 現象：指標提升明顯低於 5 輪，呈“上升未飽和”狀態。
5 輪：效果- 成本最優點
- 進入收益遞減區間的起點，準確率與穩定性基本收斂。
- 與 10 輪相比，增益不明顯，但計算/時間成本顯著更低。
10 輪：與 5 輪接近
- 指標接近 5 輪，差異在統計誤差範圍內。
- 成本約為 5 輪的 2 倍（推理費用、時間佔用、併發管理）。
10 輪以上：可能出現負面影響
- 過擬合於“特定審核員口徑/特定樣本簇”，提示詞變窄。
- 對跨天、跨審核員、跨語種的泛化能力略有下降。

結論：在成本—收益的綜合考量下，我們選擇 5 輪作為生產建議，並給出實踐區間 5–8 輪（8 輪用於更嚴格的場景/關鍵上線前的穩健性校驗）。

版本對比

Temperature 調參經驗

在我們反覆調提示詞的過程中，發現 temperature 參數對結果影響較大。

在調試和實驗階段
我們會把 temperature 開得比較高，大概在 8–1.0。這樣模型會更“活躍”，能從不同角度去理解文本。比如：
- 二次元梗、諷刺話語、跨語種甚至夾雜 emoji 的內容，高 temperature 下模型能給出更多解釋；
- 這對我們來説很有幫助，可以暴露提示詞裏沒考慮到的邊角情況，方便我們快速改進。
在真正上線的時候
我們把 temperature 拉到 0–0.1。
- 這樣模型輸出會盡量固定，不會同一條內容前後給出不一樣的結果；
- 對審核業務來説，穩定和可解釋比“有創造力”要重要得多。

所以我們的做法是：調試階段高 temperature ，生產環境低 temperature，既能探索問題，也能保證上線穩定。

實驗結果（口徑與噪聲説明）

整體準確率：81%
正向召回準確率（合規判定）：76%
負向召回準確率（違規判定）：90%

評估口徑與數據噪聲：

基準為客户提供的人工審核數據；多人、分多日完成，未建立雙盲複核，口徑存在天然不一致。
因此 81% 的一致性，已經接近甚至可能超過多人人工的穩定水平。
在多語言與灰色語境（玩梗、反諷）上，ReAct 提示詞顯著降低了隨機誤判，並提升了跨語言一致性。

代表性案例（模擬真實數據）

工程實現要點

核心代碼

def process_file_validation(file_path, prompt_template, client, model_id, temperature, max_tokens, logger):
    """Process a single file for validation and return results"""
    file_name = os.path.basename(file_path)
    
    logger.info(f"Validating file: {file_name}")
    
    try:
        df = pd.read_excel(file_path, engine='openpyxl')
        
        # Processing Excel data
        # ...
        
        results = []
        
        # Counters for detailed metrics
        metrics = {
            "total": len(data),
            "pass_samples": 0,
            "reject_samples": 0,
            "pass_correct": 0,
            "reject_correct": 0,
            "category_metrics": defaultdict(lambda: {"total": 0, "correct": 0})
        }
        
        for item in tqdm(data, desc=f"Processing {file_name}"):
            # ...
            # Format the prompt with the current text
            prompt = prompt_template.format(text=text)
            
            # Get model response
            response = invoke_claude(client, prompt, model_id, temperature, max_tokens, logger)
            
            # Extract prediction (0 or 1) from response
            if response:
                # Look for Pass/Reject indicators in the response
                lower_response = response.lower()
                
                # Check for explicit "Pass" or "Reject" in the response

                # Check for numeric indicators
                
                # Default to Reject if unclear
                    
                is_correct = pred_label == true_label
                if is_correct:
                    if true_label == 1:
                        metrics["pass_correct"] += 1
                    else:
                        metrics["reject_correct"] += 1
                        metrics["category_metrics"][category]["correct"] += 1
                    
                results.append({
                    "text": text,
                    "true_label": true_label,
                    "pred_label": pred_label,
                    "is_correct": is_correct,
                    "response": response,
                    "category": category,
                    "source_file": file_name
                })
            
            # Add a small delay to avoid rate limiting
            time.sleep(0.5)
        
        # Calculate metrics
        # ...
        
        logger.info(f"Completed {file_name}: Accuracy={metrics['accuracy']:.4f}, "
                   f"Pass={metrics['pass_accuracy']:.4f}, Reject={metrics['reject_accuracy']:.4f}")
        
        return file_name, results, metrics
        
    except Exception as e:
        logger.error(f"Error processing file {file_path}: {e}")
        return file_name, [], {"error": str(e)}

1) 日誌與可追溯性

目的：記錄每個文件、每條樣本的判定與指標，支撐問題回溯。
實踐要點：
- 文件 + 控制枱雙通道日誌；
- 關鍵信息結構化輸出（accuracy、pass/reject、category 指標）；
- 每輪/每版本生成獨立 log 文件，便於對比。

2) 數據裝載與多文件批處理

Excel 列位處理：文本、標籤列提取。
要點：
- 統一 label 口徑：Pass → 1 / Reject → 0；
- 類別精度：對 Reject 的類別進行單獨統計，便於發現“弱類”。

3) 大模型調用與推理參數（使用botocore調用Bedrock）

默認參數：temperature=0.0、max_tokens=1000，確保可重複與穩定輸出， max_tokens過大對效果影響有限;
超時/ 重試：botocore.config.Config中設置connect_timeout/read_timeout/retries；

4) 提示詞模板與佔位

通過prompt_template.format(text=...) 注入樣本正文。
建議：模板內統一約束唯一 JSON 輸出，便於解析；輸出前置 ReAct 步驟（語言識別、關鍵詞提取、類別匹配、最終判定）。

5) 併發驗證與節流

多文件並行：ThreadPoolExecutor 按文件粒度併發；
速率控制：time.sleep(0.5) 做基礎節流，避免限流，注意您Amazon Web Service賬號內Quota；

6) 評估與報表

輸出四個 Sheet：Results / Overall Metrics / File Metrics / Category Metrics + Prompt。
好處：
- Category Metrics 能快速定位薄弱類別；
- Prompt 留存使版本可復現；
- 結合日誌快速回放異常樣本。

評估口徑：統一使用“與人工標註的一致性”為主指標（Overall/Pass/Reject accuracy + Category accuracy），並在文中顯式聲明標註噪聲與“多審核員/多日/未複核”的現實約束。

經驗總結（針對輪數選擇與成本）

建議輪數：5–8 輪；5 輪用於大多數生產場景，8 輪用於上線前穩健性校驗。
避免過擬合：10 輪以上容易對某些審核員口徑或小樣本簇過擬合，泛化變差。
成本優化：
- 串並結合：文件級並行 + 樣本級節流；
- 固定 temperature，保證一致性，減少“返工輪”；
- 對類別分層抽樣做小集評估，優先修“弱類”，再全量回歸。
- 在最終工程化實施時，可以將提示詞放到system prompt中，同時開啓cache，以降低成本。
JSON 僅輸出與解析健壯性
- 強調輸出格式的規範化，降低對輸出結果的不統一增加生產系統的不確定性。
- 部分提示詞

輸出

落地經驗

在整個項目落地的過程中，我們積累了幾條關鍵經驗：

提示詞必須貼合業務標註體系: 通用的“內容安全”提示詞遠遠不夠。只有結合客户的 10 類違規分類，並不斷對照人工審核樣本修正，才能讓模型輸出結果和業務口徑保持一致。
ReAct 框架帶來了可解釋性: 模型先進行“思考”，再給出“行動”，讓每一步邏輯更加透明。我們可以展示模型的推理邏輯（語言識別、關鍵詞提取、類別匹配），增強了審核結論的可信度。
數據質量是上限，提示詞優化是下限: 我們使用的人工審核數據存在多人、分多日完成、缺乏複核等問題，導致標註結果本身帶有噪聲。在這種情況下，模型的準確率“天花板”就會受到影響。換句話説，提示詞優化能逼近人工水平，但要進一步突破，還需要客户改善數據標註流程。
成本與效果的權衡: 我們在實驗中驗證了 3、5、10 輪迭代的差異，最終選擇 5 輪作為最優點。同樣地，temperature 參數在調優階段設置高值，在上線階段鎖定低值，也是平衡創造性與穩定性的工程實踐。

未來優化方向

1、自動化提示詞優化

引入 AutoPrompt、RLHF 等方法，讓提示詞進化不再完全依賴人工試錯。
在更多語言、更多語境下持續收斂。

2、更細粒度的分類與標籤

客户的 10 類違規類別是第一層級。
後續可以擴展子類別（如“仇恨言論 → 針對性別 / 種族 / 職業”），滿足更精細化的內容治理需求。

3、 成本優化

會結合Bedrock的cache特性，增加對system prompt、user prompt的cache，在保證審核效果的情況下，儘可能優化成本。
成本詳情請參閲Amazon Bedrock成本頁面（https://aws.amazon.com/cn/bedrock/pricing/）與Claude模型成本頁面（https://docs.claude.com/zh-CN/docs/about-claude/pricing）

結語

從最初的“誤判頻發”，到最終實現 81% 的整體準確率，我們通過 提示詞工程 + ReAct 框架 + 工程化架構，幫助客户構建了一套 穩定、可觀測、可擴展 的遊戲社區審核系統。

這個過程的價值在於：

它不僅是一次模型調優嘗試，而是一套 可工程化複製的方法論；
在 UGC 社區、社交平台、直播審核 等場景，都可以直接複用這套 提示詞優化 + 架構閉環 的方案；
通過 日誌、判例庫、藍綠部署 等工程實踐，我們讓審核系統具備了 一致性、可追溯性和快速迭代能力。

最終，這個項目讓我們看到了 大語言模型 + 工程化落地 在內容審核領域的潛力：

提示詞調優 讓模型快速逼近甚至超越人工審核的一致性；
工程化架構 確保系統在 高併發、大規模多語言 審核場景下依舊穩定運行；
端到端閉環 使審核系統不僅能解決當下問題，還能通過數據迴流不斷自我進化。

*前述特定亞馬遜雲科技生成式人工智能相關的服務目前在亞馬遜雲科技海外區域可用。亞馬遜雲科技中國區域相關雲服務由西雲數據和光環新網運營，具體信息以中國區域官網為準。

本篇作者

本期最新實驗《多模一站通 —— Amazon Bedrock 上的基礎模型初體驗》
✨ 精心設計，旨在引導您深入探索Amazon Bedrock的模型選擇與調用、模型自動化評估以及安全圍欄(Guardrail)等重要功能。無需管理基礎設施，利用亞馬遜技術與生態，快速集成與部署生成式AI模型能力。
⏩️[點擊進入實驗] 即刻開啓 AI 開發之旅
構建無限, 探索啓程！

亞馬遜雲開發者博客

亞馬遜雲開發者博客

博客 / 詳情