LLM输出限制 - 探测窗口算法与状态机在AI面试Agent中的应用#

引言#

在构建 AI 面试 Agent 时，一个核心挑战是如何确保 LLM 的输出质量。LLM 输出的不确定性（幻觉、格式错误、截断等）会直接影响面试体验。本文探讨两种核心方法：扩展状态机（Extended State Machine） 和 探测窗口算法（Detection Window），以及它们在 AI-Interview 项目中的实际应用。

核心问题：LLM 输出为何需要限制#

LLM 输出失败可分为四类：

类型	描述	示例
格式类	JSON 解析失败、schema 不匹配	`{"name": "error}` 缺少引号
内容类	幻觉回答、偏离问题、敏感词	回答与问题无关
状态类	空输出、截断输出、超时	streaming 中断
语义类	逻辑矛盾、循环回答、自我矛盾	前后回答冲突

传统的做法是重试机制：输出失败就重新调用 LLM。但这种方法效率低下，尤其在流式输出场景下，用户已经看到了部分内容。

方法一：扩展状态机#

核心思想#

状态机将面试流程建模为离散的、有穷的、互斥的状态。每个状态转换都有明确的触发条件和动作。

1
┌─────────┐    submit_answer    ┌─────────┐
2
│ WAITING │ ──────────────────> │ EVALUATING │
3
└─────────┘                     └─────────┘
4
                                      │
5
                              deviation_score
6
                    ┌─────────────────┼─────────────────┐
7
                    ▼                 ▼                 ▼
8
             ┌──────────┐      ┌──────────┐       ┌──────────┐
9
             │ CORRECT  │      │ GUIDANCE │       │ CORRECTION│
10
             └──────────┘      └──────────┘       └──────────┘

优点#

可预测性强：状态轨迹清晰，每个转换都可追踪
可视化友好：便于调试和问题定位
流程可控：异常恢复逻辑清晰

缺点#

状态爆炸：随着业务复杂度的增加，状态数量指数级增长
不适合细粒度检测：只能在状态转换点检测，无法在流式输出中实时检测
层次不清：当检测逻辑与流程逻辑混在一起时，代码难以维护

InterviewState 示例#

1
@dataclass(frozen=True)
2
class InterviewState:
3
    session_id: str
4
    resume_id: str
5

6
    # 当前面试进度
7
    current_series: int = 1
8
    current_question: Optional[Question] = None
9
    current_question_id: Optional[str] = None
10

11
    # 追问链追踪
12
    followup_depth: int = 0
13
    max_followup_depth: int = 3
14
    followup_chain: list[str] = field(default_factory=list)
15

16
    # 回答记录
17
    answers: dict[str, Answer] = field(default_factory=dict)
18
    feedbacks: dict[str, Feedback] = field(default_factory=dict)
19

20
    # 状态
21
    error_count: int = 0
22
    phase: Literal["init", "warmup", "initial", "followup", "final_feedback"] = "init"

状态机通过 phase 字段追踪面试阶段，每个阶段有明确的进入条件和退出条件。

方法二：探测窗口算法#

核心思想#

探测窗口是数据流 + 管道过滤的架构，将输出检测组织为多层独立的”窗口”，每个窗口专注特定类型的检测。

1
┌──────────────────────────────────────────────────────────────┐
2
│                    LLM Output Stream                         │
3
└──────────────────────────────────────────────────────────────┘
4
                              │
5
                              ▼
6
┌──────────────────────────────────────────────────────────────┐
7
│  Window 1: Format Detection (快速失败)                        │
8
│  - JSON 语法检测                                              │
9
│  - Schema 结构检测                                            │
10
│  - 是否为空/截断                                               │
11
└──────────────────────────────────────────────────────────────┘
12
                              │
13
                              ▼
14
┌──────────────────────────────────────────────────────────────┐
15
│  Window 2: Safety Detection (安全检测)                        │
16
│  - 敏感词过滤                                                 │
17
│  - 政治敏感内容                                               │
18
│  - 恶意代码检测                                               │
19
└──────────────────────────────────────────────────────────────┘
20
                              │
21
                              ▼
22
┌──────────────────────────────────────────────────────────────┐
23
│  Window 3: Semantic Validation (语义合法性)                   │
24
│  - LLM 驱动的语义检测                                         │
25
│  - 幻觉判断                                                   │
26
│  - 逻辑一致性                                                 │
27
└──────────────────────────────────────────────────────────────┘
28
                              │
29
                              ▼
30
┌──────────────────────────────────────────────────────────────┐
31
│  Window 4: Quality Scoring (质量评分)                         │
32
│  - 回答完整度                                                 │
33
│  - 与问题的相关性                                             │
34
│  - 偏离度评分                                                 │
35
└──────────────────────────────────────────────────────────────┘

优点#

关注点分离：每层窗口独立职责，易于扩展
增量检测：可以在流式输出中边生成边检测，快速失败
适合多阶段验证：从格式到语义，分层过滤

缺点#

状态模糊：数据流没有明确的状态边界
调试复杂：问题可能在多个窗口间传递，难以定位
延迟累加：每个窗口都有处理延迟

架构对比：老版 vs 新版#

老版 InterviewService 架构#

单 Agent 流程，状态机控制整体流程，探测窗口验证输出：

1
┌─────────────────────────────────────────────────────────────┐
2
│                    InterviewService                          │
3
├─────────────────────────────────────────────────────────────┤
4
│                                                             │
5
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐ │
6
│  │ Format       │───>│ Schema        │───>│ Safety       │ │
7
│  │ Window       │    │ Window        │    │ Window       │ │
8
│  └──────────────┘    └──────────────┘    └──────────────┘ │
9
│         │                  │                  │           │
10
│         └──────────────────┼──────────────────┘           │
11
│                            ▼                                │
12
│                  ┌──────────────────┐                     │
13
│                  │   State Machine   │                     │
14
│                  │  (Phase Control)  │                     │
15
│                  └──────────────────┘                     │
16
│                            │                                │
17
│                            ▼                                │
18
│                  ┌──────────────────┐                     │
19
│                  │   LLM Service    │                     │
20
│                  └──────────────────┘                     │
21
└─────────────────────────────────────────────────────────────┘

新版 Orchestrator + ReviewAgent 架构#

多 Agent 协作，Orchestrator 负责路由和流程控制（状态机），ReviewAgent 通过 LLM 驱动检测：

1
┌─────────────────────────────────────────────────────────────┐
2
│                   Orchestrator (LangGraph)                   │
3
├─────────────────────────────────────────────────────────────┤
4
│                                                             │
5
│  ┌────────────┐    ┌────────────┐    ┌────────────┐       │
6
│  │ Question   │───>│ Evaluate   │───>│ Review     │       │
7
│  │ Agent      │    │ Agent      │    │ Agent      │       │
8
│  └────────────┘    └────────────┘    └────────────┘       │
9
│         │                │                  │               │
10
│         │                ▼                  ▼               │
11
│         │         ┌────────────────────────────┐           │
12
│         │         │    LLM-driven Detection     │           │
13
│         │         │  (替代规则驱动的探测窗口)     │           │
14
│         │         └────────────────────────────┘           │
15
│         │                        │                         │
16
│         └────────────────────────┼─────────────────────────┘
17
│                                  ▼                          │
18
│                    ┌──────────────────────┐               │
19
│                    │  Feedback Loop        │               │
20
│                    │  (无效输出→重试/降级)   │               │
21
│                    └──────────────────────┘               │
22
└─────────────────────────────────────────────────────────────┘

核心区别#

维度	老版架构	新版架构
架构模式	单 Agent + 规则引擎	多 Agent 协作 (Orchestrator)
检测方式	规则驱动 (Regex/Schema)	LLM 驱动 (语义理解)
流程控制	状态机硬编码	Graph 路由 + 条件边
扩展方式	增加规则	增加 Agent 节点
反馈机制	直接重试	降级 + ReviewAgent 判断

核心结论：混合架构#

两者结合是最佳实践：

场景	推荐方案	原因
面试流程阶段控制	State Machine	阶段明确、转换可控
LLM 输出质量检测	Detection Window	分层过滤、增量检测
异常恢复流程	State Machine	状态明确、动作确定
流式输出边生成边检测	Detection Window	快速失败、及时截断

1
┌─────────────────────────────────────────────────────────────┐
2
│                     Hybrid Architecture                      │
3
├─────────────────────────────────────────────────────────────┤
4
│                                                             │
5
│   ┌─────────────────────────────────────────────────────┐   │
6
│   │  Orchestrator (State Machine)                       │   │
7
│   │  - 流程阶段控制                                      │   │
8
│   │  - 路由决策                                          │   │
9
│   │  - 异常恢复                                          │   │
10
│   └─────────────────────────────────────────────────────┘   │
11
│                            │                                │
12
│                            ▼                                │
13
│   ┌─────────────────────────────────────────────────────┐   │
14
│   │  ReviewAgent (Detection Window)                      │   │
15
│   │  - Format/Schema 检测                                │   │
16
│   │  - Safety 检测                                       │   │
17
│   │  - Semantic 验证                                     │   │
18
│   └─────────────────────────────────────────────────────┘   │
19
│                            │                                │
20
│                            ▼                                │
21
│   ┌─────────────────────────────────────────────────────┐   │
22
│   │  Feedback Loop                                      │   │
23
│   │  - 无效输出 → 重试/降级                               │   │
24
│   │  - 降级策略：简化 prompt、减少要求                    │   │
25
│   └─────────────────────────────────────────────────────┘   │
26
│                                                             │
27
└─────────────────────────────────────────────────────────────┘

探测窗口算法设计要点#

三阶段处理策略#

1
async def process_llm_output(streaming_output):
2
    # Stage 1: 快速失败检测 (同步，阻塞式)
3
    format_result = await check_format_window(streaming_output)
4
    if format_result.is_invalid:
5
        return await fast_fail(format_result.error)
6

7
    # Stage 2: 语义合法性检测 (异步，可等待)
8
    semantic_result = await check_semantic_window(streaming_output)
9
    if semantic_result.is_invalid:
10
        return await handle_semantic_failure(semantic_result)
11

12
    # Stage 3: 降级与恢复
13
    if semantic_result.needs_human_review:
14
        await escalate_to_human(semantic_result)
15

16
    return StreamingResult(status="valid", content=streaming_output)

可观测性设计#

每个无效输出都应记录，用于后续分析和优化：

1
@dataclass
2
class OutputValidationRecord:
3
    timestamp: datetime
4
    output_type: str  # "question", "feedback", "evaluation"
5
    validation_stage: str  # "format", "safety", "semantic"
6
    is_valid: bool
7
    error_message: Optional[str]
8
    deviation_score: Optional[float]
9
    retry_count: int

方法三：滑动窗口算法#

核心思想#

滑动窗口（Sliding Window）是一种动态数据处理范式，与静态的探测窗口不同，它在时间/字数维度上保持一个”窗口”，随数据流入不断滑动，适用于需要时序分析和趋势检测的场景。

1
┌─────────────────────────────────────────────────────────────────┐
2
│              Detection Window (静态/管道式)                       │
3
│                                                               │
4
│   Input ──► [Window A] ──► [Window B] ──► [Window C] ──► Output │
5
│                                                               │
6
│   特点：每个窗口接收完整输入，逐层过滤，无状态保留                │
7
└─────────────────────────────────────────────────────────────────┘
8

9
┌─────────────────────────────────────────────────────────────────┐
10
│              Sliding Window (滑动/增量式)                        │
11
│                                                               │
12
│   ┌──┬──┬──┬──┬──┬──┬──┐                                     │
13
│   │D1│D2│D3│D4│D5│D6│D7│  ───► 时间/字数轴                      │
14
│   └──┴──┴──┴──┴──┴──┴──┘                                     │
15
│        └──────┐                                                    │
16
│         Window Size = 4 (当前窗口)                               │
17
│                                                               │
18
│   每滑动一次：淘汰最旧 1个，加入最新 1个 = 增量更新               │
19
└─────────────────────────────────────────────────────────────────┘

滑动窗口的三种类型#

类型	窗口大小	应用场景
Tumbling Window	固定大小，不重叠	批量统计、离线分析
Sliding Window	固定大小，重叠滑动	实时检测、流式报警
Session Window	动态大小，活动触发	用户会话、事件序列

在 LLM 输出检测中的实际应用#

场景 1: 流式输出的字数滑动窗口#

1
class SlidingWindowDetector:
2
    """检测 LLM 输出是否在合理字数范围内"""
3

4
    def __init__(self, min_words=10, max_words=500, slide_step=5):
5
        self.min_words = min_words
6
        self.max_words = max_words
7
        self.slide_step = slide_step
8
        self.word_counts = []  # 滑动窗口记录
9

10
    def process_token(self, new_token: str) -> DetectionResult:
11
        self.word_counts.append(len(new_token.split()))
12

13
        # 窗口超过最大大小时，移除最旧的
14
        if len(self.word_counts) > self.max_words:
15
            self.word_counts.pop(0)
16

17
        # 检查当前窗口均值是否异常
18
        if len(self.word_counts) >= self.min_words:
19
            avg = sum(self.word_counts) / len(self.word_counts)
20
            if avg < 2:  # 平均每 token 词数过低，可能是截断
21
                return DetectionResult.invalid("output_truncated")
22

23
        return DetectionResult.valid()

场景 2: 时间滑动窗口检测幻觉#

1
class HallucinationSlidingWindow:
2
    """基于时间窗口的幻觉检测"""
3

4
    def __init__(self, time_window_seconds=30, max_new_entities=5):
5
        self.time_window = time_window_seconds
6
        self.max_new_entities = max_new_entities
7
        self.entity_timeline = []  # (timestamp, entity_name)
8

9
    def process_output(self, output: str, timestamp: datetime):
10
        entities = self.extract_entities(output)
11

12
        # 添加时间戳到时间线
13
        for entity in entities:
14
            self.entity_timeline.append((timestamp, entity))
15

16
        # 移除超过窗口期的记录
17
        cutoff = timestamp - timedelta(seconds=self.time_window)
18
        self.entity_timeline = [
19
            (ts, e) for ts, e in self.entity_timeline
20
            if ts > cutoff
21
        ]
22

23
        # 检查窗口内新实体数量
24
        new_entities = set(e for ts, e in self.entity_timeline if ts == timestamp)
25
        if len(new_entities) > self.max_new_entities:
26
            return DetectionResult.invalid(
27
                f"possible_hallucination: {len(new_entities)} new entities in {self.time_window}s"
28
            )
29

30
        return DetectionResult.valid()

场景 3: 语义一致性的滑动窗口#

1
class SemanticConsistencySlidingWindow:
2
    """检测回答序列的语义一致性"""
3

4
    def __init__(self, window_size=3, consistency_threshold=0.6):
5
        self.window_size = window_size
6
        self.threshold = consistency_threshold
7
        self.answer_history = []
8

9
    def check_consistency(self, new_answer: str) -> ConsistencyResult:
10
        embedding = self.get_embedding(new_answer)
11
        self.answer_history.append(embedding)
12

13
        # 维持固定窗口大小
14
        if len(self.answer_history) > self.window_size:
15
            self.answer_history.pop(0)
16

17
        # 计算窗口内相邻回答的相似度
18
        if len(self.answer_history) >= 2:
19
            similarities = []
20
            for i in range(len(self.answer_history) - 1):
21
                sim = cosine_similarity(
22
                    self.answer_history[i],
23
                    self.answer_history[i+1]
24
                )
25
                similarities.append(sim)
26

27
            avg_similarity = sum(similarities) / len(similarities)
28

29
            # 相似度骤降可能是矛盾信号
30
            if avg_similarity < self.threshold:
31
                return ConsistencyResult.inconsistent(
32
                    f"similarity_drop: {avg_similarity:.2f} < {self.threshold}"
33
                )
34

35
        return ConsistencyResult.consistent()

与探测窗口的核心区别#

维度	Detection Window	Sliding Window
数据保留	仅保留当前处理的数据	保留窗口内历史数据
计算方式	单次计算	增量更新
适用场景	格式化检测、schema 验证	时序分析、趋势检测
状态管理	无状态	有状态（滑动历史）
延迟	低（无需维护历史）	中等（需维护窗口）

综合架构：三种方法协同#

1
流式 LLM 输出检测架构：
2

3
┌──────────────────────────────────────────────────────────────┐
4
│                    LLM Output Stream                         │
5
└──────────────────────────────────────────────────────────────┘
6
                              │
7
                              ▼
8
┌──────────────────────────────────────────────────────────────┐
9
│  Sliding Window Layer 1: 格式/字数监控                        │
10
│  - 实时检测截断、空输出                                       │
11
│  - 字数异常报警                                              │
12
└──────────────────────────────────────────────────────────────┘
13
                              │
14
                              ▼
15
┌──────────────────────────────────────────────────────────────┐
16
│  Sliding Window Layer 2: 语义一致性监控                       │
17
│  - 回答序列矛盾检测                                          │
18
│  - 主题漂移检测                                              │
19
└──────────────────────────────────────────────────────────────┘
20
                              │
21
                              ▼
22
┌──────────────────────────────────────────────────────────────┐
23
│  Detection Window Layer: 规则/Schema 验证                     │
24
│  - JSON 格式检查                                             │
25
│  - 敏感词过滤                                                │
26
└──────────────────────────────────────────────────────────────┘
27
                              │
28
                              ▼
29
                    ┌──────────────────┐
30
                    │  State Machine   │
31
                    │  (反馈环控制)     │
32
                    └──────────────────┘

实战经验总结#

1. 状态机适用场景#

在 AI-Interview 项目中，InterviewState.phase 字段使用状态机模式：

init → warmup：初始化后进入热身阶段
warmup → initial：热身结束，开始正式提问
initial → followup：基于偏差分数决定是否追问
任何阶段 → final_feedback：面试结束

2. 探测窗口适用场景#

ReviewAgent 的反馈生成采用探测窗口思想：

1
# 不同偏差分数触发不同类型的反馈
2
if deviation_score < 0.3:
3
    feedback_type = FeedbackType.CORRECTION  # 直接纠错
4
elif deviation_score < 0.6:
5
    feedback_type = FeedbackType.GUIDANCE    # 引导性追问
6
else:
7
    feedback_type = FeedbackType.COMMENT      # 正面点评

3. 混合架构实践#

OrchestratorAdapter 展示了如何结合两者：

1
async def submit_answer(self, user_answer: str, question_id: str) -> QAResponse:
2
    # 1. 状态机：更新状态
3
    self.state.answers[question_id] = answer
4

5
    # 2. Graph 调用（内部包含 ReviewAgent 的检测逻辑）
6
    result = await self.graph.ainvoke(self.state)
7

8
    # 3. 基于检测结果决定下一步
9
    if self.state.next_action == "question_agent":
10
        # 生成下一个问题
11
        ...

总结#

维度	状态机	探测窗口	滑动窗口
核心抽象	状态 + 转换	数据流 + 管道过滤	时间维度 + 增量更新
检测时机	状态转换点	持续流入/流出	滑动过程中实时
适用检测	流程合规性	输出质量（一次性）	输出质量（时序/趋势）
失败恢复	明确的状态转移	多级降级策略	窗口重置
调试体验	轨迹清晰	需要可观测性工具	需要窗口状态监控
典型应用	阶段切换	Format/Safety 检测	截断检测、幻觉检测

最佳实践是三层混合架构：

状态机：控制面试流程阶段（init → warmup → initial → followup → final_feedback）
滑动窗口：实时检测流式输出的时序异常（截断、幻觉、一致性）
探测窗口：对完整输出进行规则/语义验证（JSON 格式、敏感词、Schema）

这种架构在 AI-Interview 项目中经过验证，能够有效处理 LLM 输出的不确定性，同时保持系统的可维护性和可扩展性。