AI Agent面试系统架构设计与实战：从并发处理到智能评估

1次阅读

共计 2970 个字符，预计需要花费 8 分钟才能阅读完成。

最近在做一个 AI Agent 面试系统的项目，发现传统面试系统在 AI 场景下会遇到很多新问题。这里总结下我们遇到的几个核心痛点：

高并发压力 ：线下面试顶多同时几十场，但 AI 面试可能瞬间涌入上万请求
评估准确性 ：人工面试可以察言观色，AI 需要处理语言歧义、文化差异等问题
延迟敏感 ：候选人等待超过 5 秒就可能流失，但复杂模型推理又很耗时
系统稳定性 ：评估服务崩溃不能影响面试流程，需要完善的容错机制

经过多次迭代，我们最终采用了这样的架构：

graph TD
    A[客户端] -->|HTTP| B(API Gateway)
    B -->| 负载均衡 | C[面试服务集群]
    C -->|Kafka| D[评估服务集群]
    D -->|gRPC| E[模型推理服务]
    E --> F[Redis 缓存]
    F --> G[MySQL 持久化]

关键组件分工：

面试服务 ：处理基础会话逻辑，状态维护
评估服务 ：调用 NLP 模型生成评分
消息队列 ：解耦服务，实现异步削峰
模型服务 ：GPU 加速的 BERT 模型推理

遇到第一个坑就是同步调用导致的雪崩。改进后的生产者代码：

@RestController
public class InterviewController {
    @Autowired
    private KafkaTemplate<String, String> kafkaTemplate;

    @PostMapping("/submit")
    public ResponseEntity<String> submitAnswer(@RequestBody AnswerDTO answer) {

        // 分区键使用用户 ID 保证同用户消息有序
        ListenableFuture<SendResult<String, String>> future = 
            kafkaTemplate.send("interview_answers", 
                answer.getUserId(), 
                JsonUtils.toJson(answer));

        future.addCallback(success -> log.info("消息发送成功: {}", success),
            ex -> {log.error("消息发送失败", ex);
                // 这里触发降级逻辑
                fallbackService.saveToLocal(answer);
            });

        return ResponseEntity.ok("已接收回答");
    }
}

消费者端的关键配置：

spring:
  kafka:
    consumer:
      group-id: evaluation-group
      auto-offset-reset: latest
      enable-auto-commit: false
    listener:
      ack-mode: MANUAL

用 gRPC 定义评估接口：

service EvaluationService {rpc BatchEvaluate (EvaluationRequest) returns (EvaluationResponse);
}

message EvaluationRequest {
    repeated string answers = 1;
    string position_id = 2;
}

message EvaluationResponse {
    message Result {
        float score = 1;
        map<string, float> dimension_scores = 2;
    }
    repeated Result results = 1;
}

服务端使用线程池处理批量请求：

class EvaluationServicer(evaluation_pb2_grpc.EvaluationServiceServicer):
    def __init__(self):
        self.model = load_bert_model()
        self.executor = ThreadPoolExecutor(max_workers=4)

    def BatchEvaluate(self, request, context):
        futures = []
        for answer in request.answers:
            future = self.executor.submit(
                self._evaluate_single,
                answer, request.position_id)
            futures.append(future)

        results = [f.result() for f in futures]
        return evaluation_pb2.EvaluationResponse(results=results)

配置 Hystrix 保护评估服务：

@HystrixCommand(
    fallbackMethod = "fallbackEvaluate",
    commandProperties = {@HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="5000"),
        @HystrixProperty(name="circuitBreaker.errorThresholdPercentage",value="50")
    })
public EvaluationResult evaluate(Answer answer) {
    // 调用 gRPC 远程服务
    return evaluationService.evaluate(answer);
}

// 降级逻辑：返回基础评分
public EvaluationResult fallbackEvaluate(Answer answer) {
    return new EvaluationResult(basicScoring(answer.getText()),
        Collections.emptyMap());
}

方案	QPS	P99 延迟	资源消耗
同步调用	120	3.2s	高
异步 + 批处理	2100	800ms	中
增加 GPU 节点	3500	500ms	低

发现评估服务的 GPU 利用率只有 30%，通过以下改进提升到 75%：

使用 TensorRT 优化 BERT 模型
调整批量大小到 16（需平衡延迟）
启用 CUDA Graph 减少内核启动开销

我们开发了自动扩容脚本：

#!/bin/bash

LAG=$(kafka-consumer-groups --bootstrap-server localhost:9092 \
    --describe --group evaluation-group | awk '{sum += $5} END {print sum}')

if [$LAG -gt 10000]; then
    # 触发 Kubernetes 扩容
    kubectl scale --replicas=10 deployment/evaluation-service
fi

采用双版本方案：