Lakebase Search: crie recuperação de informações para agents com Lakebase Postgres

Autoria: Databricks · 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: Lakebase Search: Build AI Retrieval for Agents with Lakebase Postgres · Canal: Databricks · 12:34 · Assistir no YouTube

Tópicos: Agentes de IA, Dados, bancos de dados e embeddings, RAG, busca e recuperação de informação

Resumo

O vídeo apresenta o Lakebase Search e mostra como ele atende às necessidades de recuperação de informações de AI agents com busca vetorial, busca textual e hybrid search. A demonstração explica recursos como BM25, reciprocal rank fusion e uma arquitetura que separa computação e armazenamento. Em seguida, mostra um pipeline com Databricks, Spark e Unity Catalog para processar documentos, gerar embeddings e manter o índice sincronizado quando os documentos são alterados. O resultado é uma solução integrada para consultas transacionais e busca atualizada, sem exigir um banco vetorial separado nem infraestrutura externa de sincronização.

Pontos-chave

Lakebase Search adiciona as extensões Lakebase Vector e Lakebase Text ao Postgres, mantendo compatibilidade com os tipos e operadores do PG Vector.
Lakebase Text oferece pontuação BM25 e recuperação top-K otimizada para melhorar a relevância e o desempenho em buscas textuais.
Hybrid search combina busca vetorial, que captura similaridade semântica, e busca textual, que encontra correspondências exatas.
Reciprocal rank fusion combina listas de resultados com base nas posições, reduzindo os problemas causados por escalas de pontuação diferentes.
Em agentic search, o agent escolhe entre ferramentas de busca textual, vetorial e híbrida conforme a tarefa.
Rabbit Cube comprime vetores no índice para acelerar a recuperação e reduzir o tamanho, mantendo alta precisão de busca.
A arquitetura separa computação e armazenamento durável, permite escalar a computação conforme a demanda e pode reduzi-la a zero quando o workload fica ocioso.
Um pipeline com change data feed, Spark e tabelas do Lakehouse processa documentos alterados, gera embeddings e sincroniza o conteúdo para busca.
Com os documentos sincronizados no Lakebase Postgres, o agent pode recuperar informações atualizadas usando busca vetorial, textual ou híbrida.

Capítulos

Início	Capítulo	Resumo
00:00	Necessidades de busca dos AI agents	O vídeo apresenta os desafios de busca em workloads OLTP e introduz as extensões de texto e vetores do Lakebase Search.
02:36	Hybrid search e agentic search	A demonstração combina busca semântica e textual com RRF e mostra como um agent pode escolher ferramentas de busca.
05:12	Escalabilidade e arquitetura do Lakebase	O vídeo explica a compressão de vetores com Rabbit Cube, o cache de páginas e o escalonamento da computação.
06:46	Processamento de documentos e sincronização	A apresentação mostra como Spark e recursos do Lakehouse processam documentos, geram embeddings e mantêm o índice atualizado.
08:22	Pipeline de atualização automática	Um exemplo percorre o fluxo de alterações da tabela Delta até o processamento dos documentos e a sincronização dos resultados.
10:28	Demonstração e conclusão	A demonstração verifica o pipeline e os embeddings sincronizados, e conclui com o Lakebase Postgres como backend unificado para busca e workloads transacionais.

Citações

A busca fica diretamente ao lado dos dados operacionais. — 02:05

Isso é o que chamamos de hybrid search. — 03:07

O agent pode decidir qual ferramenta usar e quando usá-la. — 04:40

O índice de busca inteiro não precisa caber na RAM. — 06:15

Não há banco vetorial separado nem infraestrutura externa de sincronização para gerenciar. — 09:57

Conceitos e entidades

Lakebase Search (ferramenta): Reúne recursos de busca textual e vetorial no Lakebase Postgres para atender a workloads de recuperação de informações.
Lakebase Vector (ferramenta): Extensão que amplia o PG Vector e usa a arquitetura do Lakebase para oferecer busca vetorial.
Lakebase Text (ferramenta): Extensão de busca textual para Postgres que adiciona pontuação BM25 e recuperação top-K otimizada.
PG Vector (ferramenta): Extensão do Postgres usada como base para a busca vetorial do Lakebase Vector.
BM25 (conceito): Método de pontuação de relevância que considera a frequência dos termos, sua distinção entre documentos e o tamanho dos documentos.
Reciprocal Rank Fusion (conceito): Método que combina listas de resultados com base nas posições dos itens, em vez de comparar diretamente suas pontuações.
Rabbit Cube (conceito): Algoritmo que comprime vetores no índice para reduzir seu tamanho e acelerar a recuperação.
Databricks (empresa): Empresa cuja plataforma oferece os recursos usados na demonstração para processar documentos e sincronizar dados.
Unity Catalog (ferramenta): Recurso usado no exemplo para armazenar a tabela Delta de origem e inspecionar a view materializada resultante.
Spark (ferramenta): Mecanismo usado no pipeline para processar documentos e gerar embeddings sem sobrecarregar as consultas transacionais.

Tradução completa (pt-BR)

00:00 Neste vídeo, vou mostrar como o LakeBase Search atende às necessidades de recuperação de dados dos agents de IA. Depois, vamos percorrer um pipeline de recuperação de IA de ponta a ponta. Usaremos busca híbrida e embeddings automatizados para fazer tudo funcionar em conjunto. Agents fazem muitas buscas, mas não apenas recuperam informações: também escrevem novos dados constantemente. Histórico de conversas, memórias, resultados — tudo precisa poder ser pesquisado assim que é escrito. E os agents podem executar dezenas ou até centenas de

00:31 consultas simultaneamente. Isso torna a busca uma carga de trabalho OLTP crítica, que não pode ficar isolada do seu banco de dados. Mas oferecer suporte à busca nessa escala traz desafios. Para busca vetorial, o PG Vector é uma opção popular no Postgres. No entanto, à medida que os índices crescem, fica difícil mantê-los na memória. E, quando as buscas exigem acesso frequente ao disco, o desempenho pode cair significativamente. Uma opção é adicionar um banco de dados vetorial dedicado.

01:02 Mas, nesse caso, você passa a gerenciar dois sistemas separados e precisa de um pipeline de sincronização de dados para mantê-los consistentes. Para busca de texto completo, o Postgres já oferece suporte integrado por meio do TSVector. No entanto, suas funções nativas de classificação não implementam BM25. O BM25 oferece uma pontuação de relevância mais sofisticada. Ele considera o quanto um termo é distintivo entre os documentos, com que frequência aparece e o tamanho de cada documento.

01:33 É aí que entra o LakeBase Search. O LakeBase Search introduz duas novas extensões do Postgres: LakeBase Text e LakeBase Vector. Vamos começar pelo LakeBase Vector. Ele se baseia no PG Vector e aproveita a arquitetura do LakeBase. E, o que é importante, continua totalmente compatível com os tipos e operadores do PG Vector. Da mesma forma, o Lake Base Text estende a busca de texto completo do Postgres. Ele adiciona pontuação nativa com BM25 e recuperação de top K otimizada.

02:05 Isso ajuda a melhorar a relevância e o desempenho à medida que os conjuntos de dados crescem. Mas o que é particularmente interessante é a arquitetura subjacente. Com o Lake Base Search, a busca fica diretamente junto aos seus dados operacionais. Você pode usar uma única consulta SQL para pesquisar, filtrar e fazer junções com dados operacionais. E tudo isso se beneficia da arquitetura do Lake Base, que desacopla armazenamento e computação, permitindo que as cargas de trabalho de busca escalem.

02:36 A capacidade de escalar a busca é importante, mas também queremos que a recuperação seja precisa. A busca vetorial é ótima para capturar similaridade semântica. Ela entende o significado e a intenção por trás de uma consulta. Já a busca de texto completo é ótima para correspondências exatas. Por exemplo, nomes de produtos, referências e palavras-chave específicas. Na prática, muitas vezes precisamos das duas. Queremos a busca semântica para entender o que o usuário quer dizer e a busca de texto completo para capturar os termos exatos.

03:07 Com o Lake Base Search, podemos combinar as duas abordagens diretamente em SQL. É isso que chamamos de busca híbrida. Agora, como combinamos os resultados? Uma abordagem comum é a fusão recíproca de classificação, ou RRF. A RRF combina as duas listas de classificação. Mas, em vez de usar as pontuações brutas, ela usa as posições dos resultados. Isso evita problemas causados por diferentes escalas de pontuação. Assim, se um resultado tiver uma classificação alta tanto na busca vetorial quanto na busca textual, ele será impulsionado

03:38 para o topo, mesmo que não tenha ficado em primeiro lugar em nenhuma das listas. Vamos ver alguns exemplos, todos com tecnologia do Lake Base Search. Primeiro, vamos começar com uma barra de busca simples para produtos de tecnologia. Quando os usuários digitam em uma barra de busca, muitas vezes queremos oferecer sugestões imediatamente. Para isso, a busca de texto completo é uma ótima opção. Ela é rápida e consegue encontrar nomes e referências de produtos. Agora, quando o usuário realmente executa a

04:08 busca, queremos ir além. Não queremos apenas correspondências exatas de palavras-chave; também queremos capturar o significado por trás da consulta. É aí que entra a busca híbrida. Como você pode ver, os resultados são influenciados tanto pela similaridade semântica quanto pelas correspondências de palavras-chave. Isso já é útil, mas, com agents, podemos ir um passo além. Em vez de deixar que a aplicação decida qual método de busca usar, damos ao agent acesso direto às ferramentas de busca: busca textual, busca vetorial

04:40 e busca híbrida. O agent pode então decidir qual ferramenta usar e quando usá-la. É isso que chamamos de busca agêntica. Vamos ver um exemplo com um agent de suporte. Vou pedir que ele encontre uma soundbar compatível com uma TV que já tenho. Primeiro, o agent pesquisa a própria memória. Ele precisa descobrir qual TV comprei no passado. Depois, executa uma combinação de buscas vetoriais, textuais e híbridas, usando esses resultados para elaborar sua resposta final.

05:12 E, como você pode imaginar, o desempenho é muito importante aqui. O agent talvez precise fazer várias buscas antes de responder. Portanto, tanto a precisão da recuperação quanto a latência da consulta afetam diretamente a experiência do usuário. Agora, vamos ver como o LakeBase oferece suporte a essas cargas de trabalho em escala. Para oferecer uma busca vetorial rápida e precisa, o LakeBase Vector usa um algoritmo chamado Rabbit Cube. O Rabbit Cube comprime os vetores dentro do

05:44 índice. Isso reduz o tamanho deles e permite uma recuperação mais rápida, mantendo alta precisão de busca. Outro aspecto importante é a arquitetura do Lake base. O Lake base separa a computação do armazenamento durável. As páginas de índice acessadas com frequência são servidas a partir da memória ou do cache em disco local. Quando a página não está disponível no cache, a solicitação vai para o servidor de páginas, que pode acessar o armazenamento durável quando necessário. O principal benefício é que o

06:15 índice de busca inteiro não precisa caber na RAM. Essa arquitetura também ajuda com cargas de trabalho em picos. Quando o tráfego aumenta, o Lake base pode escalar automaticamente a computação para atender à demanda. E, quando a carga de trabalho fica ociosa, a computação pode ser reduzida a zero após um tempo limite configurado. O índice permanece no armazenamento durável, pronto para a próxima consulta. Assim, você pode eliminar os custos de computação ociosa sem precisar reconstruir o índice quando a computação for iniciada novamente.

06:46 Até aqui, vimos como o Lake base search atende às cargas de trabalho de recuperação de dados dos agents. Mas lembre-se: agents não apenas leem dados. Eles também os escrevem. Conversas, memórias, estados e resultados. E todas essas informações precisam poder ser pesquisadas assim que são escritas. Para alguns tipos de dados, isso é simples. Quando você insere uma nova linha no Postgres, pode consultá-la imediatamente. Mas as coisas ficam mais complexas com cargas de trabalho centradas em documentos. Por exemplo, criar uma

07:18 base de conhecimento ou manter uma base de conhecimento existente atualizada à medida que os documentos mudam. Esses workflows exigem várias etapas: analisar os documentos, dividi-los em chunks, gerar embeddings e indexar os resultados. Essas tarefas podem ser caras. E, idealmente, não queremos que disputem recursos com as consultas transacionais. É aí que entra o ELT app. O Lakehouse compartilha a mesma camada de armazenamento subjacente.

07:50 Isso nos permite usar diferentes mecanismos de computação para diferentes cargas de trabalho. Podemos transferir o processamento pesado para o Spark. Por exemplo, a análise de documentos e a geração de embeddings usando funções de IA. Enquanto isso, o Lakehouse continua atendendo a consultas transacionais e de busca, sem precisar executar essas transformações caras em sua própria computação. E a mesma arquitetura funciona em diferentes cenários, seja para indexar uma coleção inteira de documentos pela primeira vez ou para atualizar continuamente

08:22 o índice de busca à medida que os agents modificam documentos. Vou mostrar como isso funciona com um exemplo. Imagine que temos um agent capaz de criar e atualizar documentos. Com o tempo, esses documentos vão mudar, mas o agent ainda precisa recuperar as informações mais recentes. Então, a pergunta é: como mantemos o índice de busca atualizado automaticamente? Com os recursos nativos do Databricks, podemos criar esse workflow sem infraestrutura externa. É assim que funciona. Primeiro, nossos

08:53 documentos são armazenados em uma tabela Delta do Unity Catalog. Ativamos o feed de dados de alteração do Lakehouse, ou CDF. Isso nos permite acompanhar cada inserção, atualização e exclusão. Em seguida, usamos um job do Lakehouse com um acionador de atualização de tabela. Sempre que a tabela de origem muda, o job aciona um pipeline declarativo do Spark. Dentro desse pipeline, a primeira etapa é criar uma tabela de streaming. Essa tabela de streaming aplica as alterações e reconstrói a versão mais recente dos nossos documentos em

09:25 Delta. Depois, criamos uma view materializada, na qual fazemos o processamento dos documentos. Usamos o AI prep search para dividir semanticamente os documentos em chunks e o AI query para gerar os embeddings. Por fim, criamos uma tabela de sincronização. Ela traz os chunks de documentos com embeddings para o Lakehouse como uma tabela Delta somente leitura. Depois que os dados são sincronizados, o Lakehouse search pode usá-los para a busca híbrida. E o melhor é que o workflow permanece sincronizado automaticamente

09:57 do Lakehouse para o Lakehouse por meio do pipeline do Spark e de volta para o Lakehouse por meio da tabela de sincronização. Assim, quando um agent atualiza um documento, o pipeline processa a alteração. E o conteúdo atualizado passa a poder ser pesquisado assim que a sincronização é concluída. Não é preciso gerenciar um banco de dados vetorial separado nem uma infraestrutura externa de sincronização. Vamos ver isso na prática. Aqui, o agent pode criar e modificar documentos. Vou pedir que ele atualize um guia para comprar fones de ouvido. Especificamente,

10:28 Vou pedir que ele adicione uma nova seção sobre resistência à água. Depois de alguns segundos, o agent atualizou o guia. Nos bastidores, isso significa que o documento foi atualizado no banco de dados. Agora, vamos ver o que acontece em seguida. Primeiro, a atualização do documento deve acionar nosso pipeline declarativo do Spark. Vamos navegar até Jobs e Pipelines. Aqui, podemos ver que o pipeline foi acionado e está em execução. Vamos abri-lo e dar uma olhada mais de perto.

11:00 Nossos dados de origem vêm de uma tabela Delta. Uma tabela de streaming processa as alterações nos documentos, e a saída é uma visualização materializada que contém os trechos dos documentos e seus embeddings. Agora, vamos ver o código. Aqui, podemos ver como o pipeline é definido e como ele usa duas funções SQL nativas: AI prep search para dividir semanticamente o conteúdo em trechos e AI query para gerar embeddings. Em seguida, vamos navegar até o Unity Catalog. Aqui, podemos inspecionar a visualização materializada resultante

11:31 e ver os trechos dos documentos e os embeddings gerados. A partir daqui, podemos criar uma tabela de sincronização. No meu caso, já criei a tabela e os dados foram sincronizados. Então, vamos à interface do Lakehouse. Primeiro, vou selecionar o projeto certo, depois o esquema certo e, por fim, vou abrir a tabela sincronizada. Aqui, podemos ver os documentos divididos em trechos junto com os embeddings. E, como esses dados agora estão no Lakehouse Postgres, podemos usar a busca do Lakehouse

12:02 diretamente. A busca vetorial e a busca de texto completo estão disponíveis, e podemos combiná-las para fazer recuperação híbrida. Assim, o agent pode recuperar os documentos certos, incluindo as atualizações mais recentes. Em resumo, o Lakehouse Postgres oferece um back-end unificado para workloads OLTP de missão crítica, incluindo busca e recuperação para agents de IA. E, como os agents precisam tanto de recursos transacionais quanto analíticos, o Lakehouse nos permite usar o mecanismo certo para cada tarefa. O Lakehouse

12:34 para atender a consultas, e o Lakehouse para processamento intensivo de dados e transformações de IA, tudo isso sem conectar várias plataformas nem gerenciar ativamente pipelines separados de CDC e ETL. Você encontra o exemplo de notebook na descrição. Obrigado.

Transcrição original

[00:00] In this video, I’ll show you how LakeBase Search supports the retrieval needs of AI agents. Then, we’ll walk through an end-to-end AI retrieval pipeline. We’ll use hybrid search and automated embeddings to make everything work together. Agents search a lot, but they don’t just retrieve information, they constantly write new data, too. Chat history, memories, outputs, all of it needs to be searchable the moment it’s written. And agents can run tens or even hundreds of

[00:31] queries concurrently. This makes search a critical OLTP workload, one that can’t be siloed away from your database. But, supporting search at this scale comes with challenges. For vector search, PG Vector is a popular choice in Postgres. However, as indexes grow, keeping them in memory becomes difficult. And when searches require frequent disk access, performance can degrade significantly. One option is to add a dedicated vector database.

[01:02] But then, you’re managing two separate systems, and you need a data synchronization pipeline to keep them consistent. For full-text search, Postgres already provides built-in support through TSVector. However, its native ranking functions don’t implement BM25. BM25 gives us more sophisticated relevance scoring. It considers how distinctive a term is across documents, how frequently it appears, and the length of each document.

[01:33] This is where LakeBase Search comes in. LakeBase Search introduces two new Postgres extensions, LakeBase Text and LakeBase Vector. Let’s start with LakeBase Vector. It builds on PG Vector and takes advantage of the LakeBase architecture. And, importantly, it remains fully compatible with PG Vector’s types and operators. Similarly, Lake Base Text extends Postgres full text search. It adds native BM25 scoring and optimized top K

[02:05] retrieval. This helps improve relevance and performance as data sets grow. But, what’s particularly interesting is the underlying architecture. With Lake Base Search, search lives directly alongside your operational data. You can use a single SQL query to search, filter, and join with operational data. And all of these benefits from Lake Base’s decoupled storage and compute architecture, allowing search workloads to scale.

[02:36] Now, scaling search is important, but we also want retrieval to be accurate. Vector search is great at capturing semantic similarity. It understands the meaning and intent behind a query. Full text search, on the other hand, is great for exact matches. Things like product names, references, and specific keywords. In practice, we often need both. We want semantic search to understand what the user means, and full text search to capture exact terms.

[03:07] With Lake Base Search, we can combine both approaches directly in SQL. This is what we call hybrid search. Now, how do we combine the results? One common approach is reciprocal rank fusion, or RRF. RRF merges the two rank lists. But, instead of using their raw scores, it uses their positions. This avoids problems caused by different scoring scales. So, if a result ranks highly in both vector and text search, it gets boosted

[03:38] toward the top, even if it wasn’t the number one result in either list. Let’s look at a few examples, all powered by Lake Base Search. First, let’s start with a simple search bar for tech products. When users type into a search bar, we often want to provide suggestions immediately. For this, Full Text Search is a great fit. It’s fast and it can match product names and references. Now, when the user actually runs the

[04:08] search, we want to go further. We don’t just want exact keyword matches, we also want to capture the meaning behind the query. And that’s where hybrid search comes in. As you can see, the results are influenced by both semantic similarity and keyword matches. Now, this is already useful, but with agents, we can take it one step further. Instead of having the application decide which search method to use, we give the agent access to the search tools directly. Text Search, Vector Search,

[04:40] and Hybrid Search. The agent can then decide which tool to use and when to use it. This is what we call agentic search. Let’s look at an example with a support agent. I’ll ask it to find a sound bar that’s compatible with a TV I already own. First, the agent searches its memory. It needs to find which TV I purchased in the past. Then, it runs a combination of vector, text, and hybrid searches, using those results to build its final

[05:12] response. And, as you can imagine, performance matters a lot here. The agent might need to perform several searches before answering. So, both retrieval accuracy and query latency directly affect the user experience. Now, let’s look at how LakeBase supports these workloads at scale. To deliver fast and accurate vector search, LakeBase Vector uses an algorithm called Rabbit Cube. Rabbit Cube compresses vectors inside

[05:44] the index. This reduces their size and enables faster retrieval while maintaining high search accuracy. Another important aspect is the Lake base architecture. Lake base separates compute from durable storage. Frequently accessed index pages are served from memory or local disk cache. When the page isn’t available in the cache, the request goes to the page server. Which can access durable storage when needed. The key benefit is that the

[06:15] entire search index doesn’t need to fit in RAM. And this architecture also helps with bursty workloads. When traffic increases, Lake base can automatically scale compute to meet demand. And when the workload becomes idle, compute can scale to zero after a configured timeout. The index remains in durable storage ready for the next query, so you can eliminate idle compute costs without having to rebuild the index when compute starts again.

[06:46] So far, we’ve seen how Lake base search serves retrieval workloads for agents. But remember, agents don’t just read data. They also write it. Chats, memories, states, and outputs. And all of that information needs to become searchable as soon as it’s written. For some types of data, this is straightforward. When you insert a new row in Postgres, you can query it immediately. But things become more complex with document heavy workloads. For example, building a

[07:18] knowledge base or keeping an existing knowledge base up to date as documents change. These workflows require several steps. Parsing documents, splitting them into chunks, generating embeddings, and indexing the results. These tasks can be expensive. And ideally, we don’t want them competing with transactional queries for resources. This is where ELT app comes in. Lakehouse share the same underlying storage layer.

[07:50] This allows us to use different compute engines for different workloads. We can offload heavy processing to Spark. For example, document parsing and embedding generation using AI functions. Meanwhile, Lakehouse continues serving transactional and search queries without having to run those expensive transformations on its own compute. And the same architecture works for different scenarios. Whether we’re indexing an entire document collection for the first time or continuously

[08:22] updating the search index as agents modify documents. Let me show you how this works with an example. Imagine we have an agent that can create and update documents. Over time, those documents will change, but the agent still needs to retrieve the latest information. So, the question is, how do we keep the search index up-to-date automatically? With native Databricks features, we can build this workflow without external infrastructure. Here’s how it works. First, our

[08:53] documents are stored in a Unity Catalog Delta table. We enable Lakehouse change data feed or CDF. This allows us to track every insert, update, and delete. Next, we use a Lakehouse job with a table update trigger. Whenever the source table changes, the job triggers a Spark declarative pipeline. Inside that pipeline, the first step is to create a streaming table. This streaming table applies the changes and and reconstructs the latest version of our documents in

[09:25] Delta. Then, we create a materialized view, and this is where we perform document processing. We use AI prep search to semantically chunk the documents and AI query to generate their embeddings. Finally, we create a sync table. This brings the embedded document chunks into Lakehouse as a read only possible stable. Once the data is synchronized, Lakehouse search can use it for hybrid search. And the best part is that the workflow stays synchronized automatically

[09:57] from Lakehouse to the Lakehouse through the Spark pipeline and back to Lakehouse through sync table. So, when an agent updates a document, the pipeline processes the change. And the updated content becomes searchable once synchronization completes. No separate vector database and no external synchronization infrastructure to manage. Let’s see this in practice. Here, the agent can create and modify documents. I’ll ask it to update a guide for purchasing head foods. Specifically,

[10:28] I’ll ask it to add a new section about water resistance. After a few seconds, the agent has updated the guide. Behind the scenes, this means the document was updated in the database. Now, let’s see what happens next. First, the document update should trigger our Spark declarative pipeline. Let’s navigate to jobs and pipelines. Here, we can see that the pipeline has been triggered and it’s now running. Let’s open it and take a closer look.

[11:00] Our source data comes from a Delta table. A streaming table processes the document changes and the output is a materialized view containing the document chunks and their embeddings. Now, let’s look at the code. Here, we can see how the pipeline is defined and how it uses two native SQL functions, AI prep search for semantic chunking and AI query for generating embeddings. Next, let’s navigate to Unity Catalog. Here, we can inspect the resulting materialized view

[11:31] and see the document chunks and generated embeddings. From here, we can create a sync table. In my case, I’ve already created it and the data has been synchronized. So, let’s head over to the Lakehouse interface. First, I’ll select the right project, then the right schema, and finally, I’ll open the synced table. Here, we can see the chunked documents together with the embeddings. And because this data is now in Lakehouse Postgres, we can use Lakehouse search

[12:02] directly. Both vector search and full-text search are available, and we can combine them for hybrid retrieval. So, the agent can retrieve the right documents, including the latest updates. So, to sum up, Lakehouse Postgres provides a unified back-end for mission-critical OLTP workloads, including search and retrieval for AI agents. And because agents need both transactional and analytical capabilities, Lakehouse lets us use the right engine for each task. Lakehouse

[12:34] for serving queries and the Lakehouse for heavy data processing and AI transformations, all without stitching together multiple platforms or actively managing separate CDC and ETL pipelines. You can find the notebook example in the description. Thank you.