SkyDiscover — Podcast da Weaviate 147

Ver no idioma original →

Autoria: Weaviate vector database · 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: SkyDiscover — Weaviate Podcast 147 · Canal: Weaviate vector database · 52:22 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Dados, bancos de dados e embeddings, Engenharia de software com IA

Resumo

A equipe do SkyDiscover conversa sobre o uso de agentes de IA para projetar, otimizar e sintetizar sistemas de software especializados, como bancos de dados e mecanismos de inference. A proposta é criar sistemas ajustados a workloads específicos, em vez de depender sempre de soluções genéricas, sem abrir mão de correção e confiabilidade. Para isso, o framework combina especificações fornecidas por pessoas, perguntas para esclarecer requisitos, testes e, quando possível, verificação formal. A conversa também aborda os desafios de avaliar desempenho, escolher entre adaptar sistemas existentes ou começar do zero e ampliar essas ideias para produtos de software.

Pontos-chave

• O desenvolvimento com IA está passando da geração de trechos de código para a criação de sistemas completos, que precisam ser escaláveis, extensíveis e confiáveis em produção.
• Sistemas especializados podem superar soluções genéricas ao serem ajustados aos workloads, recursos e objetivos de cada usuário.
• No exemplo de um key-value store, os requisitos incluem proporção entre leituras e escritas, consistência, confiabilidade, recursos disponíveis e metas de latência ou throughput.
• O framework deve esclarecer requisitos que não foram especificados, em vez de presumir respostas e permitir que o agente explore brechas nos critérios de avaliação.
• Testes precisam representar as propriedades especificadas; testes mal projetados podem aprovar sistemas que parecem rápidos, mas não fazem o trabalho esperado.
• A verificação formal pode oferecer garantias mais rigorosas, mas exige especificações adequadas, que variam conforme o domínio.
• A escolha da linguagem e do nível de abstração envolve compromissos entre desempenho, segurança e facilidade de verificação.
• Começar do zero pode produzir designs melhores do que adaptar um sistema existente, embora a escolha dependa do custo, do tempo e das garantias necessárias.
• Avaliar e otimizar sistemas exige executar workloads e testes, o que pode consumir muito mais tempo do que as alterações de código.
• A equipe vê potencial para aplicar essas técnicas a produtos, mas destaca a dificuldade de formalizar o que as pessoas esperam de aplicativos como ferramentas de anotações.

Capítulos

Início	Capítulo	Resumo
00:01	Apresentação da equipe	Os participantes apresentam suas áreas de pesquisa e como chegaram ao trabalho no SkyDiscover.
05:11	Da geração de código à síntese de sistemas	A equipe explica por que construir sistemas completos exige mais do que gerar funções ou arquivos de código.
09:21	Bancos de dados ajustados a workloads	O episódio detalha como requisitos de leitura, escrita, consistência e recursos influenciam o projeto de um key-value store.
13:27	O que é o artefato de software?	A conversa explora a ideia de que o resultado pode ser um sistema criado sob medida a partir dos traces e requisitos do usuário.
19:06	Especificações, testes e reward hacking	Os participantes discutem como esclarecer requisitos e impedir que a otimização explore brechas nos testes.
23:47	Testes e verificação de propriedades	A equipe explica como vincular testes a requisitos de correção, recuperação e desempenho.
27:23	Linguagens e níveis de abstração	A escolha entre linguagens e implementações de alto ou baixo nível depende dos requisitos de desempenho e segurança.
33:32	Adaptar sistemas existentes ou começar do zero	Os participantes comparam a otimização de bancos de dados existentes com a síntese de um sistema novo.
38:09	Sistemas especializados em infraestrutura gerenciada	A conversa considera como um serviço hospedado poderia adaptar continuamente seu sistema ao tráfego observado.
41:18	Especificar produtos de software	A equipe contrasta as especificações técnicas de sistemas com a dificuldade de descrever produtos voltados a pessoas.
45:57	O desafio de otimizar sistemas	Os participantes abordam a escala das bases de código, os custos de avaliação e os trade-offs entre métricas.
49:04	Evals e evolução das especificações	A conversa conclui que agentes precisam ajudar a identificar o que testar e quais partes do sistema otimizar.

Citações

Você usa algo que foi construído para centenas de casos de uso, mas talvez conheça bem o seu caso de uso. — 06:46

O problema que resta é: podemos confiar no sistema que construímos? — 14:29

Você precisa pensar em para onde as coisas estão indo, não apenas em onde elas estão. — 38:09

Na geração ou otimização do key-value store, provavelmente 80% a 90% do tempo é gasto em avaliações. — 48:02

Conceitos e entidades

• SkyDiscover (repo): Projeto de pesquisa discutido no episódio sobre o uso de IA para sintetizar e otimizar sistemas de software.
• SkySynth (ferramenta): Nome usado na conversa para o sistema ou pipeline de síntese que orienta agentes na construção de sistemas especializados.
• key-value store (conceito): Tipo de sistema de armazenamento usado como exemplo para discutir especialização por workload.
• RocksDB (ferramenta): Sistema usado como referência na comparação de desempenho mencionada para sistemas sintetizados.
• Redis (ferramenta): Banco de dados citado como exemplo de sistema existente que pode ser adaptado ou comparado a uma implementação especializada.
• YCSB (ferramenta): Conjunto de workloads mencionado no episódio para testar sistemas de armazenamento.
• Lean (ferramenta): Linguagem e assistente de provas citado como exemplo de recurso para especificação e verificação formal.
• Rust (ferramenta): Linguagem mencionada como opção quando a segurança de memória é um requisito importante.
• Geppa (ferramenta): Método citado na conversa como ponto de comparação para a otimização evolutiva de sistemas.
• Ion Stoica (pessoa): Pesquisador e orientador de vários participantes do episódio.
• Weaviate (empresa): Organização responsável pelo podcast em que a equipe do SkyDiscover participa.

Tradução completa (pt-BR)

00:01 [música] [música] [música] [música]

00:32 [música] >> Alex Mert, Shoe, Shoven. Bem-vindos ao podcast da Weaviate. Muito obrigado por participarem. >> Muito obrigado. Sim. >> Obrigado por nos receberem. >> É, obrigado. >> Ótimo. Bem, estamos com a casa cheia. Acho que o trabalho por trás do SkyDiscover é realmente fascinante. Estou muito animado para conhecer a história. Talvez especialmente porque temos aqui um painel bem grande. Vocês poderiam contar um pouco sobre a trajetória de cada um e como começaram a trabalhar no SkyDiscover? >> Certo. Talvez eu possa começar.

01:02 Olá. Meu nome é Shoe. Atualmente, estou no quinto ano do doutorado no Sky Computing Lab, sob orientação de Ion Stoica. Meu trabalho tem se concentrado principalmente em sistemas distribuídos e sistemas de armazenamento e, recentemente, passou a se voltar mais para sistemas de IA e para como a IA pode resolver tarefas de sistemas complicadas e cada vez mais complexas. >> Talvez eu possa ir em seguida. Também estou no quinto ano. Sou Alex Krenzler, doutorando no quinto ano sob orientação de Sylvia Ratnasamy.

01:32 Mas trabalho bastante próximo de Scott Shenker e Ion Stoica. Venho da área de redes fundamentais e sistemas de rede, sistemas de controle da internet em escala global e arquitetura da internet. Mas, especialmente no último ano, passei a trabalhar com descoberta impulsionada por IA e, agora, com a equipe do SkyDiscover, com síntese impulsionada por IA. >> Certo. Tudo bem. Sou Mert. Estou no quarto ano do doutorado em EECS na UC Berkeley. Tenho como orientadores Ion Stoica, Alex Tamarkin e Kanan Ramachandran.

02:04 Meu trabalho é com sistemas de ML e, em particular, com esses algoritmos de escalonamento em tempo de teste. Como podemos torná-los mais rápidos, mais eficientes, mas também com melhor desempenho? Isso pode ser feito acelerando métodos como a decodificação especulativa ou melhorando o desempenho deles com algoritmos evolutivos, como fazemos no SkyDiscover. Estou muito animado por estar aqui. Obrigado por nos receberem.

02:34 >> Oi, sou Shubham. Estou no segundo ano do doutorado — acabei de começar o segundo ano. Também tenho trabalhado com sistemas de machine learning e, recentemente, tenho me concentrado mais no uso de agents para construir sistemas e também no uso de técnicas formais e coisas do tipo para realmente garantir que os sistemas construídos sejam úteis na prática. Estou muito animado por estar aqui. >> Sim, incrível. Tenho visto um pouco dessa evolução rumo à construção de sistemas com IA que está acontecendo em Berkeley. Acho que o segredo já foi revelado. Todo mundo sabe que a IA programa muito bem. Já tivemos o

03:06 SWE-bench e todas essas diferentes tarefas de programação, mas essa evolução rumo à construção de sistemas inteiros me parece um conceito incrível. Talvez vocês possam explicar o contexto: o que significa a IA construir sistemas? >> Acho que vimos essa transição. Se pensarmos nos primeiros sistemas de IA, como o Copilot, eles tentavam apenas completar automaticamente, completar as linhas de código. E até isso era algo impressionante. Você começava a digitar e ele percebia: “Certo, aqui está o restante da variável que você está tentando atribuir”, ou algo assim. E depois avançamos um pouco mais

03:37 e você escrevia um comentário, e ele sintetizava uma função. E acho que, no último ano ou nos últimos dois anos, especialmente talvez a partir do Claude Code — foi em fevereiro passado? Há um ano e meio? — começamos a ver o que poderia acontecer se você desse acesso a arquivos e a uma visão em nível de arquivo da programação. Mas acho que, mesmo assim, as pessoas ainda recorriam a esses sistemas de programação e diziam: “Ei, me ajude a desenvolver uma função específica ou uma funcionalidade específica.”

04:07 Acho que a equipe do SkyDiscover — como dá para perceber, todos nós viemos de áreas relacionadas a assistentes — percebeu que há uma grande diferença entre um trecho de código, um algoritmo e um sistema. Em um sistema, você começa a pensar em como gerenciar a complexidade, organizando-a em camadas de abstração. E isso é importante porque sistemas não são algo estático. Você projeta um sistema para que seja escalável, extensível, interpretável e capaz de

04:39 rodar em produção. Pensar em uma tarefa assim envolve uma ordem de complexidade a mais. Estávamos observando o rumo que esses sistemas de programação estavam tomando e acompanhando essa trajetória: de completar linhas a gerar funções e, depois, trabalhar em nível de arquivo. Por isso, ficamos muito inspirados pela ideia de que essas coisas, que hoje exigem conhecimentos de nível de doutorado para construir — um banco de dados, um mecanismo de inference, um armazenamento de pares chave-valor —, poderiam evoluir. Se realmente traçássemos o rumo que estão tomando, como seria otimizar sistemas existentes com esse nível de complexidade ou sintetizar sistemas nessa escala? Essa é, em parte, a forma como estamos pensando nisso. >> Sim. E eu gostaria de acrescentar, por exemplo, que, desde o ano passado, bem no começo, quando esses modelos começaram a sair, vimos que eles resolviam tarefas de matemática cada vez mais complicadas e tarefas de programação bem simples. Agora, com as pessoas usando cada vez mais esses agentes de programação, e com eles sendo capazes de

05:11 sistemas existentes desse tipo de complexidade ou sintetizar sistemas nessa escala. É, é, sim. Essa é um pouco a forma como estamos pensando nisso. >> Sim. E eu gostaria de acrescentar, por exemplo, que, desde o ano passado, bem no começo, quando esses modelos começaram a sair, estamos vendo esses modelos resolverem tarefas de matemática cada vez mais complicadas e tarefas de programação muito simples, digamos. E agora, à medida que as pessoas começam a usar todos esses agents de programação com cada vez mais frequência, e esses agents de programação são poderosos em

05:42 gerar milhares de linhas de código, começamos a pensar: e quanto ao software que usamos no dia a dia? Como os bancos de dados que usamos, os sistemas de armazenamento que construímos ou até a inference, a pilha de pós-processamento que as pessoas estão otimizando especificamente para seus próprios requisitos e cargas de trabalho. Como a IA pode automatizar isso e otimizar toda essa pilha de acordo com os meus requisitos? E como podemos confiar no que quer que a IA tenha gerado? Dá para ver que esses agents geram um monte de tarefas e dizem: “Certo, os agents passaram em 300 de 300 tarefas”, mas isso é mesmo confiável? Então, quando a IA

06:14 se expande, quando você pode usar multi agents e tudo mais para aumentar a quantidade de código que gera, como garantir que ele realmente tenha bom desempenho e funcione como esperado? Foi por isso que mudamos um pouco o foco. Quando começamos o SkyDiscover, trabalhávamos na otimização de algoritmos, como algoritmos de escalonamento, controle de congestionamento e assim por diante, alguns dos problemas de sistemas que temos. Depois, passamos a nos voltar mais para a pilha de software de ponta a ponta e a analisar os desafios que existem. Sim.

06:46 >> Sim. Um comentário a acrescentar: na verdade, um dos focos do nosso trabalho foi algo chamado sistema just-in-time. Imagine que agora você é capaz de construir qualquer coisa que costumava usar de algum repo open source. Mas, é claro, o repo open source vem com algo que chamamos de “imposto da generalidade”: você está usando algo que foi construído para centenas de casos de uso, mas talvez conheça bem o seu caso de uso. Conhece bem a sua carga de trabalho. Na verdade, talvez em alguns dias possamos mostrar algo mais: estamos pensando que os mecanismos de inference que construímos para dispositivos — na verdade, Mert está liderando um deles — podem ser muito mais otimizados. Se você criar seu mecanismo de inference especificamente para uma máquina Mac com Metal, para um modelo e uma carga de trabalho, poderá fazer muitas otimizações que não conseguiria fazer se estivesse trabalhando com uma configuração genérica. Isso libera esse potencial, mas, como agora você está usando agents, tudo fica muito, muito frágil. Os agents fazem centenas de gambiarras, e há muitas coisas que os agents vão

07:17 conseguir mostrar algo ainda mais: estamos pensando que os mecanismos de inference que construímos para dispositivos — na verdade, Mert está liderando um deles — podem ser muito mais otimizados. Se você criar seu mecanismo de inference especificamente para uma máquina Mac com Metal, para um modelo e uma carga de trabalho, poderá fazer muitas otimizações que não conseguiria fazer se estivesse trabalhando com uma configuração genérica. Isso libera esse potencial, mas, como agora você está usando agents, tudo fica muito, muito frágil. Os agents fazem centenas de gambiarras, e há muitas coisas que os agents vão

07:47 apenas encontrar maneiras de quebrar as coisas e explorar as lacunas que vemos nos requisitos e no modelo, que é como o mundo em que a versão final será implantada. Então, diante dessas lacunas, o projeto SkySynth é uma espécie de abordagem nossa para lidar com isso, tentando garantir que os agents façam o trabalho certo e não tentem explorar as lacunas que já existem em qualquer sistema de software. >> Sim, então acho que talvez eu possa começar

08:19 a aplicar algumas dessas ideias realmente interessantes, mas, se eu puder começar por uma perspectiva talvez um pouco egoísta, do ponto de vista da Weaviate e dos nossos bancos de dados vetoriais, apresentamos muito esse argumento de que temos um banco de dados vetorial especializado. É um banco de dados personalizado para busca e armazenamento vetoriais, desde a forma como você implementa, por exemplo, um LSM personalizado, até os índices personalizados. E então, bem, tivemos um podcast com Andy Pavlov, da Carnegie Mellon, um conhecido professor de bancos de dados, que explicava essa divisão dos bancos de dados autônomos

08:49 . E eu sempre imagino que isso seja meio parecido com hiperparâmetros, sabe? Por exemplo, com o índice vetorial HNSW, você tem o parâmetro EF max, esses pequenos parâmetros de ajuste do índice, ou pode definir com que frequência o LSM será compactado, ou como a replicação está configurada. Então, estou curioso para saber se podemos começar pelo exemplo dos bancos de dados. Sei que o artigo descreve um armazenamento de chave-valor personalizado, e eu adoraria entender como o SkySynth poderia criar um banco de dados para uma carga de trabalho especializada e

09:21 o que você acha que será o futuro dos sistemas de bancos de dados feitos sob medida. >> Então, acho que essa é uma pergunta muito boa. Começamos a trabalhar em armazenamento de chave-valor principalmente porque esse tipo de armazenamento tem muitas propriedades diferentes. Você pode pensar, por exemplo: quantas solicitações você tem? E, nessas solicitações, quantas são de leitura e quantas são de gravação? E, entre esses requisitos para criar um armazenamento de chave-valor, quais são os recursos disponíveis?

09:51 Você está criando um armazenamento de chave-valor para uma única máquina? Ou está criando um sistema distribuído, no qual precisa gerenciar a consistência e coisas do tipo? E quais são seus requisitos de consistência? Quando você recebe o valor da sua chave, consegue tolerar alguma defasagem para talvez obter uma latência melhor ao responder à solicitação? Então, há muitas dimensões diferentes de propriedades aqui. Elas podem ser separadas em requisitos como, por exemplo: quão confiável é o sistema? Quão confiável é o seu armazenamento de chave-valor ou banco de dados? E se ele falhar?

10:22 Quanto tempo levaria para se recuperar? Essa é uma perspectiva. A segunda perspectiva, como mencionei antes, é a consistência. Que nível ou que requisitos de consistência você exige para a sua configuração? E qual é também o seu objetivo? Você vai otimizar a taxa de transferência ou a latência? E quais são os cenários da sua carga de trabalho? Há uma gama muito diversificada, ou dimensões muito diversas, de requisitos e aspectos que podemos potencialmente especializar. Por exemplo, se todas as suas solicitações forem para chaves quentes

10:53 , você pode projetar o cache de leitura para armazenar em cache todas as chaves quentes na memória, de modo que não precise buscá-las no disco, por exemplo. Mas, se todas as suas solicitações forem de gravação, você projetará algo completamente diferente em comparação com uma carga de trabalho com muitas leituras. Então, começamos a explorar, basicamente, rastros existentes. Alguns desses rastros são básicos, mas os ajustamos de maneiras diferentes para que tenham proporções diferentes entre leituras e gravações. E

11:25 também temos alguns rastros de produção que obtivemos da Tencent, além de todos os outros rastros do Twitter. Então, analisamos se, com as informações sobre essa carga de trabalho e sabendo quais funções objetivo se quer otimizar, a IA consegue gerar algo melhor, por exemplo, em comparação com RocksDB, Redis e outros. E, de fato, esses agents estão propondo novos designs, diferentes tipos de designs de cache para diferentes cargas de trabalho e requisitos. E também diferentes

11:56 tipos de gerenciamento hierárquico de memória: você coloca na memória caches de tamanhos diferentes ou coloca no disco coisas de tamanhos diferentes. E, no caso do gerenciamento de consistência, como garantir que o sistema esteja correto para manter, por exemplo, a consistência de leitura após gravação ou a consistência forte, se era isso que você esperava? Criamos, acho, entre seis e oito tipos diferentes de rastros e então verificamos, com essas informações para aquela

12:26 carga de trabalho especializada específica, se os agents conseguem se especializar para ela. E, de fato, eles alcançam um desempenho até quatro vezes melhor em comparação com sistemas até muito especializados, como os da Microsoft. E, sim, vimos um bom desempenho nisso. >> Acho que minha primeira pergunta é… Bem, não quero desviar demais o assunto, mas isso seria construído sobre um sistema existente? Você acha que… Deixe-me perguntar de outra forma: penso nisso meio como um DS Pi para sistemas, ou nas especificações; acho que há um artigo que veio de Berkeley e de Jared Davis, com essa ideia de abstrair a forma como você projeta um sistema. Então, isso quase me faz perguntar: o que é software agora? O que acontece com o artefato do sistema que é criado? >> Sim, também estamos muito curiosos sobre essa questão. O que

12:56 é o artefato agora? Olha, se levarmos nossa visão ao extremo, você está tocando em algo realmente interessante. Se levarmos nossa visão ao extremo, chegamos a um ponto em que o artefato é, de certa forma, uma função única: uma saída em função dos rastros que você fornece. E a razão pela qual tínhamos artefatos antes, por que essas coisas existiam por conta própria, por que você tem algo como o Redis, é que costumava levar anos e anos para construir esses sistemas. Levava anos para treinar alguém a entendê-los. Uma equipe de engenheiros, ou uma equipe de doutorandos, levava cinco anos para construir um sistema, torná-lo robusto e deixá-lo

13:27 em condições de ser confiável em produção. E ninguém vai escolher construir um sistema totalmente novo, a menos que seja a Meta ou o Google, com uma escala enorme e, sabe, com uma economia que realmente justifique os milhões de dólares que custa desenvolver um sistema personalizado. Caso contrário, não faz sentido para ninguém mais. Acho que estamos tentando construir um sistema que parte da ideia de que, se você pudesse contratar um monte de pessoas para construir um banco de dados personalizado só para você, exatamente para as coisas que quer armazenar, poderia obter um desempenho melhor. Mas isso costumava custar muito, e estamos reduzindo bastante esse custo com coding agents e

13:59 com os frameworks que temos. E acho que, como True disse corretamente antes, o problema que resta é: dá para confiar no sistema que construímos? E grande parte da nossa pesquisa nos últimos quatro meses tem se concentrado em como provar que o sistema que construímos está correto, seja por meio de testes e de uma suíte de testes abrangente que evolui, seja por meio de especificação formal e verificação formal, como uma garantia de que está correto. >> Sim, acho que talvez o assunto que aprofunde mais os detalhes seja como vocês pensam sobre testes, e eu…

14:29 com os frameworks que temos. E acho que, como True colocou muito bem antes, o problema que resta é: podemos confiar no sistema que construímos? E grande parte da nossa pesquisa nos últimos quatro meses tem se concentrado em como provar a você que o sistema que construímos está correto, seja por meio de testes e de uma suíte de testes abrangente e em evolução, seja por meio de especificação formal e verificação formal, como uma garantia de que está correto. >> Sim, acho que talvez o tema que aprofunda os detalhes seja como você pensa sobre testes e…

15:00 Desculpe se ficarmos falando de banco de dados, se você não se importar, e enquadrarmos isso principalmente pelo ponto de vista dos bancos de dados, só porque é disso que eu entendo. Mas talvez mais tarde possamos conversar sobre como isso poderia ser diferente para uma fila de tarefas em vez de um banco de dados. Mas, se pudermos continuar falando de bancos de dados, acho que talvez eu deva voltar um pouco e perguntar: como você pensa sobre a especificação? Como alguém chega e conta que tipo de carga de trabalho tem, que tipo de banco de dados precisa? >> Então, acho que há alguns requisitos relacionados aos ambientes.

15:30 Cada usuário, ou quem quer que esteja tentando construir algo para esses ambientes, tem os ambientes em mente. Por exemplo, quantas máquinas você tem e qual é a configuração de cada máquina, como o tamanho da memória e o tamanho do disco que você pode usar. Então, definitivamente, isso é algo que o usuário vai fornecer por padrão. E, se pensarmos em domínios diferentes, na verdade, cada domínio tem propriedades diferentes que o usuário talvez queira especificar. Isso pode partir de um nível bem alto. Digamos que eu fale apenas de confiabilidade. Por exemplo, se o seu banco de dados, ou o seu sistema de dados, falhar, quanto tempo você espera que ele leve para

16:01 se recuperar? E qual é a perda de dados que você consegue tolerar nesse caso? Talvez, na maioria das vezes, as pessoas não tolerem perda de dados em nenhum tipo de sistema de banco de dados que você criar. Então, por exemplo, confiabilidade é um aspecto, e o segundo é consistência. Quando os usuários fazem solicitações e leem seus dados, qual é o nível de desatualização dos dados que estão sendo lidos? Se você conseguir tolerar um nível maior de desatualização, talvez eu possa oferecer um desempenho melhor com o banco de dados que eu criar, certo? Então, essa é outra dimensão. E, quanto às cargas de trabalho,

16:32 em si, às vezes, quando as pessoas constroem seus sistemas, elas têm em mente as cargas de trabalho que terão. Por exemplo, no caso de um armazenamento de chave-valor, talvez você saiba qual é a proporção aproximada entre leituras e gravações. Qual é a recência ou a frequência de determinada chave nas suas cargas de trabalho, para que você possa otimizar seus sistemas para isso, certo? Como eu disse, se você tiver cargas de trabalho com muitas leituras, será completamente diferente de otimizar para cargas de trabalho com muitas gravações, considerando um nível de consistência diferente. Então, acho que há algumas características básicas sobre

17:03 digamos, as cargas de trabalho que você tem, os requisitos que você tem e, talvez, também as funções objetivo. Talvez você saiba que quer apenas minimizar os SLOs de latência do usuário e que tem uma restrição específica: não vou violar este SLO ao construir meu sistema. Então, há propriedades básicas que, digamos, provavelmente são conhecimento do domínio ou conhecimento especializado em um domínio específico. Por exemplo, acabei de listar algumas coisas sobre bancos de dados. Mas, em sistemas de armazenamento, talvez sejam outras. E, em sistemas de inference, seriam completamente

17:33 diferentes, certo? Então, provavelmente, nesses casos, consistência é algo entendido de outra forma, e correção também tem outro significado. Portanto, aprender o que deve ser incluído na especificação é algo muito específico de cada domínio. E provavelmente as pessoas vêm construindo sistemas há anos seguindo essa rotina, certo? Por exemplo, quando você escreve um artigo sobre a construção de mecanismos de banco de dados, talvez escreva sobre essa propriedade específica de tolerância a falhas, confiabilidade, consistência,

18:03 métricas de desempenho. Então, a partir do código ou da literatura, você sabe quais são as propriedades básicas que deve apresentar. E, se o usuário não souber — provavelmente devo dizer: “Ok, preciso especificar meu nível de consistência” —, a IA deve conseguir fazer a pergunta e dizer: “Ah, quais são os seus requisitos? Qual é a sua restrição aqui?”. Ela não deveria simplesmente presumir algo que o usuário nem sequer mencionou. Então, sinto que há uma lacuna: se você usar o CockroachDB de maneira ingênua, ele pode sair fazendo algo que você não espera. Mas, é claro,

18:36 se você tiver um bom pipeline e conhecer o domínio e o que as pessoas já construíram antes, saberá que existem vários princípios e propriedades relacionados aos artefatos desse domínio que você deve perguntar e esclarecer antes de prosseguir e construir um sistema totalmente novo. Então, acho que essa é a especificação que estamos tentando criar, e estamos tentando criá-la de modo que siga o conhecimento do domínio. Quando não devemos presumir algo, devemos fazer a pergunta. E, a partir daí, simplesmente prosseguir com a construção de sistemas especializados. E acho que essa

19:06 especificação pode ser, digamos — estou falando de uma situação em que sou apenas um usuário comum do CockroachDB e digito: “Quero criar um banco de dados para meu treino”. Espero que o Claude Code pergunte: “O que você quer otimizar? Quais são os seus requisitos de consistência? Quais são os seus requisitos de confiabilidade?”, e assim por diante. Mas, é claro, Shriram pode falar mais sobre como, se você já for especialista no domínio e souber o que quer escrever, provavelmente poderá escrever uma especificação formal. Então, os agentes de codificação, com base nessa especificação formal, podem gerar algum tipo de verificação, como uma prova formal,

19:38 para provar que ela foi totalmente satisfeita pela especificação. Sim. >> Sim, concordo totalmente com isso. Acho que há mais um ponto a destacar: como estávamos usando essa ferramenta para gerar sistemas, acabamos entendendo alguns dos pontos problemáticos. Por exemplo, escrever uma especificação é muito difícil. Não dá para esperar que um usuário apareça e descreva toda a rotina ou uma lista completa de tudo o que talvez espere de um sistema. Então, no pipeline, se você usar o Claude Code e escrever um bom prompt, ele pode fazer perguntas — ou pode mostrar que consegue fazer perguntas. Pode até exibir essa capacidade. Mas uma coisa que percebemos foi que, quando um engenheiro realmente constrói um sistema, durante o desenvolvimento do código, muitas lacunas começam a aparecer. E, quando essas lacunas aparecem, o Claude sempre escolhe o caminho mais barato. Por exemplo, se você pedir para otimizar o desempenho, ele vai partir do pressuposto de que a otimização de desempenho era fácil de fazer e não vai se importar se estiver recorrendo a um hack. Um exemplo muito simples: começamos a usar alguns traces de YCSB

20:09 fazer perguntas ou talvez mostrar que consegue fazer perguntas. Talvez até exiba essa capacidade. Mas uma coisa que percebemos foi que, quando um engenheiro realmente constrói um sistema, ou seja, durante o desenvolvimento do código, muitas lacunas começam a aparecer. E, quando essas lacunas começam a aparecer, Claude sempre escolhe o caminho mais barato. Por exemplo, se você pedir para otimizar o desempenho, ele vai partir do pressuposto de que é fácil otimizar o desempenho e não vai se importar se estiver hackeando. Um exemplo muito simples: começamos a usar o YCSB…

20:40 e coisas assim. E, de novo, se você não conhece o trace, ele é mais ou menos determinístico. Dada a chave, você consegue prever — ou nem precisa prever, consegue mapear — o valor a partir da chave. Os sistemas iniciais que construímos tinham 30 vezes mais throughput, 40 vezes mais throughput. E, claro, sem examinar nada, pensamos: “Ok, acho que construímos alguma coisa”. Mas, quando entramos nos detalhes, ficou muito claro que o Claude estava basicamente recorrendo a um hack, e isso era muito óbvio. Você… é como um axioma: em um sistema, não vou fornecer chaves cujos valores possam ser determinados. O importante é armazenar esses

21:11 valores. E, então, nossa percepção foi que, durante o desenvolvimento do código, mais e mais problemas acabam vindo à tona. E nosso sistema de síntese, o SkySynch, consegue revelar o nível certo de abstração para que o usuário possa responder. Então, novamente, fazemos dois tipos de geração. Um é uma geração em que você começa com os requisitos, como ela mencionou. Nesse caso, o projetista do sistema conhece, até certo ponto, os requisitos que quer. Mas talvez

21:41 não sejam as pessoas capazes de realmente fazer as coisas de maneira formal. Por maneira formal, imagine o seguinte: se eu pedir que você escreva uma função de ordenação. É claro que você terá algumas propriedades, como: meus números negativos devem ficar do lado esquerdo, meus números positivos devem ficar do lado direito. Se houver duplicatas, é assim que vou lidar com elas. Então, você pode fornecer algumas especificações de alto nível sobre o que quer. Mas, se estiver trabalhando em um domínio muito crítico — por exemplo, em bancos de dados —, é claro que você sabe que há propriedades como read-your-writes com as quais se importa. Às vezes, essas propriedades…

22:13 …são muito difíceis de definir em linguagem natural. Porque não é claro: você está falando de concorrência, distribuição. E não é fácil, a menos que comece a definir as coisas em um formato um pouco matemático, que chamamos de linguagem formal. Era isso que Lean e Rock costumavam fazer. Então, no nosso pipeline, quando um usuário chega com um design de sistema ou com algo que quer construir, o sistema agentic vai sondar o usuário com o nível certo de perguntas. E vai seguir o caminho formal…

22:43 …ou o caminho orientado a testes. E, nesse caso, nosso loop foi projetado para continuar identificando as lacunas que o usuário deixou passar. E, quando essas suposições exigirem a participação do usuário, ele será consultado. Caso contrário, serão feitas suposições no nível adequado para que o sistema possa ser construído de maneira mais robusta. Então, a pressão de otimização é algo que leva a reward hacking, e Sky é, de certa forma, uma vacina que basicamente impede o sistema de fazer muito reward hacking. >> Sim, isso meio que me lembra o Claude Code.

23:16 Tipo, sabe, ele escreve alguns testes. É como: “Passei no teste que acabei de escrever”, e coisas assim. E, quer dizer, é incrível pensar que ainda parece que você tem os dados de treinamento e os dados de teste clássicos de deep learning e machine learning. Mas agora, em vez de um modelo treinado, o artefato é código, um sistema. E os dados também são mais persistentes, acho, do que… Bem, no sentido de busca e recuperação de informações, você tem essa persistência do corpus. E talvez isso entre nessa parte do território, mas…

23:47 …sim, acho que talvez falando de testes, você mencionou prova formal. Isso me faz pensar: se eu disser “preciso que você ordene estes números”, então o sistema talvez use bubble sort ou quicksort. Como eu sei, então, a diferença entre o sistema ter usado bubble sort ou quicksort? >> Sim, idealmente, esse tipo de coisa você deveria especificar quando pedir pela primeira vez…

24:18 …que Sky sintetize essas coisas. Mas nosso sistema primeiro tenta entender o que você quis dizer na especificação da tarefa. Então, se você pedir que ele crie um algoritmo de ordenação, provavelmente ele vai perguntar: “Você tem alguma preferência quanto à complexidade temporal?”. Aí, se você não disser nada e responder “Tudo bem, só me dê um rápido”, ele fará uma…

24:50 …revisão da literatura e tentará ver que outras bases de código existem nesse domínio. Depois, tentará implementar o que considerar melhor, dadas as especificações que você forneceu. >> Então, basicamente, os testes devem estar bem alinhados com as propriedades que você especificar, certo? Por exemplo, se você não provar formalmente a consistência ou qualquer outro nível de tolerância a falhas, provavelmente vai querer fazer alguns testes de estresse…

25:20 …para avaliar a tolerância a falhas do sistema, certo? Você pode enviar várias solicitações, muitas solicitações simultâneas também, e ver se ele falha. E, quando falhar, verificar quanto tempo leva para se recuperar. Acho que as pessoas também fazem esse tipo de desenvolvimento orientado a testes em sistemas de produção, porque não conseguem especificar formalmente cada parte ou componente do sistema de ponta a ponta. E esses testes de estresse estão alinhados com propriedades específicas que você deseja, e normalmente quer verificar, por exemplo: quanto tempo…

25:51 …ele leva para se recuperar, se faz coleta de lixo e se, quando a carga de trabalho muda, ele quebra completamente ou algo assim. Então, sim, os testes estão basicamente alinhados com o que você especifica e com o que os usuários querem na especificação. >> Sim. E, em geral, você colocou esse ponto muito bem: esse Claude vai basicamente dizer que gerou 100 testes e que os 100 estão passando, porque escrever testes de boa qualidade que realmente capturem essas especificações é fundamental. E, no…

26:21 …pipeline, a ideia é que cada teste adicionado realmente faça cumprir essa especificação. Então, há alguns detalhes aqui: o teste terá que demonstrar que está realmente testando aquela especificação específica, por exemplo, gerando uma implementação de referência que esteja correta nesse aspecto e incorreta naquele aspecto. E, se conseguir distinguir isso, só então esse teste funciona como uma barreira que pode permitir ou não que um sistema passe. Então, é uma maneira mais rigorosa de fazer as coisas, porque o domínio realmente exige que você cuide…

26:52 …dessas especificações. >> Sim, quer dizer, isso me interessa muito e me faz pensar em Python versus Go e em como você pensa na abstração daquilo com que o sistema está trabalhando. Porque, se for algo como Go — ou talvez Rust, que eu sei que é mais popular —, eu usaria Go. Talvez não seja isso que quero dizer com uma linguagem um pouco de baixo nível. Mas estou pensando em algo como alocação no heap, e acho que isso é bem diferente quando você…

27:23 …não sei se você quer chamar isso de vibe coding ou de algo como o que chamamos de programação com LLM, mas acho que a linguagem usada nisso influencia bastante a maneira como o sistema lida com essas especificações. Só estou curioso para saber o que você pensa sobre isso, talvez até sobre linguagens de programação em geral. >> Sim, quer dizer, é uma boa pergunta. Então, uma coisa a considerar ao construir um sistema é que, claro, você pode ter preferências, essa é uma possibilidade. Mas, se…

27:54 …não tiver preferência, o objetivo do sistema é otimizar para uma carga de trabalho específica. Então, você realmente se importa com o desempenho naquela parte. E, quando se importa com o desempenho, ao começar a chegar aos pontos cegos, pode haver linguagens com as quais seja fácil eliminá-los. Por exemplo, se você se importa com algo em que a segurança da memória é importante, o sistema vai orientar o agent a usar uma linguagem segura em relação à memória, como Rust, porque o…

28:25 …sistema será construído com mais cuidado e terá dificuldade para compilar; assim, o que for construído será seguro em relação à memória. Mas talvez o desempenho seja comprometido. Então, a linguagem também está muito ligada ao desempenho de que você precisa e às especificações que considera importantes. E, para garantir que essas especificações sejam cumpridas, você basicamente escreve testes. Então, por exemplo, se você trabalha com engenharia de kernel, um exemplo bem simples: é muito fácil escrever um kernel correto quando você começa com a…

28:55 em alto nível, digamos, com PyTorch ou uma linguagem parecida com Python, mas aí tudo o que importa para vocês é o desempenho. Agora, se você estiver lidando com uma TPU em vez de, digamos, uma GPU da versão X, vai querer entrar nessa pilha, onde ela permite escrever as coisas de modo que você possa fundir os kernels com muita eficácia ou, se for um kernel quantizado, se preocupar em minimizar os erros de precisão. Então, isso é realmente um detalhe de implementação com o qual o usuário não deveria se preocupar, a menos que tenha uma preferência. E é assim que nosso sistema atualmente ajuda o usuário: sob a condição — e essa é uma suposição — de que

29:26 isso esteja levando a um caminho em que a especificação precise ser alterada aqui ou ali, o usuário nem sequer será exposto a isso. Ele receberá a implementação que, idealmente, oferece o melhor desempenho e o mínimo de exploração da recompensa. Por mínimo de exploração da recompensa, quero dizer que, se for uma rota de testes, o mais importante é que os testes possam ser feitos muito, muito bem. Como eu disse, Rust será mais favorável se a questão for segurança de memória, mas, se houver situações em que você não se importe com isso e consiga obter um desempenho melhor sem se preocupar com os requisitos de segurança de memória em tempo de compilação

29:56 —, você seguirá, digamos, uma rota em C ou algo assim. E, por outro lado, no espaço formal, há novamente coisas como Lean e Rock, que atuam no mundo dos modelos, onde você tenta provar coisas. Mais adiante, você pode tentar usar linguagens mais antigas, como OCaml, mas, no cenário mais recente, também há compiladores como CompCert, no mundo de C, além de coisas como Verus, no mundo de Rust. Então, novamente, essas coisas estão muito, muito intrinsecamente ligadas ao que realmente importa para você, porque é possível escrever tudo em qualquer linguagem. O que

30:27 você escolher vai determinar basicamente o quão fácil foi testar aquilo e qual foi o desempenho no fim. Então, depende realmente do seu objetivo, daquilo que importa para você. >> É, você me dá vontade de relembrar o que sei sobre compiladores. Faz um tempo desde que eu… >> [risos] >> fiz tudo aquilo. E acho que… é, então, minha pergunta é: sabe, a partir das especificações, você poderia ir até o fim e talvez gerar um binário, de um jeito supermaluco. Tipo, você acha que isso algum dia acontece

30:58 ou sempre precisa haver algum artefato de código intermediário? >> Quer dizer, novamente, uma pergunta muito, muito, muito boa. O ponto principal é que, se você me der uma especificação e se importar principalmente com o desempenho, no fim das contas você realmente vai querer um binário que não tenha sido criado por um compilador que tenha feito suposições para acelerar sua implementação de forma geral. Então, você realmente quer que seu agent escreva código assembly para você, se não um binário, que

31:28 seja muito, muito eficiente no seu sistema. E, novamente, se ele conhecer sua carga de trabalho, pode fazer algum pré-carregamento e outras coisas que não podem ser feitas em linguagens de nível mais alto. Você quer chegar a esse ponto, mas obviamente há também um custo associado, porque seria necessário que o LLM iterasse cada vez mais para atingir esse nível. Então, é uma questão de estabelecer um limite e dizer: “Tudo bem, aceito executar este experimento ou tarefa de construção deste sistema por X horas e gastar N dólares com isso”. Nesse período, você realmente quer que seu sistema

31:59 chegue lá. Mas, novamente, depois que você tem uma versão, dá para fazer os LLMs trabalharem sem comer nem dormir. Então, num mundo ideal, basta pedir que otimizem ainda mais aquilo. E, nessa otimização, quando a linguagem se torna uma barreira — “Tudo bem, agora, para otimizar mais, só preciso passar para uma linguagem de nível mais baixo” —, é como engenharia de kernel. Depois que a ideia de como escrever o flash attention é inventada, você realmente precisa usar uma linguagem de nível mais baixo para fazer o acesso à memória, porque Python ou PyTorch não permitem fazer isso. Mas, enfim, espero que eu tenha respondido à sua pergunta; esse é o ponto. >> É, espero estar conseguindo manter a conversa, mas isso me faz pensar que, hoje em dia, acho que você teria de ser muito fera, como dizem, para gerenciar um repo com abstrações de várias linguagens. Acho que é mais ou menos para onde isso está me levando. Se eu tivesse um projeto em Python que também tivesse partes… Quer dizer, sim, você teria uma conexão… Desculpe, faz tempo que não faço projetos assim, em que

32:30 você conectaria C a Go. Faz tempo que não penso muito nesse tipo de coisa. Mas, é, legal. E acho que ainda estou pensando em coisas como construir sobre o Postgres ou sobre o open source da Weaviate, e em como você pensa em estender bancos de dados open source e no papel que isso tem a desempenhar nesta pesquisa.

33:02 >> Então, talvez… Acho que ainda estamos pensando ativamente em quais casos faz sentido sintetizar algo completamente do zero, em vez de otimizar sistemas existentes. É claro que sintetizar algo completamente do zero provavelmente pode levar bastante tempo. Então, talvez, no caso de sistemas muito maduros e prontos para produção, eles tenham sido criados para cargas de trabalho gerais e contem com muitos testes incorporados originalmente nos próprios sistemas, sejam eles open source

33:32 ou de código fechado. E, por isso, leva menos tempo para construir esses componentes. Mas sintetizar algo do zero talvez permita sair do ótimo local imposto pelas limitações da estrutura que o sistema geral tem. Digamos que eu fosse construir sobre meu sistema geral: talvez primeiro precisasse entender 40 mil linhas de código do sistema geral para conseguir perceber que, por exemplo, ajustar este parâmetro talvez funcione para esse tipo de carga de trabalho especializada. Talvez ajustar uma combinação destas duas configurações funcione para os meus requisitos específicos. Então, é claro,

34:04 que leva tempo entender as bases de código, e talvez a estrutura ou a abstração do sistema geral não seja a melhor para seus casos de uso especializados. Também não está claro se, em determinado caso, otimizá-lo pode realmente alcançar um desempenho melhor do que sintetizar algo completamente do zero. E, nos casos de uso de armazenamento de chave-valor, tentamos construir sobre o marker Microsoft faster e ver se ele conseguia fazer isso bem. Mas, comparando com nossos experimentos de síntese completamente do zero,

34:35 — do zero —, na verdade, isso alcança uma taxa de transferência menor do que simplesmente construir algo completamente do zero. E, é claro, com limitações de tempo, às vezes os agentes de codificação podem ficar presos no ótimo local, pensando: “Esta abstração é tudo o que tenho”. Então, acabam ajustando apenas alguns componentes do sistema. Mas, quando pensam em algo totalmente novo, talvez consigam chegar a um projeto melhor, dando um passo atrás e considerando em alto nível: como devo projetar minha memória? Como devo

35:05 coordenar a memória e o disco? E como devo lidar com todos os requisitos do usuário? Então, idealmente, acho que o sistema que estamos tentando construir é capaz de saber quando sintetizar e o que otimizar. Mas, ao mesmo tempo, seja otimizando ou sintetizando do zero, é preciso garantir que nada comprometa as garantias que o sistema deve oferecer, conforme especificado pelo usuário. A correção continua sendo importante mesmo quando você está apenas otimizando um sistema específico. Então, digamos que você altere o algoritmo de cache

35:36 coordenar entre a memória e o disco? E como devo lidar com todos os requisitos que o usuário tem? Então, idealmente, acho que o sistema que estamos tentando construir é aquele que sabe quando sintetizar e sabe o que otimizar. Mas, ao mesmo tempo, garantindo que, quer você faça uma otimização ou sintetize algo do zero, não comprometa algumas das garantias que o sistema deve oferecer, conforme especificado pelo usuário. Portanto, a correção ainda importa, mesmo que você esteja apenas otimizando um sistema específico. Então, digamos que você altere o algoritmo de cache…

36:08 ou os componentes de cache do Redis, e então, na verdade, algo quebra sempre que você insere uma nova carga de trabalho; aí, não está correto. Então, acho que, nos dois casos, devemos pensar: quais são os conjuntos certos de tarefas e quais são as garantias certas que devemos oferecer ao usuário para que ele confie no artefato final gerado pelos agents? E a segunda coisa, claro, é o desempenho. Dado um orçamento de tempo limitado, digamos, e também restrições de custo, é melhor começar, digamos, com um sistema existente e conhecido…

36:38 ? Se sim, começar com qual sistema? Porque há muitos tipos diferentes de bancos de dados open source por aí, e qual deles eu deveria escolher para começar? Ou, em vez disso, sintetizar tudo completamente do zero? Acho que, à medida que os modelos se tornam mais poderosos, esperamos que o modelo saiba qual especificação de alto nível cada sistema oferece e se cada sistema tem pontos fortes especializados para otimizar uma carga de trabalho específica, de modo que…

37:09 possa escolher dinamicamente entre: “Certo, vou otimizar o sistema e escolher este sistema para começar, porque ele tem propriedades que facilitam a otimização para mim”; ou simplesmente começar algo completamente do zero, quando vejo que certos recursos não são compatíveis com nenhum dos bancos de dados open source existentes. Nesse caso, posso muito bem criar meu próprio projeto. Tenho um quadro branco; talvez possa desenhar minha principal ideia de projeto para otimizar essas cargas de trabalho, e vou sintetizar algo completamente do zero. Então, esperamos que isso fique mais…

37:39 automatizado. E acho que, sim, estamos tentando criar algo que consiga fazer isso, mas o objetivo aqui é ter algo correto e também muito especializado em desempenho. Sim. >> Se me permitem, quero destacar como essa ideia é surpreendente. Acho que também nos surpreendemos quando chegamos a ela, mas, no estágio atual em que o campo está, se você trabalha com IA, não deveria estar projetando, construindo ou pensando no que está fazendo como algo para hoje. Você deveria pensar, se observar e acompanhar…

38:09 as tendências de para onde as coisas estão indo, precisa se antecipar ao destino, não ficar onde as coisas estão. E isso é algo realmente estranho, não é? Parece contraintuitivo pensar que você deveria começar do zero para criar seu sistema se já existe um sistema. Mas, se você partir do pressuposto de que o modelo está ficando cada vez melhor em construir, raciocinar e projetar, é muito fácil para ele chegar a qualquer projeto específico. Você deveria simplesmente deixá-lo começar do zero, sem nenhuma restrição, e isso, na verdade, leva ao melhor resultado. Antes, começávamos com sistemas existentes e isso nos dava um atalho. Economizávamos muito trabalho, mas, se esse trabalho é fácil para um modelo realmente inteligente…

38:41 não há necessidade de restringi-lo nem de fazê-lo começar daquele ponto. >> Sim, acho isso incrível, especialmente do ponto de vista da pesquisa e do que é possível, mas também tenho curiosidade: quando temos esses sistemas, como o Weaviate Cloud, acho que há alguns níveis nisso. Temos o conhecimento de como hospedá-lo, de como executá-lo em escala e de como depurá-lo. E acho que consigo imaginar esses sistemas tendo um enorme impacto nisso, se não sendo capazes de fazer tudo isso. Mas também há o conceito de infraestrutura gerenciada, em que você tem um provedor como o Redis, como mencionamos. Eles têm o Redis Cloud, então provavelmente ainda há espaço para esses sistemas que também oferecem infraestrutura gerenciada em outro lugar. Mas ainda é possível personalizá-los? Esta pesquisa tem alguma interseção com esse tipo de abordagem? >> Acho que sim, totalmente. Eu…

39:11 Acho que, sim…

39:44 Olha, há motivos comerciais independentes para você querer que outra pessoa hospede algo para você. Você simplesmente não quer ter pessoas de plantão gerenciando isso. Há também motivos técnicos: talvez você não tenha a equipe para desenvolver isso, verificar ou até mesmo redigir corretamente a especificação. Então, você vai pagar alguém — você sabe que o Redis tem a especificação certa para o sistema que você criou, e você não tem uma equipe técnica ou algo assim. Ainda acho que as ideias em que estamos trabalhando acabarão sendo incorporadas até mesmo a esses sistemas, porque dá para imaginar uma versão hospedada de algo como um Sky Synthesizer…

40:15 Sky Synthesizer Optimizer ou Synthesizer que, dado um conjunto contínuo de consultas, ótimo. Ainda há uma interface de gravações e leituras, mas, dadas as gravações e leituras das últimas 24 horas, eu deveria ter um sistema ressintetizado que funcione muito bem com essa distribuição de tráfego. Então, acho mesmo que isso vai se encaixar muito bem nesse modelo. >> Sim, é muito legal, porque você poderia ter essas máquinas com, já que tem um conjunto compartilhado de máquinas com RAM e disco, e então a alocação do que cabe nelas seria perfeita. Com essa nova abordagem, sim…

40:47 Nossa. Que legal. >> Sim. >> Sim, incrível. Bom, acho que talvez eu queira subir bastante o nível de abstração e falar um pouco mais amplamente sobre sistemas que as pessoas comuns talvez queiram usar. Alex e eu fizemos uma piadinha antes de começar a gravar: eu estava explicando ao Alex que uso o Zencastr para gravar, em vez do Riverside, e estávamos conversando sobre como acho que conheço um software que talvez consiga criar para mim um software de gravação de podcast. O que vocês acham dessa ideia de…

41:18 gerar software, por exemplo, para anotações ou e-mail? >> Posso tentar acrescentar brevemente uma coisa: os humanos são muito mais desorganizados do que as máquinas. Escrever a semântica, a especificação formal de um armazenamento de chave-valor, é complicado. É difícil escrever especificações. Estamos tentando facilitar isso. Também estamos fazendo pesquisa sobre o assunto. Mas existem linguagens formais para modelar a interação entre máquinas. É muito mais complicado modelar formalmente, por exemplo…

41:49 como especificar o que um aplicativo de anotações deveria fazer, certo? Muitas vezes, fazemos isso — e há pessoas que realmente fazem isso. Temos um nome para elas: gerentes de produto. Os gerentes de produto são responsáveis por fazer a ponte entre a ideia conceitual do que queremos e os engenheiros, tentando explicar a eles na linguagem deles — ainda em inglês, mas num inglês que os programadores entendam — para que os programadores escrevam isso em código. Então, conceitualmente, hoje, se você olhar para o SkySynth, ou para o framework Sky Discoverer em geral, quando…

42:19 pensamos em especificação, grande parte do nosso raciocínio envolve ou você nos dar uma especificação formal, ou descrever em linguagem humana o que quer, e nós gerarmos testes em código para representar a especificação humana, a intenção da pessoa. Provavelmente daria para chegar a um mundo em que fosse igualmente possível sintetizar conjuntos de testes de comportamento para um aplicativo de anotações: você pode fazer anotações, criar uma nova nota, descrever funcionalidades ou criar projetos no estilo PRD. É assim que se parece a especificação de um produto.

42:51 Acho que nós, como equipe da Sky Discoverer, estamos bastante focados no aspecto dos sistemas centrais, em parte porque é um problema muito difícil. Mas acho que o lado da síntese de produtos será muito interessante, assim como pensar em qual é o meio certo para registrar a especificação de um produto — para mim, é um PRD. Não estamos pesquisando isso, mas acho que algumas das técnicas que estamos desenvolvendo poderiam ser aplicáveis. >> Sim, sim, isso. Como Alex disse,

43:22 O Sky Discoverer Synthesizer tem dois eixos principais: desenvolvimento orientado a testes ou sistemas especificados formalmente, como fazer verificação formal em sistemas especificados formalmente. Infelizmente, é incrivelmente difícil capturar o que as pessoas realmente desejam em domínios como esses, que não podem ser verificados — por exemplo, “crie para mim uma boa aplicação web, uma interface agradável”. Então, também temos tentado criar algumas interfaces para alguns dos sistemas que

43:53 construímos usando o Sky Discoverer. Essa parte exige outro conjunto de habilidades, sem dúvida. >> Sim, e isso me lembra um pouco o que Shu estava explicando antes: a ideia de perguntar a alguém, por exemplo, que nível de recuperação você consegue tolerar? Já conversei bastante com startups e empreendedores, criadores de produtos, sobre essa ideia de comunicar essas ideias.

44:23 Acho que existe uma lacuna enorme aí, que é muito interessante. E, sim, algo bem específico: quando a especificação é um chatbot? Não. Isso. Legal. >> Sim, então, no início do nosso framework, há uma etapa de elaboração da especificação. Essa etapa recebe algumas especificações da pessoa sobre o que deve ser criado. No caso do desenvolvimento orientado a testes,

44:53 o framework basicamente verifica se a especificação fornecida pela pessoa está clara e é abrangente o suficiente. Nesse caso, ele começa a fazer uma análise do workload especificado. Vai verificar quais outras especificações existem em bases de código relacionadas, e assim por diante. Mas também há muitos casos, como você mencionou, em que as especificações de entrada não estão claras e

45:25 é preciso receber informações da pessoa. Então, sim, ele funciona como um chatbot, no sentido de que tenta esclarecer iterativamente com a pessoa o que está acontecendo. >> Sim, incrível. Sei que estamos quase sem tempo e geralmente começo o We Have Podcast com essa pergunta geral sobre o que entusiasma vocês em relação à IA, mas preciso fazer mais uma pergunta técnica sobre isso. Como vocês pensam em otimizar o sistema? Seria algo como o Geppa para o design de sistemas? Ou seria

45:57 tipo… >> Acho que, para começar, o problema da otimização de sistemas tem um escopo maior, porque os sistemas, se você se importa com um sistema, geralmente também são muito grandes. E até descobrir qual é a maneira certa de otimizar, qual é o objetivo, é complicado: uma base de código vai ser enorme, há centenas de coisas que você pode otimizar, mas há coisas específicas que vale a pena otimizar. E, na otimização de sistemas, também

46:28 há mais um ponto: ao contrário, digamos, da otimização de texto, a avaliação não é tão fácil. Se você realmente se importa, por exemplo, com o design de hardware ou com algo como mecanismos de inference, você otimiza alguma coisa, e o ciclo para obter o feedback completo envolve executar muitos testes. Se você se importa com VLMs, provavelmente há 25 mil testes ou mais. Depois, você precisa executar todos os workloads para verificar a correção e, em seguida, executar vários workloads — diferentes pre-fills, diferentes decodes, diferentes workloads agênticos — para obter alguns números em

47:00 termos de throughput, por exemplo, ou seja lá o que for. E, mesmo na otimização de texto, geralmente existe um espaço multiobjetivo com trade-offs. No caso da otimização de sistemas, o trade-off é muito concreto, porque, se você ajusta algo para economizar memória, seu throughput fica péssimo; ou, se ajusta algo para reduzir a latência, seu throughput simplesmente desaparece. Então, é muito difícil… E, como sempre, é muito difícil definir esses trade-offs. Não é como se a pessoa soubesse qual é o ponto perfeito. Então, na otimização de sistemas, que é

47:31 obviamente um dos eixos, a otimização de sistemas já existe há bastante tempo, e todas as leis de como encontrar os problemas certos para resolver e como otimizá-los já estão estabelecidas. No pipeline do Sky Discoverer, estamos tornando isso agêntico. E a próxima versão, que esperamos planejar, é aquela em que os agents conseguem, por conta própria, explorar os problemas certos. Os agents conseguem, por conta própria, criar pequenos simuladores, como você pode imaginar, ou algum tipo de avaliador substituto que lhes dê a capacidade de fazer uma busca por subida de encosta. Então, quando conseguirem fazer essa busca, isso

48:02 se torna um problema de busca por subida de encosta, essencialmente igual ao Geppa para otimização de texto ou a qualquer outra técnica que faça evolução sobre o texto. Mas o problema passa a ser identificar o problema e obter feedback de uma forma que o LLM consiga usar. Se eu… Se eu der um número para você na nossa geração de KV, na geração ou otimização de key-value, provavelmente 80% a 90% do tempo é gasto em avaliações. Só uns 10% são realmente manipulação de texto. Então, esse se torna o gargalo. E, se você quiser escalar seus agents, se quiser executar

48:33 centenas de agents fazendo isso, seu objetivo passa a ser um metaproblema: primeiro, encontre o kernel certo que deve ser otimizado e um proxy adequado para medir apenas esse kernel. Isso envolve detalhes muito específicos, ou seja, profiling muito detalhado, que vai ajudar a identificar como avaliar e como encontrar os gargalos, que são fundamentais para obter um desempenho melhor. Então, é assim que vemos isso: como um metaproblema que realmente não existe no espaço de texto, porque, no espaço de texto, é mais…

49:04 De novo, não é um problema mais simples. Não estou tentando sugerir isso, mas, nesse mundo, ele é mais bem definido e os gargalos são diferentes. >> Então, [limpa a garganta] voltando também ao que Alex disse no começo do podcast, sobre… Com alguns avaliadores, você poderia tentar otimizar algum prompt de um sistema ou de uma função que esteja realizando uma tarefa específica, como uma parte selecionada do sistema.

49:36 Mas, se você começa pelas especificações, nem sequer está claro quais devem ser os testes. Também não está claro quais partes da base de código você deve otimizar. Além disso, nem sequer está claro se as especificações estão completas. O usuário especificou talvez alguns workloads, mas, como você disse, espera-se que o sistema de design seja robusto. Ele deve

50:09 generalizar para perturbações em torno do que o usuário pediu. Então, você consegue criar outros workloads adversariais para testar o sistema? E, além disso, e se as especificações mudarem com o tempo? Você consegue se adaptar a esse tipo de ciclo externo e obter feedback humano para iterar ainda mais nos testes e nos workloads que serão usados para otimização? Então, sim, isso fica um pouco mais amplo do que os

50:40 >> [limpa a garganta] >> sistemas evolutivos clássicos que usamos para otimizar funções e coisas do tipo. >> Sim, acho que, se eu puder dar minha opinião rápida, penso nisso assim: o Geppa tem essa fronteira de Pareto de programas candidatos — geralmente, prompts, porque costuma ser usado para otimização de texto, mas também poderiam ser programas candidatos, como código para designs de banco de dados. E, então, a fronteira de Pareto, em vez de ser formada por exemplos de treinamento

51:11 E, de novo, no sentido textual, sabe, um prompt específico para escrever uma postagem de blog: esse prompt escreveu uma postagem de blog melhor sobre mitose do que o outro escreveu sobre outro tema de biologia. E é assim que você pensa sobre isso naquele mundo, mas, neste mundo, imagino que os testes meio que definam a fronteira de Pareto. Mas acho que o que estou aprendendo, o que eu concordo bastante com essa ideia, é que a otimização evolutiva também deveria criar testes. Ela deveria conseguir propor novos testes e evoluir esse conceito também, e

51:42 A otimização evolutiva é definitivamente um tema muito legal. É divertido pensar sobre isso. >> Incrível. Bem, Alex, Mark, Shue, Shobha, foi uma conversa muito divertida. Aprendi muito, e foi muito legal conhecer todos vocês. Muito obrigado por participarem do podcast da Weaviate. >> Muito obrigado. É muito… >> Obrigado. >> Sim. Obrigado. >> Foi muito divertido conversar com vocês. >> [música]

52:22 [música]

Transcrição original

[00:01] [music] [music] [music] [music]

[00:32] [music] >> Alex Mert, Shoe, Shoven. Welcome to the We View podcast. Thank you so much for joining. >> Thank you so much. Yes. >> Thanks for hosting us. >> Yeah, thanks. >> Awesome. Well, we’ve got a packed house. I think the work behind Sky Discover is just super captivating. I’m so excited to dive into the story. Maybe especially because we have sort of a a big panel here. Do you mind each maybe giving a little bit of your background and how you came to be working on Sky Discover? >> Um Okay, maybe I can get started.

[01:02] Um hello. My name is Shoe. I’m currently a 5th year PhD student at Sky Computing Lab advised by Ion Stoica. And then my work has been focusing on previously mostly about like distributed systems, storage systems, and recently moving towards more of like AI systems and like how AI can solve this like complicated more and more complicated like systems task. Yeah. >> And I maybe I’ll go next. I’m also a 5th year. I’m Alex Krenzler. I’m a a 5th year advised by Sylvia Ratnasamy.

[01:32] But I work pretty closely with Scott Shenker and Ion Stoica. I kind of come from core networking and core network systems, global scale internet control systems, and internet architecture. But especially the last year I’ve shifted into AI driven discovery and and now with the Sky Discover team into AI driven synthesis. >> Okay. Um all right. I I’m Mert. I’m a 4th year PhD student at UC Berkeley EECS. I’m co-advised by Ion Stoica, Alex Tamarkin, and Kanan Ramachandran.

[02:04] My work is on ML systems and particularly like these test time scaling algorithms. How can we make them faster, more efficient, um but also more performant. So by ways of either like making the accelerating like this speculative decoding like methods or um making them more performant with these evolutionary algorithms and like we have at Sky Discover. Um yeah, pretty excited to be here. Thanks for hosting us.

[02:34] >> Hey, um I’m Shubham. I’m a second year PhD student, just turned second year. And yeah, I’ve been working on machine learning systems as well and recently more focused on using agents for building systems and also in the area of using like formal techniques and things like that to actually guarantee that the systems built are practically useful. Yeah, pretty excited to be here. >> Yeah, amazing. I mean, I I’ve started seeing a bit about this evolution into AI building systems coming out of Berkeley. I think like probably the cat’s out of the bag. Everyone knows AI can code really well. We’ve had

[03:06] SWE-bench and all these different coding tasks, but this evolution into building entire systems, I think it’s just such an amazing concept. You might maybe now like setting the stage on maybe just what does it mean for AI to build systems? >> I think we’ve seen this transition where the very earliest AI systems, you think back to Copilot, were like just trying to auto complete, complete your lines. And even that was pretty magical. You would start typing and it would figure out, okay, here’s the remainder of the variable you’re trying to assign or whatever. Um and then we got a little bit further

[03:37] along and you’d have a comment and it would synthesize a function. Um and then I think the last year or two, especially maybe starting with Claude Code, uh was it last February, was it? A year and a half ago. Um we started to see what could happen if you exposed like files and a file level view of light coding. But I think even then people still were going to uh these like coding systems and say, “Hey, help me um help me build out a particular function or particular piece of functionality.”

[04:07] Um I think the Sky is Covered team, we were really looking at this as you can tell we all are really coming from assistant backgrounds um and you get this difference where there’s a big difference between a piece of code, an algorithm and and a a a system. In a system you start to kind of reason about how you manage complexity uh by putting it into kind of layers of abstraction. And you want to do this because systems are not kind of a static thing. You design a system to be scalable, to be extensible, to be interpretable, um to be kind of able to

[04:39] run in production. And it’s it’s kind of an order of more complexity kind of reasoning about a task like that. Um but we were looking at where these coding systems were headed and we’re kind of thinking and following that line and going watching it go from line completion to functions to file level. And so we were really inspired by the thought of these things that today take kind of PhD level expertise to go build um a database, a inference engine, a KV store. Um if we were to really like trace out where these things are headed, what would it look like to go and um optimize

[05:11] existing systems of that that kind of complexity or synthesize uh systems to that scale. Um um yeah. That’s a little bit of how we’re thinking about it. >> Yeah. And uh I would just like to add on like for example since last year like at the very beginning of like this model this models are coming out, we’re seeing this models solving more and more complicated let’s say like math task and very simple coding task. And now like as people are starting to use all of these coding agents more and more often and then these coding agents are powerful in

[05:42] generating like thousands of lines of code, we’re thinking about okay like what about daily software? Like let’s say the databases that we use, the storage systems that we build, or even like the inference that the post running stack that people are particularly optimizing for their own requirements and workloads. How can AI automate that and optimizing that entire stack according to my requirements? And how can we trust like whatever AI is generated, like you can always see like those agents are generating a bunch of tasks and say like okay, agents passed like 3 100 out of 300 tasks, but is it really that trustworthy? So when AI are

[06:14] like expanding, you can use like multi agents and everything to scale up the amount of code that you generate, um how do you actually like make sure that it’s actually performance and actually work as you expect it. Yeah. So that’s why we shifted from a little bit. So when we started Sky Discover, we started about like optimizing like algorithms, optimizing let’s say scheduling algorithms, like congestion control, etc. Some of the systems problems that we have and moving more towards uh like end-to-end software stack and look at like what are the challenges out there. Yeah.

[06:46] >> Yeah, I mean one one one comment to add there is like in fact in our in our work we one focus that we had seen is this thing called just-in-time system. So imagine that you you now are basically capable of building whatever you used to use from some open source uh repo, but of course the open source repo comes with something we call generality tax, which is basically that you are you are using something that has been built for hundreds of use cases, but maybe you know your use case well. You know your work workload well. In fact like very very like in couple of days we might be

[07:17] able to show you something more where we are thinking that the inference engines that that we build for on-device things, in fact Mert is leading one of them where we are seeing that if you make your inference engine for a very specific Mac metal uh machine and for a model and a workload, you can do a lot of optimizations that you would not be able to do because you are you were doing things for a general setup. And that that gives you that unlocking power, but because you’re using agents now, it’s very, very brittle. There are like hundreds of hacks agents do and there are a lot of things that agents will

[07:47] just find ways to break things and exploit the gaps that we see on the requirement side and on the model side, which is like the world where the final thing is going to deploy. So, given those gaps, the SkySynth project is some sort of a uh our angle to tackle that where we are trying to make sure that the agents do the right work and don’t try to exploit the gap which are already there in any software system. >> Yeah, so I guess if I can maybe start

[08:19] applying this sort of some really interesting ideas in this but if I can start applying maybe from a sort of selfish angle sort of from the perspective of Weaviate and our vector databases, we make a lot of this argument of, you know, we have a specialized vector database. It’s a data database that’s customized to, you know, vector search and vector storage from, you know, how you implement like a custom LSM to the custom indexes. And so I guess and and um you know, we had a podcast with Andy Pavlov from Carnegie Mellon who’s well-known database professor who had who was explaining this division of self-driving

[08:49] databases. And I always imagine it sort of is like hyper parameters, you know, say like with the HNSW vector index, you have like the EF parameter max, you know, like these little index tuning parameters and or you could have like how often the LSM is going to compact or, you know, how your replication is configured. So, I guess I’m just curious about if we can maybe start on the database example. I know the paper describes like a customized key-value store and maybe just I’d love to understand how SkySynth could create a database for a specialized workload and

[09:21] what you think the future is of tailor-made database systems. >> So, um I think that’s a very good uh question that I have. So, we started working on key-value store uh mainly because like key-value store has many, many diverse different kinds of properties. So, you can think about it as like, okay, like how many requests do you have? And And in this request, like how many are read requests and how many are write requests? And then, uh among these uh requirements of like building a key-value store, like what are What is your amount of resources that is

[09:51] available? Are you building like a single-machine key-value store? Or are you building it in a distributed setup that you need to manage the consistency and stuff? Um so, and also what is your consistency requirements? Like, when you uh actually get back your uh like the the value for your key, like can you tolerate some staleness so that you can uh maybe like have better latency to answer your request. So, there are many different dimensions of properties here. So, this can be separated into, let’s say, uh those requirements. So, let’s say how reliable is the system, how reliable is your key-value store or databases. Like, what if it failed?

[10:22] Like, how long would it take to actually recover? Um so, this is one perspective. And second perspective, as I talked about before, is consistency. Like, what kind of consistency level or requirements do you require uh for your for your setup? And uh also, what is your objective? Like, are you going to optimize for throughput? Or are you going to optimize for latency? And what is your workload scenarios? So, this has like very uh diverse range or diverse dimensions of like uh all of these requirements and things that we can potentially specialize. So, for example, if all of your requests are like hot

[10:53] keys, then you can design your read cache in the way that it’s like caching all of the hot keys in memory so that you don’t need to uh actually fetch it from, let’s say, uh from disk or something like that. But if you all of your uh requests are sort of like write requests, then you design something completely different uh comparing to like a a read-heavy request. So, um we started exploring uh basically taking existing uh traces. Uh so, uh some of the existing traces are like just like basic traces, but tuning tuning it in different ways that it has like different read and write ratio. Um and

[11:25] then also, we have like some production traces we take uh from Tencent and also like all of the other um like Twitter traces as well. And then we see whether if given that you know this workload information and you you know like what is the objective functions they are going to optimize for and can AI actually generate something that is better let’s say comparing to RocksDB or Redis and different stuff. And actually indeed like those agents are coming up with new designs, different sort of caching designs and different sort of workloads and requirements. And also like different

[11:56] sort of let’s say hierarchical memory management you put different sort of like size of the cache in in memory or different size of the things that you put on disk. And then also for consistency management then like how do you make sure that it’s actually correct to maintain let’s say read after write consistency or like strong consistency if you expected that. So we created like I think around like six to eight different kind of traces and then we see if given this information for this particular

[12:26] specialized workloads whether the agents can specialize for that. And actually it’s achieve like up to four times better performance comparing to those like even like a very specialized systems from let’s say like Microsoft. And yeah see good performance there. >> I guess my first question is well I guess this I don’t want to like I really want to kind of talk about like I’m worried this pivots the topic out too much but I guess like would it build on to an existing system? Like do

[12:56] you think it like the specific maybe let me just ask like so I think about like kind of this is being like a DS Pi for systems or you know specifications I think is a paper that came from Berkeley and Jared Davis and this idea of yeah like abstracting how you design a system. So so do you like I guess it almost makes me ask like what is software now like like what happens to the artifact of the system that’s created? >> Yeah we’re we’re we’re really curious about this question too. Like what is

[13:27] the artifact now? Look, if you take our vision to the extreme, you’re getting you’re hitting on something really interesting here. If you take our vision to the extreme, you get to a point where the artifact is kind of a unique function it’s it’s a output as a as a function of the traces that you that you you provide. And the reason that we’ve had our artifacts before, why these things have stood on their own, why you have something like Redis, is because it used to take years and years to build these systems. It takes years to train someone to understand. Takes a team of engineers or a PhD team of PhD students 5 years to go build a system, harden it, get it to

[13:59] the point where you can trust it in production. And then no one is going to go pick and build a brand new system unless you’re Meta or Google and you have this huge scale and, you know, the savings you can get are actually worth the millions of dollars that it costs you to develop your custom system. Otherwise, no it doesn’t make say it’s not saying sense for anyone else to do. I think we’re trying to build a system of saying uh if you could if you could hire a bunch of people to build a custom database just for you for your exact kind of things that you want to store, you could get better performance, but it used to cost you so much and we’re driving that cost way down with coding agents and

[14:29] with the frameworks that we have. And I think as as True very correctly put earlier, the remaining problem is can you trust the system that we’ve built? And and a lot of our research the last 4 months has really been on how do we prove to you that the system that we’ve built is correct, either by tests and extensive test suite that’s evolving or actually by formal specification, formal verification, like a guarantee that this is correct. >> Yes, I think that’s maybe the topic that then dives deeper into the details is um how you think about testing and I’m

[15:00] sorry if like we stay in the database if if you don’t mind if we kind of frame this mostly through databases just cuz that’s like all that I understand, but uh I mean maybe later we could talk about like how this might differ for a task queue versus a database, but but like if we could stay on the database thing and I I I guess maybe let me backtrack and ask how how how do you think about the specification? How it does it How does someone come in and tell you about what kind of workload they have, what kind of database they need? >> Um so I think there are some requirements that are about environments

[15:30] that every user or whatever they’re trying to build something for their environments, they have the environments in mind. So let’s say how many machines do you have and each of the machine configuration like what is the memory size and what is the disk disk size that you can put. So this is definitely like something that user will provide in default. And then if you think about like different domains, actually different domains have different properties that the user might want to specify. So it can go from very high level. So let’s say I just talk about reliability. Like for example, if your database where if your data systems like fail, like how long do you expect it to

[16:01] recover? Um and what is the data loss um that you can tolerate in this case? Like maybe most of the time like people won’t tolerate like data loss for for any sort of like database system you create. And so for example, reliability and second thing is about consistency. Like when users they have their requests like when they read their stuff, like what is the staleness of the data that it’s being read. Like if you can tolerate more uh about staleness, maybe I can give you better performance from the database I create, right? So this is another dimension. And um about the workloads

[16:32] itself, like sometimes people uh when they build their systems, they have their workloads in mind. So let’s say uh particularly let’s say for the key value store in in our cases, maybe you know what is the rough like read write ratio. What is the uh like recency or frequency of a particular key uh in your workloads that you can optimize your systems for, right? So as I talk about like if you have a very read heavy workloads, it would be completely different than optimizing for a very write heavy workloads for a different like consistency level. So uh I think there are some basic characteristics about uh

[17:03] let’s say the workloads that you have, the requirements that you have, and also maybe including that like the objective functions. Like maybe you know that you want to just like minimize the user uh latency SLOs and you have some particular constraint over like I’m not going to violate uh this SLO while while building my system. So, um there are like basic properties that uh let’s say it’s probably domain knowledge or like expert knowledge in a particular domain. So, let’s say databases I just like list out a couple of things. But maybe in storage system it would be something different. And in inference systems it would be completely

[17:33] different, right? So, probably like in that cases like there’s uh consistency is like something in in a different notion and correctness is a different notion as well. So, how we learn from this like what is considered as what I should provide in specification is very domain specific. And probably people have uh built like years of systems that follow this routine, right? So, let’s say when you write a database paper about like building a database engines, maybe you write about this particular property about fault tolerance, about like reliability, about consistency,

[18:03] about performance metrics. So, uh from either the codes or the literature you know sort of like what are the basic properties that you want to post. And if the user doesn’t know uh I should probably talk about Okay, I should specify my consistency level. Then the AI should be able to post the question and say like, “Oh, so what is your requirements? Like, what is your uh what is your constraint here?” Like, it shouldn’t like assume something that the user doesn’t even say. So, I feel like the the gap between like let’s say if you just naively use CockroachDB, it might go ahead and do something that you don’t expect. But then of course like uh

[18:36] if you have a good pipeline and you know like the domain knowledge and what people have been built before, then you know that there are several principles and properties about the domain of this uh artifacts that you should ask and you should clarify before proceeding uh proceed to like build a brand new system. So, uh I think this is the spec that we’re trying to build and we’re trying to build this spec in a way that is like follow domain knowledge. And when we shouldn’t assume something, you should post the question. And uh and just proceed building like a specialized systems from there. And I I I think this

[19:06] spec can be let’s say uh I’m talking about a way that like let’s say I’m just daily user of like CockroachDB and I’m like typing like oh I want to build a database for my workout. And I’m I’m expecting cloud code to ask like oh so what do you want to optimize for? Um what is your consistency requirements? What is your uh what is your reliability requirements, etc. Um but of course like Shriram can talk more about how do you actually like if you are domain expert already and you know what you want to write, you probably can write like a formal spec and then let’s say that they uh the coding agents according to the formal spec can generate some sort of verification where like uh formal proof

[19:38] so that it proves that it completely satisfied by the spec, yeah. >> Yeah, completely agree with this. I think I think one more point to highlight here is that we again given that we were using this tool to generate systems, we kind of understood some pain points about that okay writing spec is very difficult. Like you can’t expect a user to come and tell the entire routine or entire laundry laundry list of everything that they might expect from a system. So in the pipeline again if if if you go for cloud code, it might and if you prompt it well, it might actually

[20:09] ask you questions or it might show that it can ask questions. it might like show off that capability. But one thing that we realized were was that when a engineer actually builds a system, so when the code development happen, then there are a lot of gaps that start surfacing. And when those gaps start surfacing, cloud always takes the cheaper way. For example, if you ask it to optimize for performance, it will take that assumption where performance optimization was easy to do and it will not care if it is hacking. Very simple example, we started using some YCSB

[20:40] traces and things like that. And again, if you don’t know about the trace, that trace is more or less deterministic. Where given the key, you can actually predict or not even predict, you can map the value from the key. The initial systems that we built, it was like 30 times throughput, 40 times throughput. And of course without seeing anything, we were like okay I think we have we have built something. But as we get got into the details, it was very clear that cloud was basically hacking it and it was a very obvious you You it’s like an axiom that in a system I’m not going to give you keys where the values can be determined. It’s all about storing those

[21:11] values. And then our insight there was that when the code development happens, then only there are more and more holes that are going to be exposed. And our synthesis system, which is like SkySynch, is able to surface the right level of abstraction that the user should be able to answer. In So, we again, we do two types of generation. One is a generation where you are actually starting with requirements as she was uh mentioning. Where the system you designer knows the requirements that they want at some level. But they might

[21:41] not be the people who can actually do things in a formal way. By formal way, what you can imagine if if I ask you to write a sorting function. Of course, you will be having some properties that okay, my negative number should be on the left-hand side, my positive number should be on the right-hand side. If there are duplicates and this is this is how I’m going to handle. So, you can give some high-level specifications to what you want. But if you’re doing things in a very critical domain. For example, in databases, of course, you know uh read your write or there are like properties that you care about. Those properties, there are sometimes

[22:13] they those properties are actually sometimes very hard to define in natural language. Because it is not clear because you’re talking about like concurrency, distribution. And it’s not easy unless you start defining things in a slightly mathematical format. That we call formal language. Like that is what Lean and Rock used to do. So, in our pipeline, the thing is that when a user comes with a system design or comes with something which they want to build. The the agentic system is going to probe the user with the right level of questions. And take the route of either the formal

[22:43] way or the test-driven way. And in that then again, our loop is basically designed to keep on finding out what the gaps the user missed. And as and when those assumptions need the user, the user will be probed. Otherwise, right level of assumptions will be made so that the system can be built more robustly. So, the optimization pressure is something that leads to reward hacking and Sky is in this somewhat a vaccine that basically prevents the system from doing a lot of reward hacking. >> Yeah, it kind of reminds me of like quad

[23:16] code. Like, you know, it writes some tests. It’s like, I passed the test that I also just wrote and and that kind of thing. And then, I mean, it’s just amazing thinking about like it still sounds like you have the sort of like classic deep learning machine learning like training data testing data. But now, the artifact instead of a trained model is code, a system. And then, the data is also like more persistent, I think, than you you Well, in the sort of search and information retrieval sense, you kind of have like this persistence of like the corpus. And that maybe comes into this

[23:47] territory bit, but um Yeah, I guess like kind of maybe talking about testing and you mentioned like formal proof. I guess it just makes me think like, you know, if I say, “I need you to sort these numbers.” And okay, so, you know, it’s going to either maybe bubble sort it or it’s going to quick sort it. It’s like, how do you then like how how do I know the difference between if the system has done either bubble sort or quick sort? >> Yeah, so, these type of things ideally, um so, you should specify when you first ask

[24:18] like Sky to synthesize to synthesize these things. But, our system first on tries to understand what you implied in your task specification. So, if you asked it to come up with a sorting algorithm, probably it would first ask you back, uh okay, um do you have like any preferences on the time complexity of this? Um then, if you say nothing, okay, just give me a quick one, it will do some

[24:50] literature review and try to see what other code bases exist in that domain. Then, it would try to implement what it thinks is the best given your specifications you provided. >> So basically like the test should be tight with whatever you specify in your properties, right? So for example like let’s say if you don’t formally prove your let’s say consistency or whatever other fault tolerance level, you probably want to stress test a little

[25:20] bit about how like how how fault tolerant is the system, right? You can like send a bunch of requests like many many concurrent requests as well and see whether it can it would just fail and see after when it fails like how long does it take to recover as well. So I think people have this like test-driven development things in production system as well like because they cannot formally specify each part or each component of their end-to-end system. And this stress testing is tight with particular properties that you desire and you typically want to see like okay how long

[25:51] does it take to recover, whether it does like garbage collection and do when when workload shifted it’s like completely like breaking down or something like that. So I think yeah so so so test is like basically tight with whatever you specify and whatever the users want in in their specification. Yeah. >> Yeah. And and in general again you you put that point very correct that this cloud will basically tell you that I generated 100 tests and and 100 tests are passing because writing good quality tests that are actually capturing those specifications is the key. And in the

[26:21] pipeline again the idea is that every test that is added is actually enforcing that spec. So again there are some details here that the test will have to prove that it is actually testing the particular specification by generating say a reference implementation which is correct on that aspect and incorrect on that aspect. And if it is actually able to differentiate this that that then only that test is actually like a gate that can allow a system to pass or not pass. So it’s more more like a rigorous way to do things because the domain actually requires you to take care about

[26:52] those specifications. >> Yeah, I mean I guess like on on I’m really interested in it just inspires me to think about like Python versus like Go and just how you think about the abstraction of what the system is working with cuz if it’s say something like Go or maybe I know Rust is maybe more popular but I would use Go maybe it’s not that’s what I mean by like slightly lower language but I’m like and it’s looking at something like heap allocation and just I guess that is quite different like when you’re

[27:23] I don’t know if you want to call this vibe coding or like what we call sort of LLM coding but like what language it’s using on top of that really I think influences just like how it works with these specifications. Some I guess I’m just curious how you think about maybe even just like programming languages with this. >> Yeah, I mean again good question. So that one one thing to take care of this when when you’re building a system is of course you you you can either have preferences that is one thing but if you

[27:54] don’t have a preference then the goal of the system is that it is optimizing for a particular workload. So you really care about performance in that part. And when you are caring about performance when it starts getting into like the blind spots there there would be some languages that might be easy to build in terms of closing those blind spots. For example, if you are caring about something where memory safety is actually a thing the system will steer the agent to use that memory safe language like like Rust because the

[28:25] system is going to be built more carefully and it will be it will have a hard time compiling and hence whatever is built is going to be memory safe. But maybe the performance will get compromised. So in fact the language is also something that is very attached to the performance that you need the specifications that you care about and to make those specifications abide by you are basically writing tests. So so the whole thing is that me for example, if you do kernel engineering like a very simple example, it is very easy to write a correct kernel when you start with the

[28:55] high-level say PyTorch or Pythonish language, but then you all you care about is performance. Now, if you are dealing with a TPU versus say X version GPU, you want to go into that stack where it allows you to write the things where you can say fuse the kernels very effectively or if it’s like a quantized kernel, you are caring about how the precision errors can be minimized. So, it’s it’s really really an implementation detail the user should not be caring about it unless they have a preference and that’s how our system currently actually helps the user that unless and until this is an assumption

[29:26] that is leading to a path where the specification needs to be changed here or there, the user will not be even exposed with that. He will be given that implementation that is ideally most performant and least reward hacking. By least reward hacking, if it’s the test route, it’s more about where the tests can be done very very properly. As I said, Rust will be more more favorable if it’s like a memory safe thing, but if there are things where you don’t care about it and you can get better performance not caring about your compile time memory safety

[29:56] requirements, you will go in a say a C route or something. And on the other side in the formal space, they again there are like Lean and Rock which acts in the model world where you are trying to prove things. In the downstream again, you either try doing some old-style OCaml kind of languages, but in the latest world again, you have CompCert kind of compilers which is in the C world. Plus Verus kind of things which is in the Rust world. So again, these are like very very intricately attached to what you really care about because you can write everything in every language. What

[30:27] you choose will basically decide how easy it was to test it and how performant it was at the end. So, it’s really depending on your objective that you care about. >> Yeah, you make me want to brush up on my understanding of compilers. It’s been to be since I did >> [laughter] >> all of that um and I guess like yeah so I guess my question is like you know from the specifications you could just go all the way into maybe generating like a binary I guess like in a super crazy way. Like you like do you think that’s ever

[30:58] or does it always have to be some intermediate code artifact? >> I mean again very very very good good question. So that the whole thing here is that if you are if you if you give me a specification and you care all about performance again at the end of the day you really really want a binary that was not built off any compiler that was making any assumptions to speed up your implementation in a general way. So you really want your agent to actually write you like assembly code if not if not binary that

[31:28] is like very very performant for your system and again if it knows your workload it might be doing some pre-fetching some things that can’t be done on the higher level languages. You want to go there but obviously like there is a cost aspect attached there also because you would require the LLM to iterate more and more and more to get to that level. So it’s it’s somewhere where you basically close your boundary saying that okay I’m fine running this experiment or running this system building task for X hours and I spend N number of dollars on this. In that time you really want to want your system to

[31:59] be there. But again once you have a version LLMs can be made to work without eating and sleeping. So in an ideal world you can just make them optimize the thing more and in the optimization again when the language becomes a barrier that okay now to optimize further I just need to go to a lower level language it’s again like kernel engineering once the once the idea of how to write flash attention gets invented you really need to go into the lower level level language to actually do the memory fetching because Python or PyTorch won’t allow allow you to do that. But yeah I

[32:30] mean I hope I I answered you the question but that’s the point. >> Yeah I mean I hope I’m keeping the conversation but yeah, it just makes me think about like right now I think you I mean, you’d have to be pretty cracked, as they say, to like have be managing a repo in like multiple like language abstractions. I think that’s kind of what where this is taking me. Like if I had a Python project that also has like a like a parts I mean, yeah, you you have like connection Sorry, it’s been a while since I’ve done projects like this where

[33:02] you would like connect like C into Go. So, it’s just been a while since I’ve really thought about that kind of thing. But, uh Yeah, cool. And And I guess I’m still just kind of thinking about like you know, like building on top of say Postgres or you know, Weaviate’s open source like just how you think about extending open source say databases and just what role that has to play in this research.

[33:32] >> Um so, maybe like I think we’re still actively thinking about like in what cases does it make sense to synthesize something completely from scratch versus like optimizing some existing systems. So, of course, like synthesizing something completely from scratch can take probably a lot of time. So, there are maybe like for very mature production ready systems, maybe they’re like they have their built for like general workloads, they have like many many test building in their original like the the systems that is open source

[34:04] or closed source. And then so, it takes less time to build those components, but probably synthesizing from scratch can allow you to jump out of the local optimum that is being heavily constrained by whatever structure that the general systems has. So, let’s say if I were to build on my general system, maybe I first need to understand like 40K lines of codes for the general system to be able to see like oh, maybe tuning this parameter will work for this kind of specialized workloads. Maybe tuning a combination of these two configurations will work for my particular requirements. So, of

[34:35] course, like it takes time for understanding the code bases and probably the structure or the abstraction that the general systems has might not be the best for your specialized use cases. And it’s unclear that like whether one case optimizing it is actually can achieve better performance comparing to synthesizing something completely from scratch. And we actually try like in our key value store use cases of like building on top of like marker Microsoft faster and see whether it can like do it well. But then comparing to our synthesizing from scratch from

[35:05] scratch experiments is actually achieve less throughput comparing to just like building something completely from scratch. And in in of course like a time constraint like sometimes coding agents can get stuck in the local optimum and thinking about oh this abstraction is everything that I have. So, I’m just going to tune partial or partial like components of the system. But versus like when it thinks something completely fresh maybe it can come up with a better design from like thinking about backing up in a high level like how should I design my memory? How should I

[35:36] coordinate between memory and disk? And how should I handle all of the requirements that the user have? So, ideally I think the system that we trying to build is like knowing when to synthesize, knowing what to optimize. But then at the same time like ensuring that everything either you do optimization or synthesize from scratch, you want to make sure that you don’t break some of the guarantees that the systems should have what the user specify in their specification. So, correctness still matters when even if you’re just like optimizing for a particular system. So, let’s say if you change the cache the caching algorithm

[36:08] or the caching components of Redis and then actually something break whenever you you input a new work code then it’s not correct. So, I think in both cases we should think about like okay, so what are the set of right right set of tasks and what are the right set of guarantees that we should provide to the user so that the user would trust the ultimate artifact that are being generated by the by the agents. And second thing is of course performance. Like in given like a limited let’s say time budgets and also cost constraints, is it better that I start from let’s say existing well-known

[36:38] system? If so, start from what system? Because like many different There are many sort of like open source like databases out there and which one should I get started with? And versus like completely synthesizing from scratch. I think those questions as models become more powerful, hopefully like the model will know like what kind of high-level spec that the each systems will provide and what whether each system will have like specialized [clears throat] strength in terms of optimizing for a particular workload so

[37:09] that it can dynamically choose between okay, like I am going to optimize the system and I’m going to choose this system to get started with because it has this kind of properties that it’s easy for me to to optimize. Or I’m just going to completely start something from scratch where I see let’s say some features are completely not supported in any of the existing open source databases. So, I might as well just build my own design. I have a whiteboard, maybe I can draw like my key design idea to optimize for this workloads and I’m just going to synthesize something completely from scratch. So, hopefully this will be more

[37:39] automated and I think yeah, so we’re trying to build something that can achieve this, but the goal here is having both correct and also being very specialized in performance. Yeah. >> If I can I want to call out here just like how surprising this this like take is. I think it was like surprising for us when we got to it too, but I think for the current stage just of where the field is at, if you’re working in AI, you shouldn’t be like designing or building or thinking of what you’re doing as for today. You should be thinking if you look and follow the

[38:09] trends of where they’re headed, you have to skate to where the puck is going, not where it is. And so this is it’s this really weird thing, right? Where it’s like it’s counterintuitive to think that you should start from scratch to build your system if there’s an existing system out there. But if you assume as the model is getting better and better at building and reasoning and designing, um it’s so easy for it to even get to any particular design. You should just let it start from scratch and be fully unconstrained, and that actually takes you to the best outcome. We used to start from existing systems and it would shortcut. We would save a lot of work, but if that work is actually easy for a really smart model,

[38:41] there’s no need to constrain it or from starting from that point. >> Yeah, I think it’s amazing, especially like from the sort of research what’s possible angle, but I’m I’m also curious about so like, you know, when we have these systems like when we have Weaviate Cloud, we I guess there’s like there’s like a few levels to it. It’s like we sort of have like the knowledge of how to host it, like how to like how to run it in like how to run it at scale, and then like how to debug it. And I and I think those kind of arguments I could see

[39:11] these systems certainly like having a huge impact on that, if not completely being able to do that. But then I’m there’s something to I think like the concept of like uh like managed infrastructure, where it’s like you have like a provider like like Redis as we’ve been mentioning. Like they have like Redis Cloud, and so there’s probably still something to like these systems that like that still like have a managed infrastructure somewhere else, but can you still tailor those? Does this research have some intersection with that kind of thinking? >> I I think I totally I I I think that um

[39:44] yeah, look, there’s independent like like like there’s business reasons you might want to have someone else host something for you. You just want to don’t have the kind of people on call managing it. There’s kind of like technical reasons, like maybe you don’t have the the team to go and build out or check or even write your specification correctly, so you’re going to pay someone you know that Redis has the right specification for the system that you’ve built and you’re not a technical team or something. Um I still think that the ideas that we’re working on are eventually going to slot into even those systems, because you could imagine a hosted version of something like a Sky Synthesizer

[40:15] Sky Synthesizer Optimizer or Synthesizer that given a streaming set of queries great. There’s still an interface of puts and gets, but given the last 24 hours of puts and gets, I should have a re-synthesized system that’s going to do really well on that distribution of of uh, of traffic. So, I actually think this will this will fold really well into that that model. Um, >> Yeah, it’s so cool cuz you yeah, you might have like these machines with like cuz you have like a shared set of like machines with their RAM and disk and then it’s like perfectly allocating what fits into it. With this new one, yeah,

[40:47] wow. That’s so cool. >> Yeah. >> Yeah, amazing. Um, yeah, so I guess maybe I’d love to kind of come up the abstraction quite a bit and maybe talking a little more broadly about like systems that everyday people might want to use. Alex and I had a little joke before we were before we started recording where um, I was explaining to Alex that I use Zen caster for recording instead of Riverside and we’re talking is that I think I know of some software that might be able to create me a podcast recording software. Uh, how do you guys think about like this idea of um,

[41:18] generating software for say note taking or email? >> And you I I can try to briefly add this which is just to say that like humans are much messier than machines. So like it’s to write out the like semantics that the like the actual formal specification for a key value store, it’s it’s ugly. Specs are hard to write. Um, we’re trying to make that easier. We’re doing research on that, too. But there’s kind of formal languages to model interaction between machines. Uh, it’s much trickier to kind of formally model how would you even

[41:49] specify what what uh, like a note taking app should do, right? The way that we often do this we you know, there are people that actually do this. We have name we have a name for them and they’re product managers. Product managers are like they’re kind of responsible for for translating between the like conceptual idea of what we want to talking to engineers and trying to explain to them in their language, still in English, but in English that that programmers understand and the programmers going to write it in code. So, um conceptually, so today, if you look at SkySynth uh like up just the Sky Discoverer framework in general, as we

[42:19] think about specification, a lot of what we’re reasoning about is either you give us a formal spec, or you kind of in in human language describe what you want, but we kind of generate tests that in in in code the the human spec. Um the this the the the intent of the human. You could probably get to a world where you could just as well synthesize um uh kind of sets of tests of behaviors with a note-taking app, where like you can take notes, you can go and create a new note, kind of feature descriptions or PRD-style designs. Like that’s what a spec looks like for a product.

[42:51] I think that we as a Sky Discoverer team are really quite focused on the core systems aspect of this, partly because it’s just it’s a really hard problem, but I think that the product synthesis side will be really interesting, and just looking at what the right medium is to capture a spec for a product, which to me is a PRD, um we’re we’re not looking at that in our research, but I do think some of the techniques we’re developing would would be applicable. >> Yes, yes, yeah. As Alex said, um so

[43:22] Sky Discoverer Synthesizer has two main arms, uh either test-driven development or formally specified like doing formal verification on uh formally specified systems. Um yeah, unfortunately, it’s incredibly hard to capture uh what humans actually desire from like these um unverifiable domains, like design me a good web application, a nice UI. Um so, we’ve been also trying to build some UIs for some of the systems we

[43:53] built using Sky Discoverer. Um that part takes some other set of skills, uh definitely. >> Yeah, and I they kind of remind me of what uh Shu was explaining earlier with the like I think like the idea of asking someone like um what recover like what what recovery can you tolerate? Like I you know, I’ve done a lot of talking to start ups and entrepreneurs like product builders who are like this idea of communicating these these ideas.

[44:23] I think there’s like a huge gap there that’s really interesting and just yeah, what specific like when is the specification like a chatbot? No. Yeah. Okay. Yeah, cool. >> Yeah, so at the start of our um framework, uh there’s a spec building part. The spec building part takes in some specifications from the human um about what should be built. Um now it for the case that is test driven development,

[44:53] um the framework essentially checks um if the spec that the human provided is clear and comprehensive enough. In that case, it would start doing some uh profiling on the workload that you specified. Uh it would go and see uh what other specs exist in related code bases that are out there, etc. But there are also many cases uh like you mentioned uh where the input specs are not clear and

[45:25] human input is needed. Uh then yeah, um it acts like a chatbot in the sense that it tries to iteratively disambiguate uh what’s going on with the human. >> Yeah, amazing. Yeah, so um I know we’re kind of coming up on the time and I usually anchor the We Have Podcast with you know, this general like what excites you about AI, but I am I have to ask one more technical question about this. How do you think about optimizing the system? Is it something like say like Geppa for system design? Like or is it

[45:57] like a Yeah. >> I think optimizing system first of all the problem is larger in scope because systems if if if you care about a system generally that system is also very large and even finding out what is the right way to optimize what is the target in it meaning a code base is going to be huge there are like hundreds of things that you can optimize but there are specific things that are worth optimizing. And in optimizing systems there also

[46:28] there’s also one more point unlike say text optimization that the evaluation is not that easy. Like if you really care about say hardware design or if you care about something like even inference engines you optimize something and the loop of getting the full feedback is like running lots of tests like if you care about VLMs there’s like probably 25,000 or more tests and then you actually are going to run all the workloads to check for correctness and then you will run several workloads like different pre-fills different decodes different agentic workloads to get some numbers in

[47:00] terms of say throughput or whatever and again even though in text optimization also there is generally a multi objective space with trade-offs in the case of or in the world of system optimization the trade-off is actually very real because you tune something for memory your throughput will be fully bad or or you are you are tuning something for latency and your throughput is just going away so it’s very hard to and and as always it’s very hard to define these trade-offs it’s not like the human knows what is the right perfect point to have so in optimizing of systems which is

[47:31] obviously like one of the arms that system optimization had been a thing all the laws had been there for how you find the right problems to solve and how you optimize them in the Sky Discover pipeline making it agentic and the next version which we are of hopefully planning to have is where the agents can themselves scout for right problems the agents can themselves build the small simulators you can imagine or some sort of like proxy evaluators which can give it the capability to hill climb. So, once it is able to hill climb, then it

[48:02] becomes a hill climbing problem which is equally same as like Jepa for text optimization or any other technique which could be doing evolution over the text. But, the problem becomes identifying the problem and getting the feedback in a way that the LLM can do. If I If I like give you a number in our KV generation, like the key value generation or optimization, probably 80 to 90% of the time is pending evaluations. Hardly 10% is actually like text manipulation. So, the bottleneck becomes that and if you want to scale your agents now, if you want to like run

[48:33] hundreds of agents doing this, you your objective actually becomes like a meta problem which is first get me the right kernel that is supposed to be optimized and get me a right proxy to actually measure just that kernel which is like very fine-grained details or fine-grained profiling that is going to help me in identifying how to evaluate and how to find out the bottlenecks which are the key to getting better performance. So, that’s how we kind of see that it’s like a meta problem and which doesn’t really exist in the text space because in text space it’s more

[49:04] Again, it’s not a simpler problem. I’m not not trying to infer that, but it’s more defined in that world and the bottlenecks are different. >> So, [clears throat] also circling back to uh what Alex said at the beginning of the uh podcast actually about So, given some evaluation evaluators, um you could imagine trying to optimize some prompt of a system or a function that is doing a a specific job. Um as um like select part of the system.

[49:36] But, now if you start from the specs, it’s not even question It’s It’s not even clear what the tests should be. It’s not even clear um which parts of the code base should you be optimizing. Um it’s moreover um it’s not even clear if the specs are complete. Um did you the user specified maybe some workloads, but as you said, hopefully the design system should be robust. It should be it should

[50:09] generalize to perturbations around what the user asked for. So, can you come up with some other adversarial workloads to test the system? And moreover, what if the specs change over time? Um can you adapt to that sort of outer loop and like get human feedback to iterate on your tests even more these sort of workloads over which you optimize more. So, yeah, it gets a little broader than the

[50:40] >> [clears throat] >> sort of classical evolutionary systems with which we use to optimize functions, etc. >> Yeah, I guess if I can just give my quick take on it, I think of it as like Geppa has this Pareto frontier of candidate program like you know prompts usually it’s used for text optimization, but like it could be candidate programs like it could be code for the database designs. And then the Pareto frontier I guess instead of being like training examples

[51:11] and again like the text sense like you know a particular prompt for writing a blog post and like for like you know this one prompt wrote a better blog post about mitosis than this other did about you know another topic in biology. And like that’s how you think about it in that world, but in this world I can imagine that the tests like kind of define the Pareto frontier. But then I think what I’m learn what I’m what I agree a lot with this idea is that the evolutionary optimization should also be coming up with tests. Like it should be able to propose new tests and like evolve that concept as well and

[51:42] evolutionary optimization is definitely a very cool topic. It’s fun thing to think about. >> Amazing. Well, Alex, Mark, Shue, Shobha, it’s just been such a fun conversation. I’ve learned so much and so cool to meet you all. Thank you so much for joining the We View podcast. >> Thank you so much. It’s a very >> Thank you. >> Yes. Thank you. >> It was very fun to talk to you. >> [music]

[52:22] [music]