Testando IA de Borda com uma ferramenta MCP: mk-qa-master e YOLO

Por Jack Kao — autor do mk-qa-master, uma ferramenta de QA nativa do MCP.

A maioria dos "testes de IA" para ao chamar uma API e afirmar que a resposta não está vazia. A IA de borda — um modelo rodando em um feed de câmera ao vivo — não se encaixa nesse molde. Você não pode afirmar coordenadas exatas de caixas delimitadoras (a saída é imprecisa por design), e "correto, mas 200ms tarde demais" é uma falha de produção, não um sucesso.

Quando adicionei o edge runner ao mk-qa-master na v1.1, eu queria que isso fizesse esse problema difícil parecer como escrever qualquer outro teste. Então, este post é eu testando: minha webcam do laptop → um stream RTSP → um modelo YOLOv8 → afirmações sobre IoU, throughput e latência p95 — tudo orquestrado através de chamadas de ferramentas do MCP, sem necessidade de Jetson.

O que é o edge runner

mk-qa-master é um servidor MCP: seu cliente de IA (Claude Code, Cursor, etc.) chama suas ferramentas para analisar, gerar e executar testes. Ele já vem com runners para pytest-playwright, jest, cypress, go, maestro, schemathesis… e a partir da v1.1, edge.

Altere uma variável de ambiente:

// a configuração do servidor MCP mk-qa-master
"env": { "QA_RUNNER": "edge" }

…e as mesmas ferramentas generate_test / run_tests agora falam RTSP + YOLO em vez de navegadores. A mesma memória muscular, domínio completamente diferente.

As quatro perguntas que um teste de borda deve responder

Um teste de IA de borda útil responde a todas essas perguntas ao mesmo tempo:

1. Corretude — o modelo detecta o que deveria?
2. Throughput — ele acompanha a taxa de quadros?
3. Latência — cada inferência é rápida o suficiente? (p95, não média.)
4. Robustez — quadros em branco/vazios produzem falsas detecções?

A corretude é a mais sutil. Duas execuções do mesmo modelo no mesmo quadro podem discordar por alguns pixels, então a corretude da detecção usa IoU (Interseção sobre União) contra uma caixa esperada com um limite (padrão 0.5). Você afirma "a caixa se sobrepõe o suficiente", nunca "a caixa é idêntica." mk-qa-master fornece isso como edge.metrics.match_detection.

O pipeline

A camada de teste quer um stream, não um identificador de dispositivo — então você conecta a câmera:

Câmera do MacBook
   │  ffmpeg (captura avfoundation)
   ▼
clip local  (5s — determinístico, reproduzível, sem surpresas de privacidade no CI)
   │  ffmpeg -re -stream_loop -1   (loop infinito)
   ▼
mediamtx  →  rtsp://127.0.0.1:8600/cam
   │  OpenCV VideoCapture
   ▼
YOLOv8n (LocalYolo)  →  afirmações de IoU / fps / latência  →  relatório pytest

Gravar um clip uma vez e reproduzi-lo via RTSP é o que torna isso determinístico — os mesmos quadros em cada execução, sem "por que falhou às 18h" dramas de iluminação. O edge runner realmente faz esse loop para você quando QA_RTSP_SOURCE aponta para um arquivo; eu vou mostrar a versão manual porque é mais clara:

# capture uma vez
ffmpeg -f avfoundation -framerate 30 -video_size 1280x720 \
       -i "0" -t 5 -pix_fmt yuv420p edge_demo.mp4

# servir em loop via mediamtx (mediamtx.yml: paths: { all_others: })
ffmpeg -re -stream_loop -1 -i edge_demo.mp4 \
       -c:v libx264 -preset ultrafast -tune zerolatency \
       -f rtsp rtsp://127.0.0.1:8600/cam

O fluxo de trabalho, como chamadas de ferramentas MCP

Esta é a parte da qual estou orgulhoso — toda a sessão é apenas ferramentas.

1. Confirme o runner. get_runner_info →

{ "current": "edge", "available": ["cypress","edge","go","jest","maestro","newman","pytest-playwright","schemathesis"] }

2. Probar o stream. analyze_stream(rtsp_url="rtsp://127.0.0.1:8600/cam") →

{
  "url": "rtsp://127.0.0.1:8600/cam",
  "width": 1280, "height": 720, "fps": 30.0,
  "labels": [],
  "candidate_tcs": [
    "o throughput geral deve ser >= o min_fps configurado",
    "a latência p95 de um único quadro deve ser <= o SLA de latência",
    "o stream reconecta após uma interrupção no meio do teste sem travar",
    "quadros vazios / sem alvo não geram detecções falsas positivas"
  ]
}

Note que ele retorna casos de teste candidatos específicos para o domínio de borda — da mesma forma que analyze_url retorna casos de teste de formulário/CTA para a web.

3. Gerar o teste. generate_test(...) escreve um esqueleto pytest conectado aos fixtures de borda (backend, stream, latency). O corpo permanece entediante de propósito.