Pipeline de extração de áudio e vídeo

Meu pipeline de vídeo depende inteiro de fontes que não querem ser lidas.

Fala, pessoal!

Tô construindo um app que pega um vídeo de receita e devolve os ingredientes e o
passo a passo organizados. Quando eu conto isso, todo mundo acha que a parte
difícil é a IA. Não é. A parte de IA é a parte que deu certo logo e consigo validar com evals e samples.

O difícil é chegar no vídeo.

Queria compartilhar como eu penso esse pipeline hoje, sem entrar em detalhe de
implementação, porque as lições que eu tirei dele servem pra qualquer coisa que
dependa de terceiro instável. E hoje isso é quase tudo.

Não existe "o provedor"

Meu primeiro desenho tinha um provedor. Um só. Funcionou muito bem até o dia que
parou de funcionar, e quando ele parou o produto inteiro parou junto.

Hoje o pipeline não sabe quem busca o vídeo. Ele pede uma capacidade e alguém
atende. Atrás dessa capacidade tem uma fila de candidatos, e se o primeiro não
resolve o segundo tenta.

Ter vários providers não é o que importa. É o pipeline não conhecer nenhum deles pelo
nome. Trocar, remover ou adicionar candidato não deveria encostar na lógica de
negócio, e se encostar é porque o desenho tá errado.

A ordem da fila é empírica, não teórica

Eu montei a primeira ordem por preço. Mais barato primeiro, mais caro por último.
Pra mim que não tenho um centavo de investidor e não quero gastar rios de dinheiros caso o app dê muito certo é o mais importante agora.

Na prática a ordem certa é a que funciona. Um candidato de graça que quase sempre
falha não é barato. Ele é lento, ele gasta o seu tempo e ainda te deixa na mão no
final.

Hoje eu ordeno por taxa de sucesso real, medida, e preço é critério de desempate.
Essa ordem muda com o tempo e tudo bem que mude. Ela é um dado, não uma decisão de
arquitetura.

A parte que me custou mais caro

Esse é o motivo do título.

Eu tinha um candidato que me devolvia sucesso. Sem exceção, sem erro, arquivo
baixado, log todo verde. O pipeline seguia feliz, parava a fila ali mesmo e ia
processar o que recebeu.

Só que o que ele baixou não servia. Às vezes vinha um pedaço do meio do vídeo. Às
vezes vinha imagem sem áudio nenhum.

O erro só aparecia lá na frente, num passo que não tinha nada a ver com a causa. E
como a fila já tinha parado no primeiro "sucesso", nenhum outro candidato chegava a
tentar. O melhor provedor da fila nunca rodava, porque o pior tinha respondido
primeiro e dito que estava tudo bem.

A correção não foi arrumar aquele candidato. Foi parar de perguntar "deu erro?" e
começar a perguntar "isso serve?".

Hoje cada passo tem uma pós-condição. O critério não é "a função retornou". É "o
que voltou dá pra usar no passo seguinte". Se não dá, isso é falha, e falha faz a
fila continuar tentando.

"Não deu erro" não é a mesma coisa que "deu certo". Quem decide se deu certo é
quem vai usar o resultado, não quem produziu.

O caminho caro é o último, não o primeiro

Nem todo vídeo precisa do processamento pesado. Muita receita já está escrita ali
na descrição, de graça, esperando alguém ler.

Então eu tento o caminho barato primeiro e só pago pelo caro quando o barato não
resolveu.

Isso não é otimização prematura. Num produto que gasta por requisição, essa ordem
é o que decide se a conta fecha no fim do mês.

Assíncrono mexe com dinheiro, e isso muda o desenho

O usuário manda o link e vai embora. O processamento acontece depois, e ele nem
precisa estar com o app aberto.

Isso obriga duas coisas que eu não tinha pensado no começo.

A entrega é pelo menos uma vez. Então processar a mesma coisa duas vezes não pode
cobrar duas vezes nem duplicar resultado, e isso tem que ser garantido no banco e
não no código que chama.

E se falhou de vez, devolve o crédito. O usuário não pode pagar por um vídeo que
ele não recebeu. Parece óbvio escrito assim, mas é o tipo de coisa que só aparece
quando alguém reclama.

O resumo que eu levo disso

1. Fila de candidatos — nunca um provedor só, e o núcleo não conhece nenhum pelo nome
2. Ordem empírica — o que funciona na prática, preço é desempate
3. Pós-condição em cada passo — "isso serve?" e não "deu erro?"
4. Barato primeiro — o caro só quando o barato não resolveu
5. Assíncrono honesto — não cobra duas vezes e devolve o que não entregou

Nada disso é sofisticado. É tudo coisa que eu aprendi depois de quebrar, que é
como eu aprendo quase tudo.

Vocês já ficaram presos em providers ou em algo que parecia certo mas não era?