Ontologias just-in-time: o que a inteligência barata significa para os dados — Hrishi Olickel, Southbridge AI

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Just-in-Time Ontologies: What Cheap Intelligence Means for Data — Hrishi Olickel, Southbridge AI · Canal: AI Engineer · 20:47 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA, Dados, bancos de dados e embeddings

Resumo

Hrishi Olickel argumenta que não existe uma ontologia universal: os esquemas de origem, armazenamento e decisão — além dos priors dos modelos — só se tornam claros quando uma decisão precisa ser tomada. Ontologias just-in-time transformam dados nesse momento, preservando o contexto e adaptando-se ao problema. O palestrante descreve pipelines que combinam modelos com funções distintas e se otimizam para custo, velocidade e precisão, ilustrando a abordagem com a resolução de entidades em registros de financiamento de campanha de Ohio. Para que esses sistemas funcionem, são necessários uma superfície estável de execução, experimentos limitados, metodologia e critérios explícitos de falha.

Pontos-chave

• Não há uma ontologia universal que sirva para todas as decisões; o significado dos dados depende do contexto em que serão usados.
• A transformação just-in-time combina o contexto de origem dos dados com o contexto da decisão no momento em que ela é conhecida.
• Modelos podem desempenhar três funções distintas em pipelines: projetar o sistema, executar tarefas dentro dele e otimizar iterativamente a solução.
• No caso dos registros de Ohio, o pipeline processou 203.317 casos por cerca de US$ 795, abaixo do orçamento de US$ 800 e da estimativa inicial de US$ 10.000.
• Priors dos modelos podem gerar erros confiantes, como interpretar incorretamente sinais, formatos de data ou grafias de campos.
• Comparar modelos de famílias diferentes pode ajudar a localizar erros: no teste citado, Jev e Luna concordaram em 194 de 200 casos, sem erros nesses casos concordantes.
• A auto-otimização exige uma superfície de execução estável, limites para experimentos, know-how e uma superfície de falha bem definida.
• Ontologias intermediárias podem ser documentadas, reutilizadas e ajustadas para novos trabalhos.

Capítulos

Início	Capítulo	Resumo
00:00	A mudança de paradigma na transformação de dados	O palestrante relaciona a queda do custo da inteligência à possibilidade de transformar dados sob demanda e introduz o conceito de ontologias just-in-time.
04:43	Por que ontologias universais falham	O significado dos dados depende da decisão, e o palestrante apresenta diferentes regimes de trabalho em pipelines.
08:20	Três funções dos modelos e o caso de Ohio	O palestrante separa os papéis dos modelos e mostra como um pipeline de resolução de entidades foi testado e aplicado aos registros de Ohio.
13:32	Priors, erros e comparação entre modelos	Exemplos de erros confiantes mostram como priors diferentes podem ser cruzados para encontrar falhas, embora alguns erros persistam entre famílias de modelos.
16:39	O que é necessário para a auto-otimização	Uma execução estável, limites para experimentos, metodologia e uma superfície de falha permitem que os modelos testem e aprimorem soluções.
18:11	Construção e reutilização de ontologias just-in-time	O palestrante descreve as etapas de decomposição, pilotos, validação e deploy, concluindo que ontologias contextualizadas podem ser reutilizadas.

Citações

E se isso não fosse mais verdade? — 00:31

Não existe um conceito de cliente separado da pergunta que você quer responder. — 04:12

O trabalho estadual inteiro custou 795, dentro de um orçamento de 800 definido antecipadamente. — 12:31

Dê-me um lugar para ficar, e eu moverei a Terra. — 17:40

A boa notícia é que toda ontologia e todo esquema são válidos, desde que você possa rotular e preservar o contexto ao redor deles. — 20:15

Conceitos e entidades

• Just-in-time ontology (conceito): Ontologia criada quando uma decisão específica exige transformar dados, preservando o contexto relevante para aquele trabalho.
• Pareto serving (conceito): Processo de testar e combinar opções para encontrar um equilíbrio favorável entre custo, velocidade e precisão.
• Decision Models (conceito): Modelos usados como trabalhadores rápidos dentro de grandes workloads, executando tarefas sobre informações.
• Priors (conceito): Pressupostos ou crenças que os modelos levam para uma tarefa e que podem influenciar suas respostas.
• Failure surface (conceito): Conjunto de critérios e condições definidos para identificar quando um sistema ou experimento falha.
• Hank Weave (ferramenta): harness apresentado como uma superfície estável para executar trabalho com agents, com logs, API, checkpoints, rollback e controle de orçamento.
• Southbridge AI (empresa): Empresa mencionada pelo palestrante como responsável por desenvolver sistemas e pipelines de dados com inteligência integrada.
• Hrishi Olickel (pessoa): Palestrante que apresenta a abordagem de ontologias just-in-time e pipelines auto-otimizáveis.

Tradução completa (pt-BR)

00:00 [música] >> Eu gosto muito deste artigo de Hannes, da Duct Tape B, em que ele pergunta se perdemos uma década perseguindo arquiteturas distribuídas que partiam do pressuposto de que computação e armazenamento eram lentos e caros. Mas a capacidade de cada era define a arquitetura e as ferramentas, e as ferramentas ficam consistentemente para trás. Primeiro, tornamos a computação mais barata que o armazenamento, depois a disponibilizamos para todo mundo e, em seguida, a tornamos mais rápida. E, todas as vezes, as arquiteturas passam por essa enorme

00:31 mudança. Toda a nossa infraestrutura de dados hoje é construída com base na ideia de que transformar dados é caro. E se isso já não fosse verdade? Acredito que resolvemos o último gargalo da transformação: inteligência geral, ou julgamento, e a tornamos acessível sob demanda ao longo de toda a fronteira de Pareto. Isso nos coloca à beira de uma mudança de paradigma. Então, nesta palestra, vamos falar sobre por que ontologias únicas sempre falham, os três papéis que os modelos desempenham em pipelines, a interseção de priors de modelos

01:03 para obter resultados melhores e o atendimento de Pareto. Como os modelos de hoje podem ajustar uma carga de trabalho para custo, velocidade e precisão ao mesmo tempo. Aqui vai um exemplo rápido. Quando Jeff foi lançado, já tínhamos um pipeline de resolução de entidades em execução, analisando os registros de financiamento de campanhas de Ohio e determinando se pertenciam à mesma pessoa, empresa ou comissão. A previsão era de que custaria cerca de US$ 10.000. Nossos sistemas pegaram esse novo modelo, descobriram onde ele se encaixava, testaram mais de uma dúzia de abordagens e o integraram. Dez dias

01:35 depois daquela primeira ligação, tínhamos a verdade de referência final para todos os casos de doadores em Ohio abaixo de US$ 800. Esse é o poder do atendimento de Pareto e das transformações just-in-time. Então, vamos ao assunto. Ontologias são a versão empresarial dos mapas mentais. É esse tapete que nos suga a todos, inclusive a mim. Quando fundei a Southbridge, há dois anos, falei sobre um único esquema universal.

02:06 A concepção popular — e não está errada, só representa uma parte pequena do quadro — é que migrações e ontologias fracassam por falta de adesão. E são abandonadas pela metade, porque organizações e pessoas nunca fazem a transição. Tudo isso é verdade. Com certeza. Mas a adesão não é o principal motivo. Digamos que você pudesse integrar e migrar todas as suas informações para um único superesquema num piscar de olhos. Ainda teria de encarar a verdade de que não existe superesquema. Na verdade, existem quatro esquemas.

02:37 O primeiro pertence à fonte, seja lá de onde venha a informação. Vou usar a temperatura como exemplo. Digamos que eu peça para você anotar a temperatura. O esquema da fonte é aquilo a que você tem acesso. Seu celular informa a temperatura da sua região; um sensor na sua mesa, menos preciso, mas mais local; ou, digamos, seu relógio. Mas até a sua disposição para cumprir meu pedido faz parte desse esquema da fonte. O segundo é o esquema de armazenamento. Só dá para anotar uma quantidade limitada de coisas. Você não pode anotar o firmware do

03:09 dispositivo que está usando. Você nem consegue anotar a hora até o segundo, porque não conseguiria terminar de escrever tudo isso em um segundo. Esse é o esquema imposto a você pelo armazenamento. O terceiro pertence à decisão. Por que preciso que você anote a temperatura? Talvez você esteja tentando descobrir o que faz você se sentir confortável; nesse caso, preciso de temperaturas suas ao longo do dia e tenho de garantir que é você quem está fazendo a medição. Talvez eu esteja criando mapas de migração do clima; nesse caso, não me importa quem faz a medição, mas me importo muito com sua localização exata,

03:40 a hora, o dispositivo usado e se isso mudou. Ou talvez eu esteja decidindo se devo instalar equipamentos sensíveis e onde, e você mesmo se torna uma variável que preciso eliminar. Mas há um quarto, ao qual chegaremos quando falarmos de priors. É uma adição recente. O verdadeiro problema é que você nunca conhecerá os quatro esquemas ao mesmo tempo, exceto no momento em que a decisão é tomada. Em quase toda empresa e todo lar, a maior parte dos dados registrados não faz ideia do uso que terá

04:12 depois. Pense em um cliente, a primeira categoria de toda ontologia. Para a equipe de construção, cliente é quem paga. Para o suporte, é quem liga. Para compliance, é quem nos torna responsáveis. E você só sabe qual definição importa quando conhece a decisão. Devemos reembolsar este pedido? Podemos conceder mais crédito a esta conta? De repente, fica extremamente claro o que você precisa saber, como e em que grau. Foi por isso que eu estava errado. Não existe esquema universal. Não existe conceito de

04:43 cliente independente da pergunta que você quer responder. E reunir esses esquemas é o processo de transformação, de tornar a informação realmente útil. É pegar o contexto em que ela foi registrada e combiná-lo com o contexto da decisão. E isso exige discernimento. Fazer essa combinação quando o espaço de decisões já é conhecido, em vez de fazê-la antecipadamente, é o que quero dizer com ontologia just-in-time. Então, vamos voltar ao discernimento com uma história do meu último emprego, onde, como em boa parte do meu trabalho, eu precisava garantir que certos

05:14 números simplesmente nunca existissem. Antes disso, um pouco sobre mim e sobre nós. A melhor forma de nos descrever é como obcecados. Obcecados por incorporar inteligência a pipelines. Pipelines que podem escalar, ser executados repetidamente para realmente tirar trabalho das nossas mãos e amadurecer sozinhos em custo, desempenho e velocidade. E a maior parte do trabalho que fazemos com dados se divide em três regimes. O primeiro é escrever uma vez, executar uma vez. Se

05:46 você faz algum tipo de desenvolvimento, pense neles como funções invocadas imediatamente e em escala monstruosa. São feitos para uma única utilização, como combinar um conjunto de dados, extrair informações ou responder a uma pergunta específica, e depois são descartados. O segundo é escrever muitas vezes, executar uma vez, em que muitas cargas de trabalho, menores e maiores, são criadas para alcançar um grande objetivo comum. O mais próximo que você talvez conheça são grandes migrações. Anos de registros transferidos de sistemas dos quais ninguém se lembra por completo. Muitas cargas de trabalho criadas para uma regra e

06:17 verificadas individualmente na fonte, comparadas entre si porque tudo isso só acontece uma vez. O terceiro, porém — e esse é o nosso ganha-pão — é o mais comum: escrever muitas vezes, executar muitas vezes. São pipelines repetíveis, criados e mantidos ao longo do tempo, à medida que adicionamos mais informações. Na Southridge, transferimos muito trabalho da linha principal para esses sistemas repetíveis: do planejamento de benchmarks, acompanhamento e programação até a criação de legendas para filmes que queremos assistir. Quase tudo o que fazemos no mundo

06:47 moderno é uma transformação de dados, ou esbarra na dificuldade de transformar dados. E, em todos esses casos, nosso trabalho é simples: garantir que as pessoas possam confiar nos resultados. Em apenas dois anos, passamos de descobrir como tornar confiáveis modelos do nível do 3.5 turbo inicial em áreas como saúde, envelhecimento e pesquisa de mineração a construir Hank Wave, nosso harness open source para trabalho com dados, e depois usar isso para fazer modelos trabalharem juntos em escala de terabytes. Hoje, temos sistemas auto-otimizáveis.

07:18 Você lhes dá o problema, uma forma de falhar com segurança e um lugar para trabalhar, e eles encontram a forma da solução. Escolhem os modelos certos, executam os testes-piloto, aumentam a escala e usam o atendimento de Pareto para encontrar a melhor opção possível. Então, uma história do meu último emprego: a pergunta que mais ouvíamos era: “Podemos tomar essa decisão com base em dados?” E, às vezes, essa era a pergunta certa, quando tínhamos milhares de embarcações na plataforma. O problema é que também fazíamos essa pergunta quando tínhamos apenas

07:50 50 usuários. E, se você conhece estatística, consegue explicar muito bem por que fazer um teste A/B com 50 usuários é uma má ideia. Não porque você não vai obter um resultado, mas porque vai. Então, a única opção de verdade era não produzir número algum, porque, no instante em que um número existe, ele argumenta a favor de um resultado. Hoje, porém, é pior. Agents interativos sempre vão dar uma resposta. Vão dar essa resposta rápido. Você pede uma transformação, sei lá, e recebe um contra e um “sim, senhor”.

08:20 Isso significa que os erros se acumulam rapidamente. Um momento no chat pode se tornar um pesadelo amplo para sempre, só esperando para ser descoberto. A principal razão para isso acontecer é que a inteligência, no que diz respeito ao trabalho com dados hoje, ocupa três funções distintas que os coding agents acabam juntando em uma só context window. Vamos separar essas funções, porque isso vai ajudar bastante quando chegarmos aos decision models, já que eles se encaixam exatamente em uma dessas três. A primeira é construir e projetar o pipeline: decompor o problema, escrever as especificações iniciais,

08:52 autorizar gastos. A segunda — que costuma ser confundida com a primeira e atribuída aos mesmos modelos — é trabalhar dentro do pipeline, realmente fazendo o trabalho: ler o PDF, gravar em bancos de dados, conferir os resultados. Antes de chegarmos à terceira, quero deixar claro que essas duas funções apontam em direções bem diferentes. A primeira exige modelos mais lentos, com tokens mais pesados e densos, modelos capazes de pensar mais, explorar um problema e analisar seus diferentes ângulos, assimilar documentação, entender como esses pipelines são construídos e

09:24 prever como algo vai funcionar antes mesmo de começar, certo? Opus ou superior. Já os modelos que você quer dentro dos pipelines são o oposto. Você os quer mais baratos, mais rápidos, especializados, bons em seguir instruções, trabalhadores repetíveis com defeitos nobres. A mesma coisa acontece na natureza. Uma colônia de formigas-cortadeiras, por exemplo, funciona com quatro tamanhos diferentes de operárias, certo? Pequenas, médias, grandes e extragrandes. Ao observar qualquer sistema que você projete, revise ou sobre o qual ouça falar, preste atenção em que função cada coisa ocupa nesse bolo de camadas. Faz

09:55 uma grande diferença. Como tínhamos essa distinção, foi muito fácil trazer Jev para essa classe recém-explosiva de decision models: eles são trabalhadores. São feitos para lidar rapidamente com informações e são implantados na parte inferior de grandes cargas de trabalho. Mas há uma terceira categoria. São os que chamamos de escaladores de colina ou servidores. Modelos capazes de pegar o primeiro tipo e se auto-otimizar. Com o conhecimento e as instruções certos, e uma base incrivelmente estável sobre a qual se apoiar, eles podem experimentar coisas novas, variar

10:25 os orçamentos para limitar a exposição a custos, depurar rapidamente, fazer anotações e encontrar o caminho não apenas para a solução certa, mas para a ideal. Chamamos isso de surfe de burrito e vamos falar sobre isso no final. Mas, primeiro, vamos falar da nossa experiência com Jev. Jev foi lançado numa terça-feira, quando estávamos mergulhados em um pipeline de resolução de entidades. Você estava trabalhando com doadores nas finanças de campanha de Ohio. A essa altura, muita gente já viu este gráfico. Já falamos dos resultados e adaptamos parte do trabalho em andamento ao

10:57 conjunto de dados. Então, você pode baixá-lo por conta própria, com os prompts e tudo mais. O que não discutimos foi tudo o que está por trás daquela seta e o que aconteceu quando executamos a mesma ideia no estado inteiro. Aqui estão todas as arquiteturas que testamos. Começamos com três projetos em um pequeno conjunto de desenvolvimento. Um modelo de raciocínio barato sozinho; Jev com um modelo de raciocínio para tudo de que não tivesse certeza; e um modelo de raciocínio propondo respostas, com Jev conferindo-as. Em cerca de 200 famílias separadas para teste, o modelo de raciocínio barato sozinho teve um desempenho

11:28 tão bom quanto Fable por cerca de 2% do custo. Jev acertou as respostas principais, mas deixou passar nove vínculos entre domicílios porque tinha respondido com confiança que não havia vínculo em todos eles. Então, reformulamos as perguntas. Sem tocar nos modelos nem nos limiares, a pergunta sobre domicílios passou a especificar o que conta como evidência suficiente, e Jeff passou de responder não a todas as 13 perguntas de desenvolvimento para responder sim. E, ao ampliarmos para todo o estado, fizemos mais de uma dúzia de rodadas desse tipo de qualificação. Cada rodada corrigiu uma definição: o que é um comitê, o que significa um

11:58 declarante, o que significa quando duas pessoas moram no mesmo endereço. Agora, cada um dos 203.317 casos de Ohio tem um rótulo que informa em que a resposta se baseia e até que ponto ela foi verificada. Esta é a hierarquia que descobrimos para esse problema específico. E aqui está tudo o que aprendemos sobre incorporar decision models a pipelines. Vou deixar isto na tela para você tirar uma captura. Mas foi aqui que o dinheiro foi gasto. O trabalho no estado inteiro custou 795, dentro de um orçamento de 800 definido antecipadamente.

12:31 A conferência custou cerca de quatro vezes mais do que a execução: 545 em segundas opiniões, resolução de divergências e auditoria, contra 128 para as primeiras respostas. Antes de Jeff, esperávamos que esse trabalho custasse cerca de 10 mil dólares. Agora que o pipeline foi construído e verificado, esperamos que o orçamento de auditoria para o próximo estado fique perto de zero. O mais impressionante é que nosso agent 4A, executado em Astra e depois em Opus, descobriu por conta própria a maioria dessas abordagens, passo a passo. Ao construir

13:01 o sistema, executá-lo, depurá-lo e experimentar coisas novas. Ele rodou por 10 dias e testou mais de uma dúzia de arquiteturas. Seus harnesses foram executados mais de 4.000 vezes, além de 90.000 chamadas a Jeff; ele testou praticamente todos os modelos na fronteira de Pareto, e os modelos dentro dessas execuções processaram cerca de 6 bilhões de tokens. Depois de tudo isso, registramos o que aprendemos em nossa biblioteca de componentes agentic. Este trabalho se apoiou nos componentes que já existiam, e estamos adicionando outros novos e testados, como

13:32 a carta de conferência. Para mim, esse é o valor de tirar o trabalho da linha principal, tanto para humanos quanto para agents, porque cada uma dessas iterações era um harness com controle de versão. Era fácil reverter, entender, depurar e criticar. Então, os modelos já conseguem fazer isso nativamente? Ainda não. Faltam quatro coisas, que vamos abordar, e há algo que não desaparece, porém, à medida que os modelos ficam maiores e mais capazes: os priors. Assim como os humanos, os modelos trazem seus próprios

14:04 priors, suas crenças sobre como o mundo deveria ser, para cada tarefa. Este é o quarto esquema que mencionei antes, aquele que o modelo traz consigo. De uma forma estranha, às vezes os modelos maiores são piores nisso. Eles se apegam às próprias crenças e as defendem com ainda mais veemência. Aqui estão alguns casos que encontramos. Um pipeline procurava “in kind” escrito com sublinhado. O arquivo trazia a expressão com “I” maiúsculo e hífen. Então, o modelo contou 15.658

14:34 contribuições “in kind” como dinheiro comum e não conferiu de novo. Os pagamentos de empréstimos também desapareceram da mesma forma. Outro modelo tentou quatro formatos de data, embora o arquivo usasse o quinto. Assim, 99,4% das datas das transações ficaram vazias, mas a contagem de linhas e os valores em dólares correspondiam, então o agent seguiu em frente. Em várias execuções, os modelos perceberam que os valores dos empréstimos eram negativos, decidiram que o sinal era redundante e armazenaram o valor absoluto. Um saldo líquido de 784.000

15:06 acabou se tornando uma dívida de 5,3 milhões de dólares, validada por vários modelos. E essa está rapidamente se tornando a maior categoria de erro que vejo nas empresas trabalhando com dados à medida que os modelos assumem o controle. Às vezes, dá para resolver isso simplesmente não fazendo vibe coding, conferindo os resultados e aplicando a intuição humana. E o que você está fazendo de fato nesse caso é interessante: está cruzando seus priors com os dos modelos. No primeiro exemplo, qualquer pessoa perceberia a ausência de contribuições “in kind” se entendesse de financiamento de campanhas ou soubesse o que

15:37 conferir. Então, nós encontramos o problema. Mas os humanos, falando como uma pessoa que trabalhou nessa tarefa específica, são caros. São lentos, atrasam cronogramas, são ainda menos determinísticos que os modelos e odeiam interrupções. E acontece que também é possível avançar bastante cruzando os priors de diferentes modelos. Nas nossas 200 famílias separadas para teste, Jev e Luna concordaram em 194. E nenhuma dessas respostas em comum estava errada. Todos os erros estavam nas seis famílias em que discordaram. Modelos de famílias e linhagens diferentes tendem a discordar mais e a ter priors diferentes dos modelos do mesmo grupo, por exemplo.

16:08 A exceção — não vou dizer quem — são os modelos destilados fora da mesma empresa. Assim, com esse tipo de trabalho, dá para reduzir bastante a superfície e, junto com ela, os erros, chegando a uma classe muito menor, mas persistente, de problemas que se aplicam aos LLMs como espécie. Então, em um benchmark, quatro famílias diferentes de modelos chegaram ao mesmo total, até o último algarismo, porque todas compartilhavam uma convenção de sinal diferente da do gabarito.

16:39 E, quando se chega a esse ponto, o único caminho adiante é listá-los, ficar atento a eles e aplicar soluções específicas. Voltando ao assunto: quais são as quatro coisas que nos faltam para conseguir nos auto-otimizar? A número um é uma superfície de deploy estável. Usamos Hank Weave para isso: um harness que recebe a superfície em rápida mudança dos ambientes de execução de agents, como Claude Code e Pi, e expõe uma interface consistente e bem testada de logs e API, com checkpoints, reversão, aplicação de limites de orçamento e tudo o mais integrado.

17:10 Algo sobre o qual você possa construir. Mas outras coisas também se encaixam nessa descrição. Para ser justo, no trabalho de dados sem interface, eu diria que Hank Weave ainda é o mais antigo, estável e aberto. Vou deixar a skill disponível caso queira experimentá-la. O segundo ponto é alguma forma de limitar seus experimentos. Você não consegue testar se não puder controlar custo, tempo e acesso como recursos. O terceiro é conhecimento prático e metodologia. Descobrimos que essa nova classe de modelos pode aproveitar tudo o que aprendemos em dois anos de implantação, de forma agêntica,

17:40 com padrões, técnicas de depuração e prompting, e aplicar isso a problemas complexos. Com a camada de abstração certa, você consegue expressar isso com muita eficiência em tokens, e os modelos podem implementá-lo. O quarto, e mais importante, é uma superfície de falha. Arquimedes disse: “Dê-me um ponto de apoio e moverei a Terra.” E, no nosso caso, não encontramos um problema ou uma restrição que não pudéssemos resolver por meio de iterações, desde que tivéssemos uma pilha estável sobre a qual construir e uma superfície de falha contra a qual iterar. Esse último ponto foi o mais difícil de colocar em palavras e

18:11 de transformar em ferramentas e instruções que ajudem os modelos a chegar lá. Os melhores modelos atuais ainda são apenas razoavelmente bons nisso; são lampejos de inteligência, por assim dizer. O processo todo, porém, envolve passar por seis etapas. Primeiro, inspecionamos o trabalho e o dividimos. Para Jeff, isso significa dividir cerca de 800 mil linhas em 200 mil casos menores e especializados, e cada um desses casos em perguntas tipadas. Que tipo de doador, um doador, sabe, perguntas diferentes que precisavam ser respondidas. Depois, definimos a superfície de falha. Nesse

18:42 caso, executamos bons modelos em uma pequena parte dos dados, verificando manualmente uma parte dela para estabelecer uma linha de base em relação à qual pudéssemos falhar. Em outros casos, configuramos sistemas automatizados de falha, verificações de esquema e também tratamos o comportamento como algo que podemos medir. Mas é muito importante definir uma superfície de falha antes mesmo de começar. Agora vem a parte divertida. Queremos pilotos mínimos e delimitados para testar a arquitetura. E, quando algo começa a funcionar, movemos essas etiquetas para rigs. Código que

19:14 é executado entre segmentos de trabalho delimitados, que chamamos de códons. Esses códons são então reutilizados, executados em ciclos independentes, validados e colocados em sequência. Por fim, os pipelines funcionais são implantados em produção, onde podem amadurecer aos poucos. E é nessa parte intermediária que acontece o surfe. Encontramos uma arquitetura que dá um resultado sólido, usamos como linha de base e substituímos modelos e outras partes por opções mais rápidas e baratas, comparamos com resultados intermediários conhecidos e tornamos mais rigoroso o requisito de sucesso, a cada vez

19:44 chegando cada vez mais perto do ideal, enquanto observamos a fronteira avançar. Conseguir dividir um problema complexo em partes significa que cada parte pode avançar por conta própria até sua melhor posição, como diria Adam Smith. Em um sistema como esse, as ontologias existem como intermediárias entre a inteligência e o resultado, o que facilita sua reutilização. Essa é a outra metade do que quero dizer com ontologias just-in-time. Elas são criadas quando o trabalho precisa delas, mantidas com seus comprovantes e reutilizadas quando o próximo

20:15 trabalho precisa da mesma coisa. E, quando você as tem, pode baratear essas coisas. Você pode executá-las em paralelo em conjuntos de dados para escalar. Vou terminar com um pedido de desculpas, certo? A resposta é que não existe ontologia. Pelo menos, não uma universal. Nunca existiu. A boa notícia é que isso torna válida qualquer ontologia e qualquer esquema, desde que você consiga rotular e preservar o contexto ao redor deles. E, se pudermos aproveitar essa inteligência barata que está começando a se espalhar pelo mundo ao nosso redor, estaremos nos aproximando rapidamente de um futuro em que

20:47 qualquer informação, em qualquer formato, seja tão útil quanto possível. E, na Outpace, estamos trabalhando o máximo que podemos para tornar esse futuro realidade. Obrigado.

Transcrição original

[00:00] [music] >> So, I really love this article from Hannes at Duct Tape B, where he asks if we lost a decade chasing distributed architectures that presumed compute and storage were slow and expensive. Capability in every era though defines architecture and tooling, and the tooling likes behind consistently. We first made compute cheaper than storage, and then we gave it to everybody, and then we made it faster. And every single time architectures undergo this massive

[00:31] change. All of our data infrastructure today is built on the idea that transformation is expensive. What if that wasn’t true anymore? I believe we’ve solved the final bottleneck in transformation, general intelligence or judgment, and we’ve made it accessible on tap all along the Pareto frontier. Which puts us right on the verge of a paradigm shift. So, in this talk, we’re going to cover why single ontologies always fail, the three roles models play in pipelines, intersecting model priors

[01:03] for better results, and Pareto serving. How today’s models can tune a workload for cost, speed, and accuracy all at the same time. Here’s a quick example. When Jeff launched, we already had an entity resolution pipeline running, working out Ohio’s campaign finance records and whether they belong to the same person, company, or committee. It was projected to cost about $10,000. Our systems took that new model, worked out where it fit, tested over a dozen approaches, and integrated it. 10 days

[01:35] after that first call, we had final ground truth for every donor case in Ohio under $800. That is the power of Pareto serving and just-in-time transformations. So, let’s get into it. Ontologies are the enterprise version of mind maps. It’s this carpet that sucks us all in, including me. I talked about a single universal schema when I founded Southbridge 2 years ago.

[02:06] The popular conception, and it’s not wrong, it’s just small part of the picture, is that migrations and ontologies fail because of a lack of buying. And they’re abandoned halfway through, that organizations and people never switch over. All of that is true. 100%. But buying isn’t the primary reason. Say, if you could integrate and migrate all of your information into a single super schema in the blink of an eye, you still have to contend with the truth that there is no super schema. There actually are four schemas.

[02:37] The first one belongs to the source, wherever the information comes from. I take temperature as an example. Say, I ask you to write down the temperature. The source schema is whatever you have access to. Your phone gives you your region’s temperature, sensor on your desk, which is less accurate, but it’s more local, or your watch, say. But even your patience in following through on my request is part of that source schema. The second one is the storage schema. There’s only so much you can write down. You can’t write down the firmware of the

[03:09] device you’re using. You can’t even write the time down to the second because you couldn’t finish writing all of that inside of a second. This is the schema imposed on you by storage. The third one belongs to the decision. Why do I need you to write the temperature down? Maybe you’re figuring out what makes you comfortable, in which case I need temperatures from you spread throughout the day, and I need to make sure that it’s you that’s doing the measuring. Maybe I’m building weather migration maps, in which case I don’t care who does the measuring, but I care a lot about your exact location,

[03:40] the time, the device you used, and whether that’s changed. Or maybe I’m deciding whether to install sensitive equipment and where, and you yourself become this variable that I need to cancel out. There’s a fourth one though, which we’ll get to when we talk about priors. It’s this recent addition. The true problem is that you will never know all four schemas at the same time except at the moment that the decision is being made. In almost every enterprise and every home, most of the data being recorded has little idea of what it’s going to be

[04:12] used for. Take a customer, the first box in every ontology. To building, a customer is whoever pays. To supported, whoever calls. To compliance, it’s whoever we’re on the hook for. And the only time you know is when the decision is known. Should we refund this order? Can we extend this account more credit? Suddenly, what you need to know, how and to what degree, becomes extremely clear. This is why I was wrong. There is no universal schema. There is no concept of

[04:43] a customer that’s divorced from the question that you want to answer. And pulling these schemas together is the process of transformation, of making information actually useful. Taking the context that it was recorded in and merging it with the context of the decision. And that takes discernment. Doing that merge when the decision space is known instead of ahead of time is what I mean by a just-in-time ontology. So, we’ll come back to discernment with a story from my last job where like most of my job was to make sure that certain

[05:14] numbers just did not exist ever. Before that, a little bit about me and us. We are best described as obsessives. Obsessives who embed intelligence into pipelines. Pipelines that can scale, that can run over and over again to take work truly off our hands, and pipelines that can mature in cost, performance, and speed all on their own. And most of the work we do in data breaks into three regimes. The first is write once, run once. If

[05:46] you do any kind of development, think of these as monster scale immediately invoked functions. They’re built for something single use, like joining a data set, mining information, or answering one specific question, and then they get torn down. The second is write many, run once, where lots of smaller and larger workloads are built for one large common goal. The closest thing you might know is like large migrations. Years of records moved out of systems nobody fully remembers. Lots of workloads built for one rule and

[06:17] verified individually at source, checked against the others because all of it only happens once. The third, though, and this is bread and butter, is the most common, is write many, run many. These are repeatable pipelines that are built and maintained over time as we add more information in. And at Southridge, we’ve moved so much work off the main thread and into these repeatable systems, from benchmark design, tracking, coding, to making subtitles for movies that we want to watch. Almost everything we do in the modern

[06:47] world is a transformation of data, or it’s bottlenecked by how hard it is to transform data. And in all of these cases, our job is simple. Make sure people can rely on the results. In just 2 years, we’ve gone from figuring out how to make early 3.5 turbo level models reliable on things like health care, aging, mining research, to building Hank Wave, our open-source harness for data work, and then using that to get models to work together at terabyte scale. Today, we have self-optimizing systems.

[07:18] You give them the problem, a way to fail safely, a place to work, and they find the shape of the solution. They pick the right models, they run the pilots, they scale up, and they Pareto serve their way to the best option they can find. So, story at my last job, the question we heard most often was, “Can we make this decision data led?” And sometimes that was the right question when we had thousands of vessels on the platform. The problem is that we also asked it when we only had

[07:50] 50 users. And if you know statistics, you can explain really well why AB testing 50 users is a bad idea. Not because you’re not going to get a result, but because you will. So the only real option was to do not produce a number at all because the moment a number exists, it argues for a result. Today though, it is worse. Interactive agents will always give you an answer. They’ll give it to you quickly. You ask for a transformation, whatever, and you get a contra and yes, sir.

[08:20] What this means is mistakes add up quickly. Moment in chat can be a broad nightmare forever just waiting to be discovered. The primary reason that this happens is that intelligence, as it relates to data work today, occupies three separate roles that coding agents kind of mash into one context window. Let’s pull those apart because it’ll help a lot when we get to decision models because they fit into exactly one of these three. The first one is building and designing the pipeline, which is breaking down the problem, writing the early specs,

[08:52] authorizing spend. The second one, and this is usually confused with the first and given to the same models, is working inside the pipeline, actually doing the work, reading the PDF, writing to databases, checking results. Before we get to the third one, I want to make it clear that these two roles pull in very different directions. The first one wants slower models with heavier, thicker tokens, models that can think more, walk around a problem and see the angles, digest documentation, understand how these pipelines get built, and

[09:24] predict how something will do before it even starts, right? Opus or up. The models you want inside pipelines though are the opposite. You want them cheaper, faster, specialized, good at following instructions, repeatable workers with noble defects. You see the same thing in nature. A leafcutter ant colony, for example, runs on four different sizes of worker, right? Small, medium, high, extra high. As you watch any system that you design, review, or hear about, listen for what slots in where in this layer cake. Makes

[09:55] a big difference. Because we had this distinction, bringing in Jev in this newly exploding class of decision models was very easy cuz they’re workers. They’re built for quick contact with information and they’re deployed at the bottom end of large workloads. So, third category, though. This is something we call the hill climbers or servers. Models that can take a first one and self-optimize. Given the right knowledge, instructions, and an incredibly stable surface to stand on, they can try new things, vary

[10:25] budgets to limit cost exposure, debug quickly, take notes, surf their way not just to the right solution, but the optimal one. We call that burrito surfing and we’ll cover it at the end. But, first, let’s talk about our experience with Jev. Jev launched on a Tuesday when we were deep into an entity resolution pipeline. You were working on donors in Ohio’s campaign finance. And at this point, a lot of people have seen this chart. We talked about the results before and adapted some of the ongoing work to the

[10:57] data set. So, you can download it for yourself, prompts and everything. What we didn’t talk about is everything behind that one arrow and what happened when you ran the same idea on the whole state. Here all of the architectures we tried. We started with three designs on a small development set. A cheap reasoning model on its own, Jev with a reasoning model for anything it wasn’t sure about, and a reasoning model proposing answers with Jev checking them. On about 200 health out families, the cheap reasoning model on its own did

[11:28] as well as Fable for about 2% of the cost. Jev first got the core answers right, but it missed nine household links because it had confidently said no to every one of them. So, we rewrote the questions. Without touching the models of the thresholds, the household question now said what counts as enough evidence, and Jeff went from no on all 13 development questions to yes. And as we scaled it statewide, we ran over a dozen rounds of such qualification. Each round fixed a definition, what a committee is, what a

[11:58] filer means, when two people live at one address, what does that mean? Every one of Ohio’s 203,317 cases now has a label that says what the answer rests on and how far it was checked. This is the hierarchy we discovered for this specific problem. And here’s everything we learned about putting decision models into pipelines. I’ll leave this up so you can screenshot it. But here’s where the money went. The whole statewide job came to 795 on an $800 budget that was set ahead of time.

[12:31] Checking cost about four times as much as doing, 545 on second opinions, settling disagreements, and the audit against 128 for first answers. Before Jeff, we expected this work to cost about $10,000. And now that the pipeline is built and verified, we expect the audit budget for the next state to be close to zero. The most amazing thing is that our agent 4A, running on Astra and then later on Opus, found most of these approaches incrementally on its own. By building

[13:01] the system, running it, debugging it, and trying new things. It ran for 10 days, tried over a dozen architectures. Its hangs ran for more than 4,000 times alongside 90,000 calls to Jeff, tried practically every model on the Pareto frontier, and the models inside those runs went through roughly 6 billion tokens. And once all of that was done, we wrote what we learned back into our library of agentic parts. This work leaned on these existing ones and we’re adding new tested ones like

[13:32] the checking letter. This is to me the value of taking work off the main thread for humans and for agents because every single one of these iterations was a version controlled Hank. They were easy to revert, understand, debug, and critique. So, can models do this natively now? Not quite. They’re missing four things which we’ll we’ll go over and there’s something that doesn’t go away though as models get bigger and more capable, the prior. Just like humans, models bring their own

[14:04] priors, their beliefs about what should be in the world to every task. This is the fourth schema that I mentioned before, the one the model brings with it. Bigger models in a strange way are worse at this sometimes. They hold onto their beliefs and argue for them even more vehemently. Here’s a few that we ran into. One pipeline looked for in kind spelled with an underscore. The file spelled it with a capital I and a hyphen. So, the model counted 15,658

[14:34] in kind contributions as ordinary money, didn’t double-check. The loan payment repayments also disappeared the same way. Another one tried four date formats when the file used the fifth. 99.4% of transaction dates then came out empty and every row count and dollar so matched so the agent moved on. Several runs noticed that loan amounts were negative, decided that the sign was redundant, and stored the absolute value. A net of 784,000

[15:06] became 5.3 million dollars of debt in the end, validated by multiple models. And this is quickly becoming the largest class of error I see across companies at data work as models take over. Sometimes you can solve this just by not vibing, by checking results and applying human intuition. And what you’re actually doing there when you do this is interesting. You’re intersecting your priors with the models. In that first example, any human would catch missing in-kind contributions if they knew campaign finance or thing to

[15:37] check. So, we found it. But humans, speaking as a human on this particular task, are expensive. They are slow, they pause timelines, they’re even more non-deterministic than models, and they hate interruptions. And what it turns out you can also get really far with cross-model prior intersection. On our 200 held out families, Jev and Luna agreed on 194. And none of those shared answers was wrong. Every error sat in the six families where they disagree. Models from different families,

[16:08] different pedigrees, tend to disagree more and have different priors than models in the same group, for example. The exception, I’m not going to say who, are models that are distilled outside the same company. So, with that kind of work, you can shrink the surface quite a bit, and the errors along with it down to a much smaller but persistent class of problems that apply to LLMs as a species. So, in one benchmark, four different model families produced the same total down to this end because they all shared a sign convention that the answer key

[16:39] didn’t. And once you get that far, the only way forward is to list them, look out for them, and apply specific solutions. So, going back, what are the four things we’re missing to be able to self-optimize? Number one is a stable deployment surface. We use Hank Weave for this, a harness that takes the fast-moving surface of agent runtimes like cloud code and pie, and then exposes a consistent, well-tested log and API interface with checkpointing, rollback, budget enforcement, everything built in.

[17:10] Something you can build on. But other things fit this description. To be fair, for headless data work, Hank Weave, I would say, still the oldest, most stable, and the most open. I’ll leave the skill up if you’d like to try it. Number two is some way to bound your experiments. You can’t test unless you can control cost, time, and access as resources. The third one is know-how and methodology. We found that this new class of models can take everything we’ve learned from two years of deployment, agentic

[17:40] patterns, debugging techniques, prompting, and apply to complex problems. With the right abstraction layer, you can express it very token efficiently, and the models can implement it. The fourth and the most important one is a failure surface. Archimedes said, “Give me a place to stand, and I will move the Earth.” And in our case, we haven’t met a problem or a constraint that we couldn’t iterate ourselves to solving given a stable stack to build on and a failure surface to iterate against. That last one has been the hardest to put into words and

[18:11] into tooling and instructions that helps models get there. The current best models are still only barely good at this, sparks of intelligence, so to speak. The whole process though involves going through six stages. First, we inspect the job and we split it. For Jeff, that means splitting some 800,000 rows into 200,000 smaller, specialized cases, and each of those cases into typed questions. What kind of donor, one donor, you know, different different questions that needed to get answered. Then we decide the failure surface. In

[18:42] this case, we ran good models on a small slice of the data with some of it being manually checked to set a baseline that we can fail against. In other cases, we’ve set automated failure systems, we’ve set schema checks, we’ve also covered behavior as a thing that we can measure against, but it’s very important to have to define a failure surface before you ever start. But now comes the fun part. We want minimal bounded pilots to test architecture. And once something starts working, we move those tags into rigs. Code that

[19:14] runs between bounded work segments that we call codons. These codons are then reused, looped independently, validated, and placed in sequence. Finally, working pipelines get deployed to production, where they can slowly mature. And that middle part is where the surfing happens. We find an architecture that gives a solid result, we use it as a baseline, and we swap models and some other parts for faster and cheaper options, compare against known intermediates, tighten the requirement for success, each time

[19:44] moving closer and closer to the ideal, and you just watch the frontier move. Being able to break a complex problem into pieces means each piece can move its own to its own best position, as Adam Smith would say. In a system like this, ontologies exist as intermediates between intelligence and result, which makes them easier to reuse. That’s the other half of what I mean by just-in-time ontologies. It’s built when the job needs it, kept with its receipts, and reused when the next

[20:15] job needs the same thing. And once you have those, you can make these things cheaper. You can you can run them in parallel across data sets to scale up. I close with an apology, right? That the answer is there is no ontology. Not a universal one, at least. There never was one. The good news is that this makes every ontology and schema valid, as long as you can label and preserve the context around it. And if we can harness this cheap intelligence is starting to percolate through the world around us, we’re rapidly approaching a future where

[20:47] any information, in any format, is made as useful as it can be. And at Outpace, we’re working as hard as we can to make that future a reality. Thank you.