Nikunj Bajaj, Co-Fundador e CEO da TrueFoundry – Série de Entrevistas

Você trabalhou em pesquisas de aprendizado de máquina, IA de produção na Facebook e sistemas de recomendação em larga escala antes de fundar a TrueFoundry — quais experiências o levaram a construir uma empresa de infraestrutura de IA empresarial, e qual dor você sentiu que não estava sendo atendida na época?

Na Meta, víamos o aprendizado de máquina como um caso especial de software, e a IA gerativa como um caso especial de aprendizado de máquina, o que resultou em uma pilha vertical com software na parte inferior, aprendizado de máquina no meio e IA gerativa no topo. Nesse setup, se eu sou um desenvolvedor de aprendizado de máquina, os modelos que eu construo seguem o mesmo padrão de implantação que o restante do software, o que torna a escalabilidade de sistemas muito direta.

A maioria das empresas, no entanto, implantava pilhas paralelas, o que significa que tinham pilhas separadas para software, aprendizado de máquina e IA gerativa. No momento em que você tem essas pilhas paralelas, a escalabilidade se torna mais complexa devido às transferências necessárias entre o mundo do aprendizado de máquina e o mundo do software.

Nossa equipe sempre trabalhou na interseção entre a construção de modelos de aprendizado de máquina e infraestrutura de aprendizado de máquina, então tínhamos uma visão única que podíamos trazer pilhas verticais semelhantes para as empresas e adaptá-las para suas necessidades específicas. Também tínhamos uma hipótese no final de 2021 de que o aprendizado de máquina estava se aproximando de um ponto de inflexão, e quando isso acontecesse, mais empresas precisariam de uma pilha verticalmente integrada para implantar e dimensionar esses sistemas de forma eficaz. Foi isso que nos levou a fundar a TrueFoundry, e nossa hipótese estava certa. A adoção de IA acelerou após o lançamento do ChatGPT no final de 2022.

À medida que os sistemas de IA se movem da experimentação para as operações diárias, o que mudou sobre a forma como as organizações devem pensar sobre confiabilidade e falha?

As apostas com a IA gerativa são significativamente mais altas em comparação com os sistemas de aprendizado de máquina tradicionais. À medida que esses sistemas se movem para a produção, as organizações estão lidando com um nível muito maior de ambiguidade e não determinismo, pois os LLMs são estocásticos por natureza. Os sistemas agênticos construídos sobre eles adicionam mais ambiguidade.

Além disso, as falhas não são mais binárias. Em vez de os sistemas simplesmente falharem ou não falharem, muitos problemas aparecem como falhas parciais ou degradações silenciosas. Os sistemas podem responder com maior latência, qualidade degradada ou comportamento incorreto ao longo do tempo. Em muitos casos, essas degradações podem ser mais difíceis de detectar e, às vezes, até mais prejudiciais do que uma falha completa.

Organizações precisam pensar sobre confiabilidade não apenas em termos de tempo de atividade, mas também de degradação de desempenho ao longo do tempo.

TrueFailover foi lançado em meio a uma onda de interrupções de serviços de nuvem e IA de alto perfil. Quais eventos recentes tornaram claro que a confiabilidade de IA havia mudado de um “bom para ter” para um requisito arquitetônico fundamental?

Um de nossos clientes de saúde que processa solicitações de pacientes em tempo real e sensíveis ao tempo foi afetado por uma interrupção causada por uma falha de modelo. Seus fluxos de trabalho geram milhares de dólares de receita por segundo, e a interrupção interrompeu alguns desses fluxos de trabalho críticos. Como um cliente inicial do TrueFailover, conseguimos ajudar com uma recuperação rápida, e o impacto foi contido.

Incidentes como esse levantam uma pergunta importante. À medida que as apostas dos sistemas de IA gerativa continuam a subir, por que os processos de recuperação ainda são largamente manuais? Isso reforçou a ideia de que os sistemas devem ser projetados com a suposição de que as falhas ocorrerão e que devem ser projetados para se corrigir automaticamente. A confiabilidade também deve ser incorporada à própria pilha de IA por meio do uso de Gateways de IA, que podem fornecer roteamento centralizado, observabilidade, guardrails e comutação de modelo inteligente entre provedores.

Muitas interrupções de IA ainda são enquadradas como problemas técnicos. Onde você vê os verdadeiros custos econômicos e humanos começando a surgir quando os sistemas de IA param de funcionar?

A IA empresarial evoluiu para o ponto em que esses problemas técnicos não afetam mais apenas os fluxos de trabalho internos. Hoje, as interrupções e degradações afetam a percepção pública e os lucros diretamente e imediatamente, porque os casos de uso de produção agora são orientados para o cliente. Essa mudança de testes internos para aplicações de alto risco e orientadas ao público é por que estamos vendo uma demanda crescente por atenção e supervisão executiva.

À medida que os sistemas de IA se integram mais profundamente nos fluxos de trabalho operacionais, as interrupções não são mais apenas problemas técnicos. Elas têm consequências comerciais, de cliente e de reputação cada vez mais diretas.

Em ambientes críticos, como farmácias, operações de saúde ou suporte ao cliente, com que rapidez o tempo de inatividade de IA pode se tornar um risco operacional ou de reputação?

Em ambientes críticos, a escalada acontece quase imediatamente, pois esses sistemas suportam fluxos de trabalho em tempo real e sensíveis ao tempo. Mesmo uma interrupção curta pode paralisar processos críticos, atrasar a entrega de serviço ou interromper sistemas downstream que dependem dessas saídas, criando efeitos operacionais em cascata em toda a organização.

Em setores como a saúde, o impacto se estende além da interrupção operacional para a experiência do cliente e os resultados do serviço. Se um paciente não consegue cumprir sua prescrição no prazo, podem haver consequências reais. Não é apenas um problema para o paciente, mas também pode danificar a reputação de uma farmácia ou provedor de saúde. Em ambientes críticos onde a confiança é um fator, é fundamental que os sistemas permaneçam online. É por isso que as organizações estão cada vez mais reconhecendo que os sistemas de IA devem ser projetados com a suposição de que as falhas ocorrerão e que os mecanismos de recuperação precisam ser ativados automaticamente para minimizar o risco.

Você disse que muitas equipes arquitetam para capacidade em vez de continuidade. Por que você acha que a resiliência foi historicamente subestimada no design de sistemas de IA?

Isso vem basicamente dos incentivos dentro das organizações. Novas capacidades são visíveis e emocionais. Elas desbloqueiam demonstrações, recursos e possibilidades de produto que a liderança pode ver imediatamente.

A continuidade, por definição, é invisível quando as coisas estão funcionando bem. Por causa disso, os sistemas de recompensa tendem a ser inclinados para o desenvolvimento de novos recursos em vez de garantir que nada quebre. Como resultado, as organizações frequentemente investem desproporcionalmente no desenvolvimento de capacidades em vez de engenharia de resiliência.

À medida que as empresas dependem cada vez mais de modelos e APIs externos, quais novas fragilidades estão sendo introduzidas na pilha de IA que os líderes podem não apreciar completamente ainda?

Os LLMs são fundamentalmente recursos compartilhados, e as empresas não os possuem como possuem infraestrutura tradicional. Além disso, sistemas críticos de negócios que operam em empresas estão executando em sistemas externos que não são totalmente testados no tempo. Os LLMs em si estão evoluindo rapidamente, o que significa que um provedor de modelo não pode ser responsabilizado por coisas como latência ou desempenho de modelo ligeiramente reduzido, porque eles estão iterando rapidamente em sua pesquisa.

Como os LLMs são recursos compartilhados, a latência pode aumentar porque outro consumidor desses LLMs toma uma ação específica. Há muitos desses pontos de falha que são introduzidos devido à natureza fundamental dos LLMs, e as empresas nesse novo mundo simplesmente não têm controle total. Sem controle total, a melhor coisa que uma empresa pode fazer é criar redundâncias de sistema suficientes para projetar um sistema resiliente.

Como as organizações devem repensar a arquitetura de IA para supor falha em vez de tratar interrupções como casos de bordo raros?

As organizações devem voltar aos primeiros princípios do design de sistemas distribuídos. Os sistemas de software foram construídos com a suposição de que componentes de rede e máquinas falhariam, e que uma região inteira poderia desligar.

Sistemas de IA não devem ser diferentes. Devemos supor que os provedores de modelo experimentarão problemas de latência, degradação ou interrupção, e incorporar redundância para que as aplicações permaneçam resilientes em diferentes cenários de falha.

Você espera que a resiliência de IA se torne um fator decisivo na seleção de plataforma e fornecedor, semelhante à forma como o tempo de atividade e a redundância moldaram as decisões de infraestrutura de nuvem?

À medida que mais sistemas de IA se movem para a produção, a resiliência se tornará um requisito básico. Se um fornecedor não pode mostrar seus gráficos e métricas de tempo de atividade e resiliência geral, eles nem serão considerados. Uma vez que a resiliência se torna uma expectativa de base entre os fornecedores, os fatores decisivos mudarão para experiência do usuário, otimização de desempenho, observabilidade e capacidades de produto de nível superior. Com o tempo, componentes como um Gateway de IA e capacidades de failover automatizado se tornarão elementos fundamentais da infraestrutura de IA empresarial.

Olhando para o futuro, o que “pronto para produção” realmente significa em um mundo onde a IA é esperada para estar continuamente disponível, não apenas ocasionalmente útil?

Sistemas de IA prontos para produção devem ser observáveis, controláveis e recuperáveis. As três caixas precisam ser marcadas.

Para que a IA de produção seja observável, as equipes precisam de visibilidade profunda no comportamento do modelo, latência, taxas de erro, uso de token, padrões de falha e deriva. Sem observabilidade forte, torna-se muito difícil detectar degradações antes que os usuários comecem a notá-las.

Para que os sistemas sejam controláveis, isso inclui modelagem de tráfego, limitação de taxa, guardrails, aplicação de política e roteamento inteligente entre modelos e provedores. É aqui que um Gateway de IA se torna fundamental, atuando como um plano de controle centralizado que impõe guardrails, fornece governança consistente e permite a comutação de modelo dinâmica quando o desempenho ou a confiabilidade cai.

E, por fim, quando se trata de ser recuperável, os sistemas devem ser projetados com a suposição de que os componentes podem ser quebrados parcial ou completamente, seja devido a interrupções de provedores, qualidade de modelo degradada, limites de taxa ou entradas inesperadas de atores mal-intencionados. Mecanismos de failover e autocura automática devem ser nativos da arquitetura, não manuais, ativados após algo dar errado.

Essa é a direção que estamos trabalhando na TrueFoundry. Fornecedores que definem prontidão para produção dessa forma, combinando observabilidade, controle centralizado e recuperação automatizada, ganharão a confiança de longo prazo dos clientes e serão capazes de continuar a resolver novos problemas à medida que surgem. Vendors que define production readiness in this way, combining observability, centralized control, and automated recovery, will earn long-term customer trust and will be able to continue to solve new issues as they emerge. Thank you for the great interview, readers who wish to learn more should visit TrueFoundry.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar TrueFoundry.