Além do RAG: um mecanismo de contexto relacional que reduz o consumo de tokens — Unblocked

Autoria: AI Engineer · Assistir no YouTube

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

Idioma original: inglês

Vídeo original: Beyond RAG: A Relational Context Engine That Cuts Token Burn — Unblocked · Canal: AI Engineer · 19:16 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Dados, bancos de dados e embeddings, Open source e ecossistemas de software, RAG, busca e recuperação de informação

Resumo

Peter, da Unblocked, apresenta um context engine que reúne conhecimento institucional disperso e fornece contexto relevante, inter-relacionado, personalizado e atento às permissões. Ele compara o uso de Claude com e sem esse contexto e mostra exemplos de redução de custo e apoio a revisões de código. Em seguida, demonstra como criar um mecanismo de consultas estruturadas em linguagem natural, incluindo descoberta de schema, resolução de identidades, validação, autocorreção e busca textual completa. Por fim, apresenta um agente de chat com acesso a esse contexto e um simulador open source para testar localmente o efeito de fornecer contexto aos agentes.

Pontos-chave

Um context engine reúne código, documentação, PRs, conversas e histórico institucional para gerar contexto fundamentado e específico para cada tarefa.
No exemplo apresentado, o uso do context engine reduziu em cerca de 50% o custo e o tempo em comparação com a execução sem ele.
RAG atende à recuperação semântica de conteúdo, mas não resolve sozinho consultas estruturadas, temporais ou agregações.
Consultas em linguagem natural precisam de um mecanismo que descubra o schema, resolva identidades e gere consultas estruturadas.
A descoberta dinâmica de schema e o mapeamento de identidades podem ser feitos, em boa parte, com métodos procedurais determinísticos.
Consultas geradas por LLM devem ser tratadas como não confiáveis e validadas para bloquear operações perigosas e proteger limites entre tenants.
Erros de validação ou execução podem ser devolvidos ao LLM em um loop com limite de tentativas para que ele corrija a consulta.
O mecanismo demonstrado combina filtros, agregações, recortes temporais, autocorreção e busca textual completa.
A Unblocked também oferece um simulador open source que cria context bundles e compara, em um teste A/B, tarefas executadas com e sem esse contexto.

Capítulos

Início	Capítulo	Resumo
00:01	O que é um context engine	Peter explica como um context engine transforma conhecimento institucional disperso em contexto fundamentado e mostra exemplos de seu uso com Claude e em revisões de código.
05:58	Da recuperação semântica às consultas estruturadas	A apresentação diferencia as perguntas atendidas por RAG das consultas estruturadas e introduz os desafios de gerar consultas seguras a partir de linguagem natural.
11:21	Construção do mecanismo de consultas	A demonstração percorre a descoberta de schema, a resolução de identidades, a síntese e validação de consultas, a autocorreção e a busca textual completa.
17:03	Agente de chat e simulador local	Peter mostra o mecanismo em uso por um agente de chat e apresenta um simulador open source para testar localmente os benefícios de fornecer contexto.

Citações

O contexto que entra no context engine é disperso; do outro lado, você obtém contexto fundamentado. — 01:35

O que você vê, essencialmente, é uma redução de 50% no custo. — 03:50

Gerar as consultas é, na verdade, a parte fácil. O difícil é a estrutura de suporte ao redor delas. — 08:08

Construímos algo que consegue lidar com a outra metade do RAG. — 17:03

Conceitos e entidades

Unblocked (empresa): Empresa apresentada por Peter, que desenvolve um context engine e produtos para revisão de código.
context engine (conceito): Sistema que reúne conhecimento institucional disperso e o transforma em contexto inter-relacionado, relevante para a tarefa, personalizado e atento às permissões.
Claude (modelo): Assistente usado na demonstração para planejar uma otimização de código com e sem contexto adicional.
RAG (conceito): Abordagem de recuperação que, segundo a apresentação, lida com conteúdo semântico, mas não basta para consultas estruturadas.
document query engine (repo): Projeto open source usado na demonstração para construir um mecanismo que converte perguntas em linguagem natural em consultas estruturadas.
automatic schema discovery (conceito): Técnica que amostra documentos de um repositório de dados para derivar dinamicamente um schema.
identity resolution (conceito): Processo de relacionar identidades de usuários entre sistemas diferentes, usando correspondência aproximada e, se necessário, um LLM como desempate.
context engine simulator (ferramenta): Projeto open source que permite criar context bundles localmente e comparar tarefas com e sem esse contexto por meio de um teste A/B.
Peter (pessoa): Apresentador da Unblocked que explica o context engine e conduz a demonstração de construção do mecanismo de consultas.

Tradução completa (pt-BR)

00:01 [música] Estamos no ar? Certo. Conseguem me ouvir? Assim está ótimo, pessoal. Bom. Certo. Então, vamos fazer uma espécie de speedrun aqui, porque só temos 20 minutos. Sou Peter, da Unblocked. Na Unblocked, criamos um mecanismo de contexto. Então, vou

00:32 mostrar algumas coisas para vocês. A palestra vai ser dividida em duas partes. Vou explicar o que é um mecanismo de contexto e como ele pode agregar valor à sua organização. Depois, vamos construir um componente de um mecanismo de contexto. Também vou mostrar alguns projetos open source que vocês poderão explorar depois. Essa é a agenda: o que é um mecanismo de contexto? Como ele gera valor? E depois vamos construir. Então, vamos voltar no tempo

01:04 talvez alguns anos, para a época anterior aos AI agents. Naquela época, vocês eram a camada de contexto. Imaginem que são novos funcionários de uma organização e estão tentando entender o que está acontecendo. Normalmente, acabam tendo que analisar um monte de código e vasculhar sistemas de documentação, só para encontrar as informações necessárias para fazer o trabalho. Sem falar em todo o histórico compartilhado que foi se acumulando ao longo do tempo, conforme a organização lidava com incidentes e com as cicatrizes de batalha que vêm com eles. Então, o que um mecanismo de contexto faz é reunir todo esse conhecimento institucional. Ele recebe o contexto disperso e, do outro lado, entrega um contexto fundamentado, ou seja, um contexto em que tudo está inter-relacionado. Ele é específico à intenção, personalizado e leva as permissões em conta.

01:35 Então, vou mostrar exatamente o que quero dizer com isso. Agora, imaginem que vou abrir o Claude aqui e mostrar algumas sessões interessantes que tive. Perguntei ao Claude — sem um mecanismo de contexto conectado — se poderia criar um plano para otimizar um componente da nossa camada chamado source mark engine. Tenho certeza de que todos conhecem o que o Claude faz ao começar uma tarefa: é como um funcionário novo. Ele

02:12 não entende nada sobre a base de código nem sobre a organização. Então, a primeira coisa que faz é vasculhar a base de código e tentar descobrir o que está acontecendo. Dá para ver isso aqui. E, sabe, acaba entendendo — ou pelo menos demonstra com confiança que entendeu. Então, me dá uma recomendação. Mas agora vou mostrar como fica quando conectamos um mecanismo de contexto ao backend. Nesse caso, ele chama o mecanismo de contexto da Unblocked, e a Unblocked fornece um pacote de contexto muito abrangente, mas específico para essa tarefa. Dá para ver que ele está consultando não só o código-fonte, mas também documentos do Notion sobre a arquitetura, pull requests e conversas no Slack sobre a otimização desse componente. O resultado final é um pacote de contexto bem conciso, com todos esses links. Assim, se o Claude quiser buscar mais informações, tem ótimos pontos de partida. Mas o realmente interessante é isto: aqui, gastei US$ 1,29, e levou cerca de um minuto e 30 segundos. Isso foi com o mecanismo de contexto; sem ele, o gasto chega a US$ 2,60 e leva 3 minutos. Então, o que vemos, essencialmente, é uma redução de 50% no custo, o que é impressionante.

02:45 Agora quero mostrar outra demonstração interessante: uma sessão que meu colega teve com a Unblocked outro dia. Opa, desculpem, vou tirar isto daqui. É uma sessão interessante que meu colega teve com a Unblocked outro dia. Também temos um produto de revisão de código, no qual Richie trabalha, e ele percebeu que o número de problemas apontados pelo produto de revisão de código estava começando a cair. Então, ele perguntou à Unblocked, que conseguiu reunir essas informações

03:17 e chegar rapidamente a uma causa provável: mudamos de Opus 48 ou Opus 46 para Opus 48, e as características de comportamento nos bastidores fizeram com que o número desses problemas diminuísse. Então, ele pediu à Unblocked para simplesmente corrigir isso, e a Unblocked conseguiu criar um PR nos bastidores. Ela tem todo o contexto e sabe o que fazer. Mas a parte realmente legal é que dá para

03:50 ver que ela criou esta descrição, e é simplesmente impressionante: ela entendeu qual PR causou a regressão inicialmente e encontrou uma conversa no Slack em que o assunto estava sendo discutido. Também reuniu alguns desses dados para embasar a correção, o que é incrível. Então, vou voltar para… Acho que perdi minha apresentação do Keynote. Vamos

04:21 ver. Aí está. Os agents têm o mesmo problema, certo? Custo. Ah, desculpem. Este é o Keynote errado. [risos] É o Keynote errado. Aí está. Acho que agora vamos direto para a parte de construção, porque estamos com pouco tempo hoje. Então, vou resumir. Vocês têm

04:55 contexto espalhado por toda parte: em PRs, revisões, comentários, issues e tickets, documentos e conversas. Tudo isso pode ser consultado semanticamente, mas também é estruturado, e o RAG resolve a parte do conteúdo. Ele consegue lidar com perguntas sobre conteúdo: encontrar o código, o PR que o alterou, a conversa no Slack em que isso está sendo debatido. E, se vocês colocarem isso em um loop de agent, podem ir bem longe. Deem a um loop de agent ferramentas para fazer buscas em arquivos e ele se torna muito poderoso, mas não lida com alguns outros tipos de perguntas estruturais, como: quais PRs eu mesclei na semana passada? Quem revisou mais alterações em pagamentos? Quais são os PRs abertos mais antigos? E assim por diante. Essas são consultas, não buscas semânticas. Então, quero mostrar de novo o exemplo do Richie: ele começou a conversa com a Unblocked fazendo uma pergunta que exige uma consulta, porque envolve um elemento temporal: “Você pode me mostrar um gráfico da proporção por semana desde 1º de janeiro?”

05:27 Certo. Para fazer isso, não dá para simplesmente buscar essas informações em um vector store, porque elas não estão codificadas ali. Então, é preciso fazer isso por meio de algum tipo de mecanismo de consulta. Essencialmente, a recuperação tem duas partes. Temos a recuperação semântica, que lida com esse tipo de pergunta semântica. Mas hoje vamos trabalhar na parte estruturada. Vamos transformar consultas em linguagem natural em consultas estruturadas. Gerar as consultas é, na verdade, a parte fácil. A parte difícil é a estrutura de suporte em torno delas. É preciso, por exemplo, entender o esquema para passá-lo ao LLM, que então gera uma consulta bem delimitada. Também é preciso conseguir mapear identidades. Se eu perguntar sobre PRs abertos de Rashene, o sistema não vai saber quem é Rashene, porque a identidade dele no GitHub pode ser completamente diferente. Então, precisamos conseguir fazer esse mapeamento de alguma forma. Quando a consulta sai do LLM, ela não é confiável. Pode conter operações perigosas ou ultrapassar limites entre tenants. Então, precisamos de alguma forma de validar se a consulta está correta e é segura. E, por fim, mesmo depois dessa validação, podem ocorrer erros.

05:58 Hoje, vamos trabalhar nessa parte estruturada. Vamos transformar consultas em linguagem natural em consultas estruturadas. Gerar as consultas é, na verdade, a parte fácil. A parte difícil é a estrutura de suporte em torno delas. É preciso, por exemplo, entender o esquema para passá-lo ao LLM, que então gera uma consulta bem delimitada. Também é preciso conseguir mapear identidades. Se eu perguntar sobre PRs abertos de Rashene,

06:28 o sistema não vai saber quem é Rashene, porque a identidade dele no GitHub pode ser completamente diferente. Então, precisamos conseguir fazer esse mapeamento de alguma forma. Quando a consulta sai do LLM, ela não é confiável. Pode conter operações perigosas ou ultrapassar limites entre tenants. Então, precisamos de alguma forma de validar se a consulta está correta e é segura. E, por fim, mesmo depois dessa validação, podem ocorrer erros.

07:01 bem longe. Você dá ferramentas a um agent loop para fazer buscas em arquivos depois disso, e ele é muito poderoso, mas não lida com alguns outros tipos de perguntas estruturais, como PRs que eu mesclei na semana passada, quem mais revisou pagamentos, os PRs abertos etc. E essas são consultas. Não são buscas semânticas. Então, quero mostrar de novo, voltando ao exemplo de Richie, com o qual ele começou a conversa no Unblocked

07:33 fazendo uma pergunta baseada em consulta, porque há um elemento temporal. Você pode me mostrar um gráfico da proporção semanal desde 1º de janeiro? Certo. Para fazer isso, não será possível simplesmente obter essas informações de um banco de dados vetorial, porque não é lá que essas informações estão codificadas. Então, será preciso fazer isso por meio de algum tipo de mecanismo de consulta. E, essencialmente, a recuperação tem duas partes. Temos a recuperação semântica, que consegue lidar com esses tipos de perguntas baseadas em semântica. Mas

08:08 hoje, vamos trabalhar na parte estruturada. Vamos transformar consultas estruturadas, ou consultas em linguagem natural, em consultas estruturadas. Mas gerar as consultas é, na verdade, a parte fácil. A parte difícil é a estrutura de suporte que fica em torno delas. Então, você precisa fazer coisas como entender o esquema para poder passá-lo ao LLM, para que ele gere uma consulta bem delimitada. Também é preciso conseguir mapear identidades. Se eu fizer uma pergunta como

08:38 PRs abertos de Rashene, ele não vai saber quem é Rashene, porque a identidade dele no GitHub pode ser completamente diferente. Então, precisamos conseguir fazer esse mapeamento de alguma forma. E, quando você obtém a consulta do LLM, ela não é confiável. Ela pode conter operações perigosas. Pode atravessar limites entre tenants. Então, é preciso ter alguma forma de validar se a consulta está correta e é segura. E, por fim, mesmo que você faça essa validação, ainda pode haver erros.

09:11 E, quando você realmente faz a consulta ao banco de dados, também podem ocorrer erros. Então, podemos fazer o LLM tentar se corrigir caso isso aconteça. É isso que queremos alcançar aqui. Queremos chegar a isso. Queremos poder dizer algo como “PRs de machine” e, com base nisso, obter esse tipo de consulta. Então, espere um instante. Este é o repo open source que vamos usar como base. Vou direto para mostrar como isso fica.

09:44 Então, este é o repo. Ele se chama Document Query Engine. Quero mostrar como ele fica quando o iniciamos pela primeira vez. Posso dizer, por exemplo: “PRs do Peter no Ground Zero”. Ah, na verdade, não estamos executando. Vou voltar. Vamos executar primeiro.

10:15 Agora posso fazer minha pergunta. Quando você inicia, ele não está conectado a nada. Não vai produzir resultado algum. Então, vamos construir isso aos poucos. Certo. A primeira coisa de que vamos falar é a descoberta automática do schema. Isso é completamente dinâmico. É um banco de dados sem schema. Nem todos os bancos de dados são sem schema, mas o mesmo princípio pode ser aplicado. Você pode descobrir o schema dinamicamente durante a execução. E a técnica

10:47 envolve amostrar muitos documentos no armazenamento de documentos e, em seguida, derivar um schema a partir deles. Quero mostrar uma parte complicada disso: inferir enums. O resultado é que você pode usar um LLM como uma marreta de Thor, e ele pode fazer um bom trabalho, mas, na verdade, dá para avançar bastante usando apenas métodos procedurais tradicionais. Então, não recorra sempre a um LLM para fazer

11:21 esse tipo de trabalho que parece não determinístico. Esse tipo de coisa é bastante determinístico. Agora que descobrimos o schema, vou mostrar como isso fica na nossa demonstração. Opa. Primeiro, precisamos passar para o próximo nível e depois executar. Agora descobrimos o schema da nossa coleção do GitHub, que contém apenas pull requests.

11:52 Certo, então ela contém não só o schema, mas também índices que ajudam a melhorar o desempenho das consultas. A próxima etapa é a resolução de identidade, aquela coisa de que falei: associar usuários a identidades reais. Mais uma vez, isso pode ser resolvido usando apenas truques procedurais simples. Então, é mais ou menos assim que fazemos. Por baixo dos panos, no Unblocked, quando pegamos nomes de usuário ou

12:28 identidades de sistemas diferentes e fazemos a correspondência entre eles, podemos usar esse tipo de correspondência aproximada e, no fim, se necessário, passar uma lista de nomes para um LLM e usá-lo como critério de desempate. Por fim, a última etapa antes de podermos mostrar a parte interessante é a síntese. De modo geral, essa é a parte mais fácil. Basta pegarmos o schema que resolvemos dinamicamente

13:00 antes. Pegamos a data e a hora atuais e talvez algumas informações sobre quem está fazendo a pergunta, para que ele possa resolver facilmente perguntas como “meus PRs”, e não apenas “os PRs do Peter”. Depois, passamos isso para o LLM e pedimos que sintetize uma consulta para nós. O resultado vai ser parecido com isto. Vamos até este exemplo. Agora posso voltar ao meu mecanismo e tentar executar essa consulta de novo.

13:37 Agora ele vai buscar os documentos para mim e gerar esta consulta. A próxima etapa de que falei foi a validação. Essa é, na verdade, a parte mais importante. Sua consulta pode conter operadores muito perigosos, como o operador de função, por exemplo, que executaria JavaScript bruto no servidor do banco de dados, o que definitivamente não é ideal. Mas também pode haver outras coisas que você queira fazer. Por exemplo, talvez existam campos ocultos que você não queira expor ao LLM

14:12 nem que o LLM deduza e execute. Se você tiver campos de metadados, por exemplo, que contenham IDs de tenants, e quiser isolar cada consulta para um tenant específico, é melhor garantir que o LLM nem interaja com esses campos e, em vez disso, restringi-los nos bastidores. Você pode injetar esses campos por baixo dos panos. É mais ou menos assim que isso funciona. Então, vamos mostrar rapidamente o benefício disso e como fica.

14:47 Vamos até a etapa de validação. Opa. Execute de novo. Se eu fizer agora uma pergunta como “PRs com autenticação no título”, isso provavelmente vai acionar algum tipo de expressão regular. E pronto. Certo. Nosso mecanismo de validação disse: “Desculpe, expressões regulares não são permitidas. Você foi bloqueado”. Agora não podemos fazer isso. A validação é ótima. Mas o que fazemos com isso? Ocorreu um erro.

15:23 Mas, em vez disso, podemos pegar esse erro, enviá-lo de volta ao LLM e deixar que ele tente se corrigir. E é só isso. Do ponto de vista técnico, é só um loop com algum limite máximo de tentativas. Então, se eu tentar de novo, avançar até as tentativas e executar, agora posso tentar essa consulta mais uma vez.

16:00 Opa, essa está errada. Vamos tentar esta. Agora você pode ver que foram necessárias algumas tentativas, mas no fim ele conseguiu. No entanto, restringiu a consulta para usar match e, infelizmente, essa é uma correspondência exata do título. Não temos nenhum PR com esse título exato. Então, precisamos de mais uma coisa:

16:32 a busca de texto completo. Então, agora, se adicionarmos a busca de texto completo ao nosso mecanismo, esperamos obter algo parecido com isto. Vamos tentar mais uma vez.

17:03 Ótimo. Pronto, fomos do início ao fim. Tudo isso é open source. Você pode ver como foi implementado e experimentar por conta própria. E foi isso que construímos: algo que consegue lidar efetivamente com a outra metade do RAG. Então, qualquer coisa relacionada a dados estruturados: você pode usar filtros e agregações; as consultas têm escopo temporal e o sistema se autocorrige. Mas

17:35 o mais legal é que isso também alimenta um agente de chat. Se eu for até aqui e disser algo como “Com o que relacionado à autenticação temos trabalhado na semana passada?”, você verá tudo isso mostrando exatamente o que ele está fazendo e todas as consultas que cria. Agora ele tem os dados e está

18:09 raciocinando sobre eles nos bastidores. E pronto. Muito legal. Então, aí está: contexto estruturado e consultável para agents e pessoas. Só falta mais uma coisa. Na descrição, você provavelmente viu que prometemos um simulador de mecanismo de contexto. Se não quiser conectar o Unblocked agora porque há algumas restrições no seu

18:39 ambiente, temos um projeto open source que permite fazer isso inteiramente localmente. A ideia é criar um pacote de contexto para cada tarefa e, em seguida, executar um teste A/B com esse pacote para a mesma tarefa, mostrando os benefícios de ter todo esse contexto à disposição dos seus agents. E este é o código do PR, caso você queira.

19:16 Certo. E mais uma coisa: se quiser alguns cocos, passe pelo estande. Obrigado.

Transcrição original

[00:01] [music] Are we up? Okay. Can you hear me? Just like this just fine, everyone. Good. Okay. Um, so we’re we’re going to be doing a bit of a speedun here because uh uh we’ve only got 20 minutes, but um I’m I’m Peter from Unblocked. And at Unblocked, we build a context engine. So I’m going to

[00:32] show you a couple of things. The talk’s going to be split into two parts. Um I’m going to show you what a context engine is and how it can add value to your organization. And then we’re going to actually go and build a component of a context engine. And I’m going to show you a couple of open source projects that you can uh go and play with after this. So there’s the agenda. What’s a context engine? How does it deliver value? And then we’ll build. Um so let let’s just hop back in time

[01:04] maybe a few years to the times before AI agents. And in those days um you were the context layer. Imagine that you’re a new employee to an organization and you’re just trying to get to grips with what’s what’s happening. What you usually end up having to do is look at the look at a whole bunch of code, rip around documentation systems just trying to find the information that you need to get your work done. Um, and not to mention like all of the the sort of

[01:35] shared history that’s built up over time through an organization dealing with incidents and the battle scars that come with it. Um, so what a context engine does is it takes all of that institutional knowledge and it pulls it in and what you get the scattered context that goes into the context engine and out the other end you get grounded context which means that the context is all interrelated to each other. It’s intent specific. It’s personalized and it’s permissions aware.

[02:12] And so I’m going to show you exactly what I mean by that. Now let’s imagine that I’m going to go into here into Claude and I’m going to show you a couple of interesting sessions that I had. So um I asked Claude here, this is without a context engine attached to create a plan to optimize a component in our layer called the source mark engine. And uh I’m sure you’re all familiar with what Claude does when it starts a new task. It’s like a new employee. It

[02:45] doesn’t understand anything about your your codebase or your organization. So the first thing it does is it reps around your codebase and and tries to figure out what’s going on. And so you can kind of see that here. And you know it figures it out eventually or at least you know it confidently projects that it’s figured it out. Um, and so it provides kind of like a a recommendation for me there. But now I’m going to show you what it looks like when you attach a context engine to the back end. So now what it does is it calls the unblock

[03:17] context engine and unblock now delivers a very comprehensive but taskspecific context bundle for this task. And what you can see is that it it’s referencing not only the source code but also you know notion documents that talk about the architecture um pull requests slack conversations that were had about optimizing this particular component um and the the the net out is that you get this really tight context bundle with all these links. So now uh if if um you

[03:50] know Claude wants to go back and fetch more information, it has all these great jump off points. But the really interesting thing is is this. So here I spent um you know a dollar 29 on this and it took about a minute and 30 seconds. Um that was with the context engine but without I’m spending up to you know 260 and 3 minutes. So what you see essentially is a 50% reduction in cost which is pretty incredible.

[04:21] Um now I want to show you another interesting demo um which is uh an interesting session that my colleague Whoops sorry bring this out here. It’s an interesting um session that my colleague had with unblock the other week. So what he we also have a code review product and Richie works on that and he discovered that the number of issues that the code review product was surfacing was was starting to drop. So he just asked unblocked and unblocked was able to pull this information

[04:55] um and and you know narrow it down very quickly to uh a likely cause which was that we switched from Opus 48 or Opus 46 to Opus 48 and the behavior characteristics behind the scenes um you know caused all those issues to drop and uh so what he did is he asked on block to just fix it and now on locked um was able to just create a PR behind the scenes and it has all that context and it knows what to do. But the really cool part is you can

[05:27] see that it created this description and it’s it’s just remarkable like it it um understood the PR that caused the regression in the first place and then it found a Slack conversation where the conver where where this was being discussed and pulled on some of the data here to help inform um the fix which which is just nuts. So, I’m going to go back to wh I think I lost my keynote presentation here. Let’s

[05:58] see. There we go. So, you have the same problem with agents, right? Cost. Oh, sorry. This is the wrong [laughter] It’s the wrong keynote. There we go. So now I think what we’re going to do is we’re just going to get right into the building part because we’re we’re quite short on time today. Um and so I’m just going to summarize this. You’ve got

[06:28] context scattered all over the place. You’ve got context in PRs, reviews, comments, issues and tickets, docs, conversations. Um and and all of that is uh semantically queryable, but it’s also structured and rag nails the content part. Um, it it can be it can handle things like content questions, find the code, the PR that changed it, the Slack thread that’s debating it, and if you wrap that stuff in an agent loop, it can go really

[07:01] really far. You give an agent loop tools to do file search after this and it it’s very powerful but it doesn’t handle some of the other type of uh structural questions like PRs that I merged last week who reviewed payments the most open PRs etc. Um, and these are queries. They’re not semantic searches. So, I want to just show you again, um, going back to Richie’s example here that he started the the conversation

[07:33] with unblock by asking it a query based question because there’s a temporal element. Can you show me a chart of ratio weekly since January 1st? Okay. So, in order to do this, it’s not going to be able to just pull this information from a vector store because that’s not where that information is encoded. So, it’s it’s going to have to do that um through some sort of query engine. And so, you know, retrieval has two halves essentially. We’ve got semantic retrieval and that can handle those types of semantic based questions. But

[08:08] today, we’re going to work on this the structured part. We’re going to turn structured queries or natural language queries into structured queries. But generating the queries is actually the easy part. The hard part is the scaffolding that sits around it. So you need to do things like understand the schema so you can pass it to the LLM so it generates the a tightly bound query. Uh you need to also be able to map identities. If I ask a question like

[08:38] open PR is by Rashene, um it’s not going to know who Rashene is because his identity in GitHub might be completely different. So we have to be able to map that somehow. And then when you get the query out of the LLM, it’s untrusted. It could have uh operations that are dangerous. It could cross tenant boundaries. And so you have to have some way of validating that the query is is uh correct and safe. And then finally, uh, even though you do that validation, there could be errors.

[09:11] Um, and when you actually do the query against the database, there could be errors there as well. And so we can actually get the LLM to try to correct itself if it gets into that situation. So this is what we’re aiming for here. We want to go to uh to this. We want to be able to say something like open PR is by machine and then we want to get this kind of query on the back of that. So, just take a sec here. U this is the open- source repo that we’re going to be building against. And I’m going to jump right into what

[09:44] that looks like actually. So, this is the repo here. It’s called the document query engine. And I want to show you what it looks like when we just boot it up the first time. So, I can say, you know, PR is by Peter at ground zero. Oh, actually we’re actually not running it. So, I’ll go back. Let’s run it first.

[10:15] Now I can ask my question. So, when you start it’s going to have it’s not going to be wired up at all. It’s going to produce nothing. So, we’re going to just gradually build this thing up here. Okay. First thing we’re going to talk about is automatic schema discovery. This is completely dynamic. is schemalist. Not and not all databases are schemalist, but the same kind of principle can apply. You can dynamically discover the schema at runtime. Um and so what what the technique

[10:47] involves is sampling a whole bunch of documents in the document store and then deriving a schema from that. And uh you know I just want to show you like one tricky part of that which is inferring enums. Um now the the the outcome from this is that you can use an LLM as a Thor hammer um and it can do a pretty good job but actually you get uh really really far just using traditional procedural methods. So you can you know don’t always fall back to an LLM to do

[11:21] this kind of what looks like non-deterministic work. This is actually quite deterministic this kind of thing. So now that we’ve discovered schema, I’m just going to show you what that looks like in our demo. Whoops. First we have to level up to the next and then run. So now we’ve discovered the schema from our um GitHub collection and this is just pull

[11:52] requests. Okay, so it has not only the schema here but also um indexes that will help improve the performance of queries. The next step is identity resolutions that thing I talked about about mapping you know users to uh real identities and um again this is this can be solved just using simple procedural tricks. So um that that’s actually more or less how we do it. Uh and underneath the hooded unblocks when we take usernames or

[12:28] identities from different systems and map them across um you can do this kind of fuzzy matching and then in the end if you have to you can pass a list of names to an LLM and have it act as a tiebreaker. And finally, uh, the last step before we can actually show the cool stuff is this. It’s the synthesis part. And roughly speaking, this is actually the easiest part. We just take the schema that we dynamically resolve from

[13:00] earlier. We take the current date and time, uh, maybe some information about the user that’s asking the question, so it can easily resolve questions like my PRs and not just Peter’s PRs. Um and then we pass it to the LLM and ask it to synthesize a query for us. And the outcome uh will look something like this. Let’s get to this one. So now I can go back to my engine and try to run that query again.

[13:37] And it’s going to pull the documents for me now and generate this query. Now the next step I I was talking about was was validation. This is actually the most important thing. Um your your uh query could contain really dangerous operators like the function operator for example which would execute raw JavaScript um on the DB server which is definitely not ideal. Um, but there could be other things that you want to do with this. Like for example, you might have hidden fields that you don’t want uh to be surfaced either to the LM

[14:12] or for the LM to to derive and execute. If you have metadata fields, for example, that contain um tenant IDs and you want to isolate each query to a specific tenant, you’re better off making sure that the LM doesn’t interact with those fields at all and then just constraining it behind the scenes. you can inject those fields underneath. And that’s kind of what that looks like. So again, we’re going to just quickly show the payoff for that and what that looks like.

[14:47] Let’s go up to our validation step. Oops. Run it again. So if I now ask a question like this PRs with authentication in the title that is probably going to drive some kind of like regular expression thing and there we go. Okay. So uh our validation engine said sorry regular expressions aren’t allowed you’re getting bounced and now we’re not allowed to do that. So validation is cool. Um but what do we do with that? you know, we got an error.

[15:23] Um, but what we can do instead is just take that error and just loop it back in to the LLM and have the LLM kind of self-correct. And that’s kind of what it that’s all it is. That’s all it looks like from a technical standpoint. It’s just a loop with some sort of maximum retry. And so if I try this again, bounce up to my retries and run that. Now, if I try that query again.

[16:00] Oops, that’s the wrong one. Let’s try this one. Now what you can see is that it actually took a couple attempts. Um but it got there in the end. However, um it constrained it down to use match and unfortunately this is an exact title match. We don’t have any PRs with that exact title. So we need one more thing

[16:32] which is this full text search. So now if we add full text search to our engine um hopefully the outcome that we get is something that looks a little bit like this. So let’s try it one more time.

[17:03] Awesome. So there you go. We got we went from start to finish there. This is all open source. So you can take a look at how it’s implemented and play around with it yourself. And this is what we built. Something that can effectively handle all of the uh other half of rag. So, anything that has to do with uh structural based data, you can have filters, aggregations, it’s time scoped, and it selfcorrects. But

[17:35] what’s really cool is that it also powers a chat agent. And so if I go over here and I say something like um what authentication related things have we’ve been working on last week. Now you get this whole thing that will show you exactly what it’s doing, all the queries that it creates. And now it has the data and it’s just

[18:09] kind of reasoning about it behind the scenes. And there we go. Very cool. So there you are. Structured queryable context for agents and humans. Now there’s just one last thing. Um on the description you probably saw that we were promising a context engine simulator. If you don’t want to wire up unblocked uh right away because you’ve got some constraints in your in your

[18:39] environment, um we have an open source project that will allow you to do this entirely locally yourself. And so the idea is uh it will create a context bundle for you on a taskbytask basis and then take that context bundle and run an AB test against the same task and show you the benefits of having all of that context at your fingertips for your agents. And that’s the uh PR code for that if you want that.

[19:16] All right. And one last thing, if you want some coconuts, come by the booth. Thank you.