00:00:00Vamos resolver o problema do Claude Code e da memória, fazendo sistemas de IA
00:00:06responderem perguntas sobre conversas passadas ou grandes volumes de documentos de forma confiável,
00:00:13um problema que tentamos resolver há anos. A resposta típica tem sido o RAG (Geração Aumentada por Recuperação) e,
00:00:20embora este vídeo se chame "Os Sete Níveis do Claude Code e RAG", o que ele realmente aborda
00:00:26é a desconstrução desse problema do Claude Code, e dos sistemas de IA em geral e sua memória,
00:00:33e o mais importante, este vídeo serve para lhe dar um roteiro que mostra onde você está
00:00:37nesta luta entre sistemas de IA e memória, e o que você pode fazer para chegar ao próximo nível. Então,
00:00:43ao passarmos por estes sete níveis de Claude Code e RAG, abordaremos vários tópicos, mas
00:00:48não vamos começar pelo GraphRAG ou algo complicado; vamos começar do início,
00:00:53que são apenas os sistemas de memória básicos nativos do Claude Code, porque, por mais triste que seja,
00:00:59é aqui que a maioria das pessoas não apenas começa, mas onde elas permanecem. Da memória automática
00:01:04e coisas como o claud.md, passaremos para ferramentas externas, como o Obsidian, antes de finalmente
00:01:10estarmos com os peixes grandes, com os verdadeiros sistemas de RAG. Nesses níveis, falaremos sobre o que o RAG é,
00:01:16como funciona, os diferentes tipos: RAG ingênuo versus GraphRAG versus RAG agêntico, coisas como
00:01:21re-rankers e tudo mais. E em cada nível, vamos detalhar da mesma forma:
00:01:25falaremos sobre o que esperar desse nível, as habilidades que você precisa dominar, as
00:01:29armadilhas que deve evitar e o que precisa fazer para avançar para o nível seguinte. O que este vídeo
00:01:34não será é uma explicação técnica super profunda de como necessariamente configurar
00:01:40esses sistemas específicos, porque já fiz isso em muitos casos quando falamos de GraphRAG e
00:01:45LightRAG, por exemplo, ou até tópicos mais avançados como "RAG de qualquer coisa" nesses diferentes
00:01:50sistemas de embedding. Fiz vídeos onde detalho do início ao fim como
00:01:55configurar isso você mesmo; então, quando chegarmos a essas seções, linkarei esses vídeos. Isto é para
00:02:00o bem de nós dois, para que o vídeo não tenha cinco horas, mas nesses níveis ainda falaremos
00:02:04sobre o que isso significa, o que cada sistema oferece e quando você deve usá-lo. Mas antes
00:02:09de começarmos com o nível um, uma palavra rápida do patrocinador de hoje: eu mesmo. No mês passado, lancei a
00:02:15Master Class do Claude Code, e é a melhor forma de ir do zero a desenvolvedor de IA, especialmente se você não
00:02:21tem um background técnico. Esta Master Class é um pouco diferente porque focamos em vários
00:02:25casos de uso para aprender a usar o Claude Code; um deles é algo como
00:02:31RAG em nível de produção: como construir os sistemas de RAG que você verá neste vídeo em um cenário real e
00:02:37realmente usá-lo como membro de uma equipe ou vendê-lo a um cliente. É nisso que focamos; então,
00:02:42se quiser ter acesso, você pode encontrá-lo dentro do Chase AI Plus; há um link no comentário fixado,
00:02:47e adoraríamos ter você lá. Agora vamos começar com o nível um: Memória Automática.
00:02:51Estes são os sistemas que o Claude Code usa automaticamente para criar um aparato de memória para
00:02:58realmente lembrar das coisas sobre as quais você falou. E você sabe que está aqui se nunca configurou
00:03:02nada intencionalmente para ajudar o Claude Code a lembrar do contexto geral sobre conversas anteriores
00:03:09ou apenas do que está acontecendo no seu código. E quando falamos de memória automática,
00:03:13é literalmente o nome: o sistema de memória automática. Quando habilitado no Claude Code,
00:03:18ele basicamente permite que o Claude Code crie arquivos markdown por conta própria que listam
00:03:26coisas que ele considera importantes sobre você naquele projeto específico. Isso é puramente baseado
00:03:32na intuição dele conforme as conversas. E eu posso ver esses arquivos de memória criados; novamente,
00:03:37ele faz isso sozinho. Se você for na pasta .claude, em projetos, verá uma
00:03:42pasta chamada "memory". Dentro desse arquivo, você verá vários arquivos markdown; aqui
00:03:47há quatro deles, e são como a versão do Claude Code de post-its, dizendo: "Ah sim, ele mencionou
00:03:51aquela vez sobre as metas de crescimento do seu projeto no YouTube; vamos anotar isso.". E dentro da pasta
00:03:59de memória de todos haverá um arquivo memory.md. Veja que neste arquivo de memória há uma nota sobre
00:04:04uma das minhas habilidades e, depois, ele tem basicamente um índice de todos esses subarquivos de memória,
00:04:09dizendo: "Ei, tem um de crescimento do YouTube aqui, um de receita, um de referências e o conteúdo deles".
00:04:13Então, se eu estiver apenas conversando com o Claude Code no meu arquivo vault e mencionar algo sobre o YouTube
00:04:19e meus objetivos de crescimento, ele consultará isso e dirá: "Ah sim, o Chase está tentando
00:04:23conseguir X inscritos até o final de 2026". É bonitinho, mas no fim das contas não é tão útil.
00:04:30É tipo quando você está no ChatGPT e ele traz coisas aleatórias de
00:04:35conversas anteriores e parece que as força ali. É tipo: "Ok, entendi que você lembrou disso,
00:04:40mas eu não me importo e, honestamente, é meio estranho ficar mencionando isso; preferia que não o fizesse".
00:04:44Infelizmente, é aqui que a maioria das pessoas para em sua jornada de memória, e isso é construído sobre um
00:04:49passado quase abusivo que todos temos quando se trata de usar esses chatbots,
00:04:54porque esses chatbots não têm uma memória real de uma conversa para outra e, por isso,
00:05:00estamos sempre morrendo de medo de sair de uma janela de chat ou de uma sessão de terminal,
00:05:06porque você pensa: "Meu Deus, ele não vai lembrar da minha conversa". E isso é um
00:05:10problema real, porque qual é a resposta de todo mundo para a janela de chat não conseguir lembrar de nada?
00:05:17Bom, a resposta é apenas manter aquela conversa rolando para sempre, porque você não quer chegar num
00:05:22cenário onde precise sair e ele esqueça tudo. Este é um medo que nasce aqui, dentro
00:05:26dessas janelas de chat, começando com o ChatGPT e o mesmo com o web app do Claude. E, honestamente, costumava
00:05:31ser infinitamente pior no web app do Claude, pois todos lembramos dos dias antes da janela de contexto de
00:05:351 milhão, onde você teria uns 30 minutos para falar com o Claude e depois: "Bom, vejo você em quatro horas".
00:05:39O problema é que as pessoas trouxeram esse tipo de comportamento psicótico e neurótico para o
00:05:45terminal. E o que elas fazem, em grande parte porque agora podem se safar com uma janela de contexto de 1 milhão,
00:05:50é nunca limpar; elas apenas continuam falando e falando com o Claude Code porque
00:05:55nunca querem que ele esqueça o que estão discutindo por causa desses problemas de memória. O
00:06:00problema disso é que sua eficiência cai drasticamente com o tempo quanto mais você fala com o Claude Code
00:06:05na mesma sessão. Este é o conceito fundamental do "Apodrecimento de Contexto" (Context Rot). Se você não sabe
00:06:10o que é, é o fenômeno de que quanto mais uso um sistema de IA na mesma sessão, no mesmo chat,
00:06:16e preencho essa janela de contexto, pior ele fica. Você pode ver aqui: Claude Code, janela de
00:06:231 milhão. Com 256 mil tokens preenchidos — ou seja, usei apenas um quarto da janela —
00:06:30estamos em 92%. No final, estou em 78%. Então, quanto mais você usa no mesmo chat, pior fica.
00:06:36E esse é um dos principais problemas que as pessoas têm com sistemas de IA e memória. Eu tenho o Claude Code,
00:06:42ele tem um milhão de contexto agora e, no entanto, não quero que ele esqueça a conversa que estou tendo,
00:06:47então nunca fecho a janela; apenas vou enchendo e enchendo. Duas coisas acontecem: primeiro, a eficácia
00:06:51cai, como você viu; segundo, seu uso dispara porque a quantidade de tokens usados em
00:06:591 milhão — naqueles 800 mil de contexto — é muito maior do que em 80 mil. Então, este não é o único problema,
00:07:08mas, mudando um pouco de assunto, estamos num ecossistema atual onde todos reclamam que o Claude Code
00:07:12foi piorado e que o uso acaba automaticamente. Há várias razões para isso, mas uma
00:07:18delas, sem dúvida, é que desde que o contexto de 1 milhão foi introduzido, as pessoas não têm ideia de como
00:07:24gerenciar sua própria janela de contexto e não são nem de longe tão agressivas
00:07:29em limpar e resetar a conversa quanto deveriam. Mas isso é outro assunto.
00:07:34O ponto de toda essa discussão é que, quando se trata de memória, RAG e
00:07:39Claude Code, temos que ter o apodrecimento de contexto em mente, pois estamos constantemente lidando
00:07:44com essa tensão de: "Ok, quero ingerir contexto para o Claude responder perguntas sobre várias coisas,
00:07:50mas, ao mesmo tempo, não quero que o contexto fique grande demais porque senão ele piora".
00:07:55Isso é algo em que sempre precisamos pensar nesta conversa sobre memória.
00:08:02Mas, voltando ao vídeo e ao nível um: o que as pessoas estão fazendo no nível um? A
00:08:06resposta é: nada demais. E como não fazem nada, elas apenas dependem
00:08:10de uma janela de contexto inchada para lembrar das coisas. Você sabe que está aqui quando nunca editou
00:08:15um arquivo claude.md e nunca criou nenhum tipo de artefato ou arquivo que permita ao Claude
00:08:23Code perceber o que diabos está acontecendo, o que ele fez no passado e o que precisa
00:08:27fazer no futuro. Então, o que precisamos dominar neste nível? Bom, na verdade, tudo o que você
00:08:31precisa dominar, apesar de tudo o que escrevi aqui, é entender que a memória automática não é suficiente.
00:08:35Precisamos assumir um papel ativo no Claude Code e na memória, pois uma armadilha neste nível
00:08:40é que, se você não for ativo, não terá controle. E precisamos controlar o que o Claude Code
00:08:44considera ao responder nossas perguntas. Então, para desbloquear o nível um e avançar para o nível dois,
00:08:50precisamos de uma memória explícita e descobrir como realmente fazer isso. Quais arquivos
00:08:57você precisa editar e entender que existem para assumir um papel ativo nessa relação?
00:09:01O nível dois foca em um arquivo específico: o arquivo claude.md. Quando você descobre
00:09:06essa ferramenta, parece uma dádiva divina; finalmente há um lugar único onde posso dizer ao Claude
00:09:12Code algumas regras e convenções que sempre quis que ele seguisse, e ele o fará. De
00:09:16fato, posso incluir coisas que eu queria que ele lembrasse, e ele sempre lembrará. Parece um progresso no início.
00:09:20Aqui está um template de um arquivo claude.md padrão para um projeto de assistente pessoal. O
00:09:29Claude Code criará automaticamente um arquivo claude.md, mas você tem a habilidade de
00:09:33editar ou até atualizá-lo sob demanda usando um comando como /init. A ideia
00:09:38disso é que ele é, novamente, como o santo graal das instruções para o Claude Code naquele projeto
00:09:43específico. Para todos os efeitos, o Claude Code dará uma olhada nisso antes de qualquer tarefa que
00:09:50ele executar. Então, se você quer que ele lembre de coisas específicas, o que vai fazer? Você vai
00:09:54colocar no claude.md. Teoricamente, é uma escala menor que um RAG; sabe, não
00:10:00estamos colocando documentos completos aqui, mas são coisas que você quer que o Claude Code
00:10:05sempre lembre e convenções que você quer que ele siga. Para este aqui, temos uma seção "Sobre Mim",
00:10:09temos um detalhamento da estrutura do sistema de arquivos e como queremos que ele opere quando
00:10:14dermos comandos. E, como eu disse, como isso é referenciado em basicamente todo prompt, o Claude Code
00:10:18é muito bom em seguir isso. Então, a ideia de: "Ei, eu queria que ele lembrasse de coisas específicas",
00:10:22parece um ótimo lugar para colocar. Mas precisamos ter cuidado, pois podemos exagerar. Quando olhamos
00:10:28estudos como este avaliando o agents.md — e você pode trocar agents.md por claude.md —
00:10:33eles descobriram no estudo que esse tipo de arquivo pode, na verdade, reduzir a eficácia de modelos de
00:10:40linguagem grandes em geral. E por que isso? Bom, é porque a mesma coisa que o torna tão bom — o fato
00:10:45de ser injetado em basicamente todo prompt — é o que também pode torná-lo ruim. Estamos realmente
00:10:51injetando o contexto correto? Conseguimos atravessar o ruído e estamos dando a ele um
00:10:57sinal adequado ou estamos apenas jogando coisas que achamos boas? Porque, se não for relevante para
00:11:02praticamente cada prompt que você dará no seu projeto, deveria estar aqui no claude.md?
00:11:08Esta é uma boa maneira de deixar o Claude Code lembrar das coisas? Eu diria que não, não muito.
00:11:15E isso vai contra o que muita gente diz sobre o claude.md e como você deve estruturá-lo. Baseado em estudos
00:11:20como esse e na experiência pessoal, menos é mais. Poluição de contexto é real; apodrecimento de contexto é real.
00:11:26Então, se algo está dentro do claude.md e não faz sentido para, novamente, praticamente
00:11:32cada prompt que você der, não deveria estar lá. Mas a maioria das pessoas não percebe isso e,
00:11:37em vez disso, cai na armadilha de um livro de regras inchado. Em vez disso, as habilidades que deveríamos dominar
00:11:42são: como criar um contexto de projeto que seja de alto sinal? Como garantir que o que estou colocando
00:11:48dentro disso faça sentido? E com isso vem a ideia de consciência do apodrecimento de contexto,
00:11:53como falamos no nível anterior. Juntando tudo isso, o nível dois parece que você está
00:11:57seguindo em frente, tipo: "Ei, estou assumindo um papel ativo na memória, tenho este arquivo claude.md". Mas você percebe
00:12:02que não é o suficiente. E quando falamos do nível três e do que podemos fazer para avançar,
00:12:08queremos pensar em algo que não seja um livro de regras estático, mas algo que possa evoluir. E é
00:12:14algo que pode incluir o claude.md. Em vez de depender do claude.md para fazer tudo, e se
00:12:18usarmos o claude.md como uma espécie de arquivo de índice que aponta o Claude Code na direção certa?
00:12:24O que eu quis dizer com o claude.md agindo como um índice e apontando para outros arquivos?
00:12:30Bom, estou falando de uma arquitetura dentro do seu código que não tem apenas um arquivo markdown
00:12:37tentando lidar com todos os problemas de memória na forma do claude.md. Estou falando de ter
00:12:41múltiplos arquivos para tarefas específicas. Acho que um ótimo exemplo disso em ação é o que o GSD — a ferramenta
00:12:47de orquestração "Get Shit Done" — faz. Ele não cria apenas um arquivo dizendo: "Ei, isso é o que
00:12:53vamos construir, estes são os requisitos e isso é o que fizemos e para onde vamos".
00:12:56Em vez disso, ele cria vários. Você pode ver aqui à esquerda: temos um project.md, um requirements.md,
00:13:02um roadmap e um state. Os requisitos existem para que o Claude Code sempre saiba e tenha memória do
00:13:08que ele deve estar construindo. O roadmap detalha exatamente o que vamos
00:13:12criar, não apenas agora, mas o que fizemos no passado e no futuro. E o project dá a ele
00:13:16memória, dá contexto do que estamos fazendo em uma visão geral de alto nível; qual é o nosso norte? E,
00:13:22ao dividir a memória, o contexto e as convenções nesse tipo de sistema, estamos lutando contra a ideia
00:13:29do apodrecimento de contexto e a ideia trazida naquele estudo, que é que injetar esses arquivos em todo
00:13:34prompt o tempo todo — como fazemos no claude.md — é, na verdade, contraproducente. Não nos ajuda a obter
00:13:39resultados melhores. Além disso, dividi-lo nessas partes e ter um caminho claro para o Claude
00:13:44Code seguir, dizendo: "Ei, quero descobrir onde está essa informação. Ah, vou ao claude.md.
00:13:49O claude.md diz que tenho estas cinco opções; ok, é aquela ali, deixe-me ir buscá-la".
00:13:54Esse tipo de estrutura é o que você verá 100% no nível seguinte, quando falarmos de
00:13:58Obsidian, e na verdade é como uma reimaginação bruta do sistema de fragmentação (chunking) e da
00:14:04busca por similaridade vetorial que vemos em sistemas de RAG reais. Mas, obviamente, isso é em pequena escala.
00:14:10Neste nível, estamos falando de quatro arquivos markdown; não estamos falando de um sistema que
00:14:14possa lidar com milhares e milhares de documentos. Mas, como você vai me ouvir falar
00:14:20muito: o que isso significa para você? Você precisa de um sistema — dos níveis quatro,
00:14:26cinco, seis, sete — que possa lidar com essa quantidade de documentos? A resposta é: talvez não. E parte desta
00:14:32jornada de RAG é entender não apenas onde você está, mas para onde você realmente precisa ir. Você
00:14:36sempre precisa estar no nível sete e saber como fazer um sistema de RAG agêntico dentro do Claude Code? É
00:14:41provavelmente bom saber como fazer, mas também é bom saber quando você não precisa
00:14:46implementar isso. Às vezes, o que vemos nesses sistemas como este é o suficiente para muita gente.
00:14:52Então, é tão importante saber como fazer quanto saber se você precisa e se deve fazer.
00:14:58Quando falamos do nível três e de arquivos de estado, como sabemos que estamos aqui?
00:15:00Bom, sabemos que estamos aqui quando ainda estamos estritamente dentro do ecossistema Claude Code. Não
00:15:04integramos ferramentas ou aplicações externas e, na verdade, estamos apenas criando
00:15:09vários arquivos markdown para criar nosso próprio sistema caseiro de fragmentação de memória.
00:15:14Mas isso ainda é muito importante; ainda estamos dominando algumas habilidades reais aqui. A ideia de
00:15:18realmente estruturar documentos, ter algum sistema em vigor que atualize o estado em cada
00:15:23sessão — porque isso também pode ser um problema com RAG: como garantir que tudo esteja
00:15:28atualizado? E é provável que você também esteja começando a usar camadas de orquestração neste ponto, como
00:15:33GSD e Superpowers, que fazem essa arquitetura de múltiplos arquivos markdown por conta própria. Mas
00:15:40há uma armadilha real aqui. O que criamos neste projeto é muito voltado apenas para esse projeto. É
00:15:46meio desajeitado pegar esses arquivos markdown e movê-los para outro projeto. Então, o nível
00:15:51quatro é onde trazemos o Obsidian, uma ferramenta que tem recebido muito destaque
00:15:56e por um bom motivo. Quando você tem pessoas como Andre Karpathy falando sobre essas
00:16:00bases de conhecimento de LLM que criaram — construídas, para todos os efeitos, sobre uma fundação no
00:16:06Obsidian — e conseguindo quase 20 milhões de visualizações, devemos ouvir e ver como isso realmente
00:16:11está operando. Agora, para contextualizar, eu fiz uma análise profunda sobre essa base de conhecimento
00:16:18de LLM do Andre Karpathy no Obsidian; vou linkar acima. Se quiser focar em como construir isso, confira o link.
00:16:22O que eu também quero mencionar para a maioria é que este Obsidian do qual falaremos
00:16:27aqui no nível quatro é, honestamente, o nível que a maioria das pessoas deveria almejar,
00:16:32porque é o suficiente para a maioria das pessoas e na maioria dos casos. Quando falarmos dos níveis cinco, seis e
00:16:37sete, falaremos sobre estruturas reais de RAG e, para ser sincero, é exagero para a maioria. Isso
00:16:43é exagero para a maioria. Adoramos falar sobre RAG como se fosse ótimo, eu entendo isso, mas
00:16:50o Obsidian é aquela solução de 80% que, na realidade, é como uma solução de 99% para a maioria, porque é gratuito,
00:16:56basicamente não tem custo de manutenção e faz o trabalho para o operador individual. E quando digo que faz o trabalho
00:17:02para o operador individual, quero dizer que ele resolve o problema de ter o Claude Code conectado a vários
00:17:07documentos diferentes, a vários arquivos markdown, conseguindo informações precisas e oportunas
00:17:13e dando ao ser humano uma visão sobre esses documentos. Porque, quando clico
00:17:19nesses documentos, fica muito claro o que está acontecendo aqui e fica muito claro quais documentos
00:17:24estão relacionados. Quando clico nestes links, sou levado a mais documentos; quando clico nestes links,
00:17:30sou levado a ainda mais documentos. E para mim, como ser humano, ter essa visão é importante,
00:17:36porque, para ser totalmente sincero, eu diria que a visão baseada no Obsidian sobre os documentos supera
00:17:42muita da visão que você obtém dos sistemas de RAG. Quando falamos de milhares e milhares de
00:17:47documentos sendo incorporados em algo como um sistema graph RAG, isso parece ótimo visualmente
00:17:52parece muito impressionante, mas você realmente sabe o que está acontecendo aqui dentro? Talvez saiba, para ser honesto
00:17:58você meio que está apenas confiando nas respostas que aparecem, nos links e tal, mas é um
00:18:03pouco difícil analisar as incorporações, com certeza. Tudo isso para dizer que você deve prestar atenção especial
00:18:08ao Obsidian e ao Claude Code, porque quando falamos sobre essa jornada do RAG, eu sempre sugiro
00:18:13a todos, clientes inclusive: vamos começar com o Obsidian e ver até onde conseguimos escalar isso e
00:18:20eventualmente, se atingirmos um limite, você sempre poderá fazer a transição para sistemas RAG mais robustos. Então por que não
00:18:26tentar a opção simples? Se funcionar, ótimo, é de graça, não me custa nada, em vez de tentarmos
00:18:31este sistema RAG, que pode ser um pouco difícil de colocar em produção dependendo do que você está tentando
00:18:35fazer. Sempre comece com as coisas simples, nunca é tão difícil transicionar para algo mais
00:18:40complicado. Então, do que realmente estamos falando aqui no nível quatro? Estamos falando em pegar
00:18:45aquela estrutura que começamos a construir no nível 3, você sabe, com um arquivo de índice apontando para diferentes
00:18:50arquivos markdown, e apenas escalar isso, trazendo então essa ferramenta externa, o Obsidian, para tornar
00:18:56mais fácil para você, o ser humano, realmente ver essas conexões. E o ideal platônico desta versão
00:19:00é basicamente o que Andre Karpathy apresentou ao construir uma base de conhecimento de LLM sobre o Obsidian
00:19:05e alimentada pelo Claude Code, e a aparência disso é uma estrutura como esta. Então, quando você usa o Obsidian
00:19:11e faz o download — é completamente gratuito de novo, veja aquele vídeo que postei antes — você define um
00:19:16determinado arquivo como o "cofre" (vault). Pense no vault como uma espécie de sistema RAG, este sistema
00:19:23quase-RAG que você criou, e dentro do vault nós então arquitetamos e estruturamos isso apenas com
00:19:30arquivos. Portanto, temos o arquivo principal chamado vault e dentro desse vault criamos múltiplas
00:19:36subpastas. No caso do Andre Karpathy, ele fala sobre três subpastas diferentes. Na realidade,
00:19:41poderiam ser quaisquer subpastas, apenas precisam condizer com o tema. Vamos falar sobre isso: em uma
00:19:47pasta temos os dados brutos. Isso é tudo o que estamos ingerindo e que eventualmente queremos estruturar para
00:19:52que o Claude Code possa referenciar depois. Imagine que você peça ao Claude Code para fazer análise competitiva de
00:19:5850 de seus concorrentes e ele puxe 50 sites para cada, certo? Estamos falando de uma grande quantidade de
00:20:03informação, provavelmente 2.500 coisas diferentes, tudo isso será despejado em algum tipo de pasta bruta.
00:20:08Esta é como a área de triagem para os dados. Temos então a pasta wiki. A pasta wiki é onde os
00:20:14dados estruturados vão. Então fazemos o Claude Code pegar esses dados brutos e estruturá-los essencialmente
00:20:20em diferentes tipos de artigos estilo Wikipédia dentro da pasta wiki. Cada artigo ganha sua própria pasta,
00:20:28então a ideia é que quando você pedir ao Claude Code informações sobre, você sabe, digamos que tivéssemos
00:20:33feito ele buscar coisas sobre agentes de IA e eu diga "ei Claude Code, fale comigo sobre agentes de IA", da mesma
00:20:38forma que você consultaria um sistema RAG, bem, o Claude Code irá ao vault; do vault ele irá
00:20:45para a wiki. A wiki tem um arquivo markdown de índice mestre. Pense no tipo de coisa que estávamos
00:20:50fazendo e comentamos sobre fazer com o claud.md antes, certo? Você vê como esses temas fazem a transição
00:20:56pelos diferentes níveis. Ele dá uma olhada naquele índice mestre, o índice mestre diz a ele o que
00:21:00existe no sistema RAG do Obsidian. "Ah, agentes de IA existem, legal". Adivinha o que está acontecendo aqui embaixo? Ele também
00:21:08tem um arquivo de índice que fala sobre os artigos individuais que existem. O que estou dizendo aqui? Estou
00:21:14dizendo que há uma hierarquia clara para o Claude Code referenciar quando quiser encontrar informações sobre
00:21:21arquivos: vault, wiki, índice, artigo, etc. Portanto, por ser tão claro como encontrar informações, e também
00:21:31tão claro como primeiro encontrar a informação e transformá-la em wiki, podemos criar um sistema que tenha muitos
00:21:37documentos sem RAG — centenas, milhares, se você fizer isso corretamente. Porque se o sistema for claro, "ei,
00:21:44eu verifico o vault e verifico o índice e isso tem uma delineação clara de onde tudo está", bem,
00:21:50então não é tão difícil para o Claude Code descobrir onde encontrar as coisas. E assim você consegue se virar com uma
00:21:54estrutura não-RAG para milhares de documentos, e tem sido muito difícil fazer isso no passado.
00:21:58E isso é porque a maioria das pessoas não estrutura nada com nenhum tipo de ordem; elas apenas têm um bilhão de
00:22:02documentos jogados em uma pasta. É o equivalente a ter 10 milhões de arquivos espalhados pelo chão da fábrica.
00:22:08Quero dizer, tipo, o Claude Code vai encontrar? Não. Você na verdade só precisa de um armário de arquivos; o
00:22:13Claude Code é, na verdade, bem inteligente. E você pode ver essa arquitetura em ação bem aqui. Então, agora
00:22:17estamos olhando para um arquivo claud.md que está em um vault do Obsidian, e o que ele diz? Bem,
00:22:24detalha a estrutura do vault, o sistema de wiki, você sabe, a estrutura geral das subpastas e como
00:22:30essencialmente operá-lo, certo? Então, novamente, estamos usando claud.md como um arquivo de convenções aqui. À esquerda,
00:22:36você pode ver a pasta wiki. Dentro da pasta wiki há um índice mestre que lista o que está lá dentro,
00:22:43neste caso há apenas um artigo: é sobre agentes gerenciados pelo Claude. Dentro daquela pasta vemos
00:22:49"agentes gerenciados pelo Claude", ele tem sua própria pasta wiki detalhando os artigos internos até você chegar
00:22:55ao artigo propriamente dito. Então, os passos que ele precisa dar são muito claros. Assim, quando eu digo ao Claude Code
00:23:01"fale comigo sobre os agentes gerenciados", temos uma wiki sobre isso. É muito fácil para ele buscar via
00:23:06sua ferramenta grep integrada. Ele me linka o arquivo markdown real e então detalha tudo
00:23:12o que está acontecendo. Agora a questão no nível quatro torna-se realmente uma questão de escala: quantos documentos
00:23:16podemos ter sem que esse tipo de sistema deixe de funcionar? Existe um ponto em que o sistema de Andre
00:23:22Karpathy começa a desmoronar? Onde tipo, "ei, eu entendi, é um caminho muito claro que o Claude
00:23:26Code precisa seguir, ele vai para os índices blá-blá-blá". Isso se sustenta com
00:23:312.000 documentos? 2.500? 3.000? Existe um número claro? A resposta é que não sabemos realmente, e há um
00:23:37número menor porque todos os seus documentos também são diferentes. E em termos de atingir um limite, não é
00:23:43tão simples quanto "bem, o Claude Code está nos dando as respostas erradas, ele tem arquivos demais no
00:23:47sistema Obsidian". Quanto isso está custando em termos de tokens, agora que adicionamos tantos arquivos, e quão
00:23:52rápido ele faz isso? Porque o RAG pode, na verdade, ser infinitamente mais rápido e barato em certas situações.
00:23:59O que estamos vendo aqui é uma comparação entre LLMs textuais, certo? Naquelas barras gigantes, e o
00:24:06RAG textual em termos da quantidade de tokens necessários para obter a resposta correta e a quantidade de tempo
00:24:11levado para obter essa resposta. O que vemos aqui? Vemos que no RAG textual versus LLMs textuais há uma
00:24:18diferença massiva, da ordem de 1.200 vezes. Estou dizendo que o RAG é 1.200 vezes mais barato e 1.200
00:24:25vezes mais rápido do que um LLM textual nestes estudos. Agora, contexto: isso foi feito em 2025, não foi feito com
00:24:33o Claude Code. Esses modelos mudaram significativamente desde então. Estes são apenas LLMs puros, isto
00:24:37não é uma IA de codificação, etc. No entanto, estávamos falando de uma diferença de 1.200 vezes. Então, ao avaliar
00:24:48se o Obsidian é o que eu deveria estar fazendo versus se eu deveria estar fazendo um sistema RAG, não é tão simples quanto
00:24:54apenas "bem, ele está dando a resposta certa ou não", porque você poderia ter um cenário
00:24:59onde obtém a resposta certa com o Obsidian e, no entanto, se fosse para o RAG, seria mil vezes mais barato
00:25:04e rápido, certo? Então é essa linha muito tênue entre quando o Obsidian é bom o suficiente e essas
00:25:10arquiteturas simples de arquivos markdown são boas o suficiente, ou quando precisamos usar RAG.
00:25:15Não há uma resposta pronta, eu não tenho uma resposta definitiva para você. A resposta é que você tem que experimentar
00:25:18e tentar ambos para ver o que funciona, porque isso está francamente desatualizado, tipo 2025, modelos antigos.
00:25:25A diferença entre RAG e LLMs textuais não é de 1.200 vezes, mas quanto essa lacuna diminuiu?
00:25:32Porque essa é uma lacuna insana, não é tipo 10 vezes, são 1.200 vezes. Então há muito que você precisa saber e,
00:25:39novamente, você não saberá a resposta de antemão, simplesmente não saberá. Assista a todos os vídeos que quiser,
00:25:45ninguém vai lhe dizer onde está essa linha divisória. Você literalmente só precisa experimentar
00:25:49e ver o que funciona para você à medida que aumenta a quantidade de documentos sobre os quais está pedindo ao Claude Code
00:25:54para responder perguntas. Então, nesse sentido, vamos passar para o nível cinco, que é onde finalmente
00:25:59começamos a falar sobre sistemas RAG reais e falamos sobre alguns fundamentos de RAG como embeddings,
00:26:04bancos de dados vetoriais e como os dados realmente fluem através de um sistema quando se tornam parte da nossa
00:26:10base de conhecimento RAG. Então, vamos começar falando sobre o RAG ingênuo (naive RAG), que é o tipo mais básico de RAG
00:26:16existente, mas ele fornece a base para tudo o mais que fazemos. Agora, você pode pensar nos sistemas RAG
00:26:21como sendo divididos em três partes. No lado esquerdo, temos a etapa de embedding, então
00:26:27temos o banco de dados vetorial e depois temos a recuperação (retrieval) real acontecendo com o modelo de linguagem
00:26:33grande. Um, dois e três. E para melhor ilustrar este modelo, vamos começar com a jornada de
00:26:40um documento que fará parte da nossa base de conhecimento. Lembre-se, em um grande sistema RAG, poderíamos estar
00:26:45falando de milhares de documentos, e cada documento poderia ter milhares de páginas. Mas neste
00:26:50exemplo, temos um documento de uma página sobre o qual estamos falando. Agora, se quisermos adicionar este documento
00:26:56ao nosso banco de dados, a maneira como funcionará é que ele não será ingerido como uma unidade inteira. Em vez disso,
00:27:03vamos pegar este documento e vamos dividi-lo em pedaços (chunks). Então, este documento de uma página
00:27:08torna-se essencialmente três chunks diferentes. Esses três chunks são então enviados para um modelo de embedding
00:27:15e o trabalho do modelo de embedding é pegar esses três chunks e transformá-los em um vetor
00:27:21em um banco de dados vetorial. Agora, um banco de dados vetorial é apenas uma variação diferente do seu banco de dados padrão.
00:27:27Quando falamos de um banco de dados padrão, pense em algo como um documento de Excel, certo? Você tem
00:27:32colunas e linhas. Bem, em um banco de dados vetorial, não são colunas e linhas bidimensionais, são
00:27:37na verdade centenas, se não milhares de dimensões. Mas para os propósitos de hoje, apenas pense em um
00:27:43gráfico tridimensional como você vê aqui, e os vetores são apenas pontos naquele gráfico, e cada
00:27:50ponto é representado por uma série de números. Então você pode ver aqui que temos bananas, e bananas é
00:27:57representada por 0,52, 5,12 e depois 9,31. Você vê isso aqui em cima. Agora, isso continua por centenas de números.
00:28:06Onde cada vetor é colocado neste gráfico multidimensional gigante depende do seu significado
00:28:13semântico. O que as palavras realmente significam? Então você pode ver aqui, esta é como a seção de
00:28:19frutas: temos bananas, maçãs, peras. Aqui temos navios e barcos.
00:28:24Então, voltando ao nosso documento, vamos imaginar que este documento é sobre navios da Segunda Guerra Mundial.
00:28:31Assim, cada um desses chunks será transformado em uma série de números e essas séries de números
00:28:37serão representadas como um ponto neste gráfico. Onde você acha que ele vai ficar? Bem, eles provavelmente
00:28:42irão para perto desta área, certo? Então isso seria um, dois e três. É assim que os documentos são colocados. Cada
00:28:49documento será dividido em chunks, cada chunk passa pelo modelo de embedding e o modelo de embedding
00:28:54os insere no banco de dados vetorial. Repita, repita, repita para cada documento. E no final,
00:28:58após fazermos isso milhares de vezes, obtemos um banco de dados vetorial que representa nosso gráfico de conhecimento,
00:29:04por assim dizer, nossa base de conhecimento. E isso nos leva ao passo três, que é a parte da recuperação.
00:29:09Então, onde você entra nisso? Bem, normalmente, vamos descrevê-lo, vamos dar a você uma
00:29:16cor diferente: você pode ser rosa. Então, este é você, tudo bem? Você normalmente apenas fala com o
00:29:23Claude Code e faz perguntas ao Claude Code sobre encouraçados da Segunda Guerra Mundial. Bem, em uma
00:29:29configuração padrão sem RAG, o que vai acontecer? Bem, o modelo de linguagem grande, Opus 4.6, vai dar
00:29:34uma olhada em seus dados de treinamento e então vai lhe dar uma resposta baseada em seus dados de treinamento,
00:29:39informações sobre encouraçados da Segunda Guerra Mundial. Mas com um sistema RAG, ele vai fazer mais: ele vai
00:29:44recuperar os vetores apropriados. Ele vai usar esses vetores para aumentar a resposta que gera
00:29:51para você, daí "Geração Aumentada por Recuperação" (Retrieval Augmented Generation). Esse é o poder do RAG: ele permite que nossos modelos de linguagem
00:29:56grandes tragam informações que não fazem parte de seus dados de treinamento para aumentar sua resposta. Neste
00:30:02exemplo, encouraçados da Segunda Guerra Mundial. Sim, eu entendo que o modelo de linguagem grande já sabe disso, mas
00:30:06substitua isso por qualquer tipo de dado proprietário de empresa que não esteja disponível na web e faça
00:30:15isso em escala. Esse é o argumento de venda do RAG. Agora, em nosso exemplo, quando pedimos ao Claude Code informações
00:30:21sobre encouraçados da Segunda Guerra Mundial e ele está em uma configuração de RAG, o que ele vai fazer é
00:30:25pegar nossa pergunta e transformá-la em uma série de números similar aos
00:30:32vetores aqui. Ele então vai dar uma olhada em qual é o número da nossa pergunta e nos números
00:30:39dos vetores e ver qual desses vetores mais se aproxima do vetor da pergunta,
00:30:46certo? Quão similares são os vetores em relação à pergunta, basicamente. E então ele vai puxar uma certa
00:30:51quantidade de vetores, sejam um, dois, três, quatro, cinco, dez ou vinte, e vai puxar
00:30:56esses vetores e suas informações para dentro do modelo de linguagem grande. Então agora o modelo de linguagem grande tem
00:31:02sua resposta dos dados de treinamento mais, digamos, 10 vetores de informação, certo? Essa foi a parte da recuperação.
00:31:09E então ele aumenta e gera uma resposta com essa informação adicional. E é assim que o RAG
00:31:13funciona. É assim que o RAG ingênuo funciona. Agora, isso não é particularmente eficaz por uma série de razões. Esta
00:31:19estrutura muito básica meio que desmorona no início quando começamos a pensar: ok, como
00:31:25estamos dividindo esses documentos em chunks? É aleatório? É apenas por um número puro de tokens? Temos
00:31:31um certo número de sobreposição? Os documentos em si estão configurados de uma forma que sequer faz
00:31:36sentido dividi-los? Porque e se, sabe, o chunk número três estiver referenciando algo no chunk
00:31:42número um e então, em nossa situação vetorial, quando puxamos os chunks, e se ele não pegar o correto?
00:31:47E se ele não pegar aquele outro chunk que é necessário como contexto para que sequer faça sentido o que o
00:31:53número três diz? Entende o que estou dizendo? Frequentemente, o documento inteiro em si é necessário para responder
00:31:59perguntas sobre tais documentos. Então, essa ideia de obter essas respostas fragmentadas não
00:32:05funciona bem na prática. No entanto, foi assim que o RAG foi configurado por muito, muito tempo. Outros problemas que podem
00:32:10entrar em jogo são coisas como: e se eu tiver perguntas sobre as relações entre diferentes vetores? Porque
00:32:17agora eu meio que só puxo vetores isolados, mas e se eu quisesse saber como barcos se relacionam com
00:32:22bananas? Parece aleatório, mas e se eu quisesse? Sabe, nesta abordagem padrão de banco de dados vetorial de RAG ingênuo,
00:32:31tudo está meio que isolado. É difícil conectar informações e muito disso depende apenas
00:32:36de quão bem aqueles documentos originais estão estruturados. Eles estão estruturados de uma maneira que
00:32:41faça sentido para o RAG? Agora, ao longo dos anos, surgiram algumas maneiras de aliviar esses problemas,
00:32:46coisas como re-rankers ou sistemas de classificação que analisam todos os vetores que pegamos e, essencialmente,
00:32:51fazem outra passagem neles com um modelo de linguagem grande para classificá-los em termos de sua relevância. Mas,
00:32:56em geral, este sistema de RAG ingênuo meio que caiu em desuso. No entanto, ainda é importante
00:33:03entender como isso funciona em um nível fundamental para que possa informar suas decisões se você optar por uma
00:33:07abordagem de RAG mais robusta. Porque se você não entende como o chunking ou os embeddings sequer funcionam,
00:33:13como pode tomar decisões sobre como deve estruturar seus documentos? Quando falamos sobre
00:33:17algo como graph RAG ou falamos sobre sistemas de embedding mais complicados, como o novíssimo
00:33:22do Google que pode ingerir não apenas texto, mas vídeos. E se você não entende
00:33:27esse tipo de fundamento, é difícil para você realmente entender esta armadilha. E a armadilha é que
00:33:31meio que acabamos de criar um mecanismo de busca medíocre. Porque com esses sistemas de RAG ingênuo onde tudo o que
00:33:36fazemos é pegar chunks e não conseguimos realmente entender as relações entre eles, como isso é diferente
00:33:42de basicamente ter apenas um sistema de "Ctrl+F" supercomplicado? A resposta é que realmente não
00:33:48há muita diferença. É por isso que nestas estruturas de RAG simplistas e meio ultrapassadas que, na verdade, ainda estão em todo lugar —
00:33:54se você vir alguém dizendo "ah, aqui está meu sistema RAG Pinecone" ou "aqui está meu sistema RAG Supabase" e eles não mencionam nada sobre graph RAG
00:33:58ou não mencionam nada como "ei, aqui está como temos um sistema sofisticado de re-ranker",
00:34:03então vai ser ruim, a ponto de, tipo, a eficácia real disso ser de
00:34:0725% das vezes você acertar algo. Você quase se sai melhor chutando. Então, se você não souber disso
00:34:12ao entrar, você pode definitivamente ser enganado ou confundido ou, em alguns casos, basicamente cair em um golpe
00:34:18ao comprar esses sistemas RAG que não fazem sentido. Então o nível cinco não é sobre implementar
00:34:23esses tipos de sistemas RAG ingênuos; é sobre entender como eles funcionam para que você,
00:34:28quando chegar a hora de implementar algo mais sofisticado, realmente entenda o que está acontecendo. Porque
00:34:34essa explicação de cinco minutos de RAG infelizmente não é algo que a maioria das pessoas entende quando dizem:
00:34:38"eu preciso de um sistema RAG". Bem, você precisa? Porque você também tem que se perguntar que tipo de perguntas você
00:34:43está realmente fazendo ao seu sistema. Se você está apenas perguntando, sabe, essencialmente tratando sua base de conhecimento
00:34:48como um livro de regras gigante e você só precisa que coisas específicas desse sistema de conhecimento
00:34:54sejam trazidas, bem, então o Obsidian provavelmente é suficiente ou você poderia até se virar com um
00:34:59sistema RAG ingênuo. Mas se precisamos saber sobre relações, se precisamos saber como X interage com Y e
00:35:02eles são dois documentos separados, eles nunca sequer se mencionam realmente, e não é algo
00:35:09que eu possa simplesmente colocar dentro do contexto diretamente porque tenho milhares desses documentos, bem, é
00:35:13aí que você vai precisar de RAG e é aí que você vai precisar de algo mais sofisticado
00:35:19do que o RAG vetorial básico. É quando precisamos começar a falar sobre graph RAG. Então, quando falamos sobre o nível
00:35:23seis de Claude Code e RAG, estamos falando de graph RAG e estamos falando disto. E na minha
00:35:29opinião, se você vai usar RAG, este é o nível mínimo de infraestrutura que você precisa
00:35:34criar. Isto é usando o LightRAG, que é uma ferramenta completamente de código aberto. Colocarei um link acima onde eu
00:35:39detalho exatamente como usá-lo e como construí-lo. Mas a ideia do graph RAG é bem óbvia: é
00:35:44a ideia de que tudo está conectado. Isto não é um banco de dados vetorial com um monte de vetores isolados,
00:35:50isto é um monte de coisas conectadas umas às outras, certo? Eu clico neste documento, posso ver aqui
00:35:55à direita — e vou mover isso — sabe, a descrição do vetor, o nome, o tipo, o
00:36:00arquivo, o chunk e, mais importante, as diferentes relações. E esta abordagem
00:36:05baseada em relações resulta em resultados mais eficazes. Aqui está um gráfico do GitHub do LightRAG. Isso tem
00:36:10cerca de seis a oito meses de idade e também vale notar que o LightRAG é o sistema de graph RAG mais leve
00:36:15que eu conheço. Existem algumas versões muito robustas, incluindo o próprio GraphRAG da
00:36:23Microsoft. É um gráfico, literalmente se chama GraphRAG. Mas quando comparamos o RAG ingênuo com o LightRAG,
00:36:30em todos os aspectos obtemos saltos de muitas vezes mais de 100 por cento, certo? 31,6 versus 68,4;
00:36:3524 versus 76; 24 versus 75 e assim por diante. E dito isso, de acordo com o LightRAG, ele
00:36:4324 contra 75 e por aí vai. E dito isto, de acordo com o LightRAG,
00:36:49ele se mantém firme e supera o próprio GraphRAG. Mas ei, estes são números do LightRAG,
00:36:54então considere com cautela. Agora, quando olhamos para este sistema de grafo de conhecimento,
00:36:58sua mente provavelmente vai para o Obsidian porque parece muito semelhante. No entanto,
00:37:04o que estamos vendo aqui no Obsidian é muito mais rudimentar do que o que ocorre
00:37:10dentro do LightRAG ou de qualquer sistema GraphRAG, porque esta série de conexões que vemos aqui
00:37:16é toda manual e um tanto arbitrária. Só está conectado porque definimos documentos relacionados
00:37:22ou o Claude Code definiu quando gerou este documento específico. Por exemplo, apenas adicionou
00:37:27alguns colchetes e pronto, o documento está conectado. Então, em teoria, eu poderia conectar
00:37:30vários documentos aleatórios que na realidade não têm nada a ver um com o outro. Agora,
00:37:35como o Claude Code não é burro, não fará isso, mas é muito diferente do que aconteceu aqui.
00:37:41Isso passou por um sistema de embedding real, analisou o conteúdo real, definiu uma relação,
00:37:46enviou uma entidade. Há muito mais trabalho acontecendo aqui no LightRAG em termos de
00:37:52definir as relações do que no Obsidian agora. Será que essa diferença realmente equivale
00:38:02a um abismo enorme em termos de desempenho? Em nível baixo, talvez em uma escala imensa.
00:38:07Novamente, estamos nessa zona cinzenta, depende da sua escala e do que estamos falando,
00:38:13e ninguém pode responder isso exceto você com experiência pessoal. Mas entenda que
00:38:20estas duas coisas não são iguais. São dois sistemas totalmente diferentes: um é sofisticado,
00:38:26outro é rudimentar. Entenda isso. E para encerrar o nível 6 no GraphRAG,
00:38:31chegamos aqui quando decidimos que o Obsidian não está funcionando, que o RAG ingênuo
00:38:36não serve e precisamos de algo que extraia entidades e relações, alavancando
00:38:43esse design de sistema de consulta híbrido de vetor e grafo. Mas há algumas armadilhas,
00:38:48obstáculos sérios até aqui no nível 6. No LightRAG, isso é apenas texto. E se eu tiver
00:38:55PDFs escaneáveis? E vídeos? E imagens? Não vivemos em um mundo onde todos
00:39:01os seus documentos serão apenas Google Docs. Então, o que fazemos nesses casos?
00:39:06A recuperação multimodal é algo enorme e, além disso, que tal trazer qualidades
00:39:11mais agentais para esses sistemas? Dar um pouco mais de poder de IA? Bem,
00:39:17se falamos de coisas multimodais, podemos finalmente passar para o que há de mais moderno
00:39:24em RAG hoje em dia, em abril de 2026. É disso que se trata o nível 7.
00:39:31No nível 7 e RAG agental, o foco principal que queremos dar aqui são as coisas
00:39:36relacionadas à ingestão multimodal. Já fizemos vídeos sobre isso, como o "RAG Anything",
00:39:44que nos permite importar imagens e documentos que não são de texto, como PDFs escaneáveis,
00:39:49para estruturas como o grafo de conhecimento do LightRAG que você viu. Também temos
00:39:56novos lançamentos como o Gemini Embedding 2, de março, que permite fazer o embedding
00:40:01de vídeos diretamente no banco de dados vetorial. Vídeos em si. E é para lá que
00:40:06o espaço está indo. Não basta apenas documentos de texto. Quanta informação e conhecimento
00:40:10estão presos na internet, especialmente no YouTube, que é puramente vídeo? E queremos
00:40:16mais do que apenas uma transcrição; ela não é suficiente. Esse problema multimodal é real e,
00:40:20de novo, isso saiu há apenas algumas semanas. O nível 7 também é onde precisamos
00:40:25prestar atenção na nossa arquitetura e pipelines de dados entrando e saindo do sistema.
00:40:30Não basta apenas colocar os dados. Como eles chegam lá no contexto de uma equipe?
00:40:35Como os dados saem? E se alguma informação mudou em um documento específico?
00:40:40E se alguém o editar? Como ele é atualizado? E se adicionarmos duplicatas? Quem pode
00:40:46colocar essas coisas lá? Em nível de produção, estas são perguntas que você deve se fazer.
00:40:50Então, ao olhar para um sistema de RAG agental como este do n8n, você vê que
00:40:54a grande maioria da infraestrutura é focada em ingestão e sincronização de dados.
00:41:01Há apenas uma pequena parte que tem a ver com o RAG propriamente dito, porque
00:41:06precisamos de sistemas que limpem os dados, capazes de notar: "ok, acabamos de ingerir isto,
00:41:11era a versão 2 da versão 1, podemos voltar e limpar?". Aqui está um pipeline
00:41:17de ingestão onde os documentos não vão direto para o sistema ou para o LightRAG.”
00:41:21Em vez disso, colocamos no Google Drive e, de lá, ele é ingerido no sistema GraphRAG
00:41:27e registrado. Esse tipo de coisa é o que vai definir o sucesso do seu sistema RAG
00:41:31quando usado de verdade. E quando falamos de RAG agental, você pode ver aqui,
00:41:37embora esteja meio embaçado: se temos um agente de IA rodando todo o programa,
00:41:42imagine um chatbot para sua equipe, ele precisa sempre acessar esse banco de dados?
00:41:49A resposta provavelmente é não. Em um cenário de equipe ou empresa, você terá
00:41:54informações em um banco de dados como este, tipo texto, mas provavelmente terá
00:41:58outro conjunto de bancos de dados, como o Postgres padrão, para consultar via SQL.
00:42:03Em um sistema RAG agental, precisamos da habilidade de decidir inteligentemente:
00:42:08"Vou acessar o banco de dados GraphRAG representado aqui ou apenas farei consultas SQL
00:42:15no Postgres?". Isso pode ficar complicado, e tudo depende do caso de uso, por isso
00:42:20às vezes é difícil fazer esses vídeos e tentar cobrir cada detalhe.
00:42:23O ponto aqui no nível 7 não é que exista um "super sistema RAG" desconhecido,
00:42:30mas sim que o segredo está nos detalhes, principalmente na ingestão de dados
00:42:34e em mantê-los atualizados. Além disso, como você realmente acessa isso?
00:42:39É fácil em uma demonstração: "ah, vamos ao LightRAG, vamos em recuperação e perguntamos".
00:42:46É um cenário diferente com uma equipe, onde todos abordam de ângulos distintos
00:42:50e você provavelmente não quer que todos tenham acesso direto ao upload no LightRAG
00:42:55através de um web app. Dito isso, para o operador individual que busca um sistema
00:43:01sofisticado capaz de lidar com multimodalidade, sugiro a combinação RAG Anything + LightRAG.
00:43:07Já fiz um vídeo sobre isso e vou deixar o link. Recomendo por alguns motivos:
00:43:14primeiro, é código aberto e leve, então você não gasta muito dinheiro ou tempo
00:43:19configurando algo assim para ver se faz sentido para o seu caso de uso.
00:43:26Novamente, o que queremos é não ficar presos em sistemas sem saída após gastar
00:43:31muito dinheiro, por isso amo o Obsidian e recomendo coisas como LightRAG e RAG Anything.
00:43:37Porque, se você tentar e não funcionar, tudo bem, você perdeu apenas algumas horas,
00:43:42não gastou uma fortuna no GraphRAG da Microsoft, que não é nada barato.
00:43:45E quando você sabe que está no nível 7? Realmente quando há coisas multimodais,
00:43:50como indexar imagens, tabelas e vídeos, e integrar um sistema de agentes
00:43:56que decida inteligentemente qual caminho seguir para responder. No nível 7,
00:44:02você provavelmente está integrando tudo: talvez um arquivo .md do Claude,
00:44:06arquivos Markdown no código para recuperação fácil, talvez inclua o Obsidian
00:44:12em algum vault, além de documentos em um banco de dados GraphRAG, com um sistema
00:44:16de IA no topo do funil que decide a rota. Essa é uma arquitetura de memória madura
00:44:20que eu sugeriria. Mas qual é a armadilha aqui? Sinceramente, é tentar se forçar
00:44:25a este nível de sofisticação quando não é necessário. Para ser honesto,
00:44:33a maioria de vocês ficará bem com o Obsidian; é mais do que suficiente.
00:44:40Você não precisa de GraphRAG, não precisa de RAG em geral, e se não for óbvio
00:44:47que você precisa do nível 7, ou se ainda não tentou a rota do Obsidian,
00:44:52não precisa estar aqui. Provavelmente é perda de tempo. Mas o objetivo do vídeo
00:44:57foi expor o que vejo como os diferentes níveis de RAG, memória e Claude Code,
00:45:01os problemas, as tensões e trocas, para que você saiba onde se situar.
00:45:07E, de novo, o mais importante é experimentar. Você não precisa ter a resposta
00:45:12antes de começar, apenas tente. Eu tentaria em ordem ascendente. Se você
00:45:18conseguir resolver com arquivos Markdown em um sistema Claude, ótimo, siga em frente.
00:45:24Depois tente o Obsidian; se não for suficiente, tente o LightRAG e assim por diante.
00:45:28Então, vou deixar vocês por aqui hoje. Se quiserem aprender mais sobre
00:45:34o lado de produção do RAG, como configurar para uma equipe ou para um cliente,
00:45:39temos um módulo inteiro sobre isso no Chase AI Plus, então confiram.
00:45:43Fora isso, digam o que acharam. Eu sei que este vídeo foi longo,
00:45:47e nos vemos por aí.