# 验证3：括号注释格式过滤

一、为什么选 LangGraph？

传统 LLM 应用大多是"一次 Prompt 出结果"的单轮模式。但高质量翻译是一个多阶段、可回退、需要全局状态协调的复杂流程——这恰好是 LangGraph 的核心设计目标：

需求	LangGraph 能力
多步骤串行	StateGraph + add_edge
条件分支/回退	add_conditional_edges
全局状态共享	TypedDict State
并发处理 Chunk	节点内 asyncio.gather
异步执行	graph.ainvoke()

---

二、状态定义：翻译流程的"数据总线"

LangGraph 的核心理念是所有节点共享同一个 State。我们定义了两层状态结构：

class ChunkState(TypedDict):chunk_id: strsource_text: strterminology: Dict          # Step1 识别的术语映射literal_translation: str   # Step2 直译结果self_review: Dict          # Step3 自审报告final_translation: str     # Step4 意译定稿status: str                # pending | running | translated | reviewed | polished | failedretry_count: intclass TranslateState(TypedDict):session_id: strsource_lang: strtarget_lang: strdomain: Optional[str]      # legal / medical / tech / literaturemodel: str                 # 用户指定模型source_text: strchunks: List[ChunkState]global_terminology: Dict   # 跨 Chunk 统一术语表final_result: stroverall_status: strsse_queue: List[Dict]error_message: Optional[str]token_usage: Dictstart_time: float

设计要点：

1. Chunk 粒度状态机：每个 Chunk 有独立的 status 字段，允许不同 Chunk 处于不同阶段（如 Chunk A 已在审校，Chunk B 还在直译）。
2. 全局术语表 + 局部术语表：global_terminology 由全文提取得到，每个 Chunk 的 terminology 是全局+局部的合并（局部优先），保证跨段术语一致性。
3. SSE 事件队列：sse_queue 用于前端实时推送，每个节点在处理过程中主动推送进度事件。

---

三、图构建：六节点 + 条件回退

[Start] → [chunk_split] → [step1_terminology] → [step2_literal] → [step3_review]↑              ↓|       [需要修订?]|       ↓         ↓└──[step2_literal]  [step4_polish]↓[aggregate] → [END]

核心构建代码：

def build_translation_graph():builder = StateGraph(TranslateState)builder.add_node("chunk_split", split_into_chunks)builder.add_node("step1_terminology", step1_terminology)builder.add_node("step2_literal", step2_literal)builder.add_node("step3_review", step3_review)builder.add_node("step4_polish", step4_polish)builder.add_node("aggregate", aggregate_node)builder.set_entry_point("chunk_split")builder.add_edge("chunk_split", "step1_terminology")builder.add_edge("step1_terminology", "step2_literal")builder.add_edge("step2_literal", "step3_review")# 条件边：自审不通过则回退到直译builder.add_conditional_edges("step3_review",needs_revision,{"step2_literal": "step2_literal", "step4_polish": "step4_polish"})builder.add_edge("step4_polish", "aggregate")builder.add_edge("aggregate", END)return builder.compile()

条件边的核心逻辑

def needs_revision(state: TranslateState) -> str:for chunk in state.get("chunks", []):self_review = chunk.get("self_review", {})if self_review.get("needs_revision", False):if chunk.get("retry_count", 0) < 2:  # 最多回退 2 次chunk["retry_count"] = chunk.get("retry_count", 0) + 1chunk["status"] = "pending"return "step2_literal"   # 回退到直译return "step4_polish"               # 审校通过，进入意译

关键决策：

• 回退粒度：只要任一 Chunk 需要修订，就整体回退到直译。这看似粗暴，但保证了修订时所有 Chunk 都能拿到最新术语表。
• 重试上限 = 2：防止无限循环。LLM 的输出有随机性，2 次重试已足够让模型"自我修正"。
• 回退时重置状态：chunk["status"] = "pending" 确保直译节点能重新处理该 Chunk。

---

四、节点深度解析

4.1 文本切分（chunk_split）

这不是简单的 split("\n\n")，而是一个三级切分策略：

原文 → 段落边界切分 → 超长段落按句子切分 → 相邻 Chunk 重叠窗口（50 tokens）

Token 估算公式（针对中英文混合场景）：

def estimate_tokens(text: str) -> int:chinese_chars = sum(1 for c in text if '\u4e00' <= c <= '\u9fff')english_chars = sum(1 for c in text if c.isascii() and c.isalnum())return int(chinese_chars * 1.5 + english_chars * 0.25)

为什么中文字符 × 1.5？ 因为主流 Tokenizer（如 tiktoken）中，一个中文字符通常消耗 1~2 个 token，取 1.5 是一个偏保守的均值估计，避免 Chunk 超过模型上下文窗口。

4.2 术语识别（step1_terminology）

采用全局 + 局部双层提取：

1. 全局提取：取前 2000 字符做全文术语扫描，生成 global_terminology
2. 局部补充：对每个 Chunk 并发提取局部术语，与全局合并

术语验证逻辑（防止 LLM 幻觉）：

# 验证1：原文和译文不能相同
if source_term.strip().lower() == translation.strip().lower():continue# 验证2：译文不应包含原文（避免 "prompt（提示词）" 这种格式）
if source_term.lower() in translation.lower() and len(source_term) > 3:continue# 验证3：括号注释格式过滤
if re.search(re.escape(source_term) + r'\s*[（(]', translation):continue

这三层验证在生产环境中极其重要——LLM 在术语提取时经常偷懒，直接输出 "token（token）" 或原封不动的术语。

4.3 直译（step2_literal）

直译节点的核心是严格遵循术语表：

• 每个 Chunk 的 Prompt 中注入了该 Chunk 的术语表（JSON 格式）
• 修订模式下，还会注入上一轮的审校意见，让模型针对性修正

兜底策略：直译失败时，使用原文作为 literal_translation，避免后续流程中断。这是生产系统的核心原则——降级优于崩溃。

4.4 自审（step3_review）

让 LLM 扮演"审校者"，从 5 个维度打分：

维度	说明
准确性	信息是否遗漏或错误
术语一致性	术语翻译是否统一
语法流畅度	目标语言语法是否正确
格式保留	原文格式是否完整保留
文化适应性	是否存在文化冲突

修订触发条件：overall_score < 6.0 或存在 critical 级别问题。

审校结果是一个结构化 JSON，包含 issues 列表，每个 issue 有 severity、category、description、suggestion 四个字段——这些会被原封不动地传给直译节点作为修订依据。

4.5 意译定稿（step4_polish）

意译是整个流程中 temperature 最高 的步骤（0.5 vs 直译的 0.3 vs 术语的 0.2），因为润色需要更多"创造性"。

输入同时包含：直译结果 + 审校意见 + 术语表。模型需要在准确性约束下最大化自然度。