Pare de usar fine-tuning para corrigir problemas de recuperação — Anant Srivastava

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

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

Idioma original: inglês

Vídeo original: Stop Fine-Tuning to Fix Retrieval Problems — Anant Srivastava · Canal: AI Engineer · 19:34 · Assistir no YouTube

Tópicos: Agentes de IA, Infraestrutura e hardware de IA, Modelos de IA, RAG, busca e recuperação de informação

Resumo

Anant Srivastava argumenta que equipes de IA empresarial muitas vezes decidem por acidente onde armazenar conhecimento e instruções. Ele propõe distinguir três funções: prompt para comportamento, memória para conhecimento atual, amplo e citável, e pesos do modelo para padrões estáveis de como responder ou raciocinar. Quando uma resposta está errada por falta de documentos relevantes, a solução é corrigir a recuperação, não fazer fine-tuning com esses documentos. Com o tempo, memória e pesos podem alimentar um ciclo de melhoria, desde que haja monitoramento e um harness adequado.

Pontos-chave

• Prompt, memória e pesos são ferramentas diferentes para funções diferentes, não etapas de uma escala de evolução.
• O prompt deve conter instruções pequenas e estáveis sobre comportamento, tom e persona, não catálogos ou grandes conjuntos de fatos.
• A memória serve para conhecimento amplo, atualizado com frequência e que precisa ter fontes citáveis ou controle de acesso.
• Para recuperar código, é importante usar divisão em trechos adequada ao código, filtros e metadados como repo e permissões.
• Se o modelo não responde corretamente por não receber os trechos certos, deve-se corrigir a recuperação em vez de fazer fine-tuning com documentação.
• Os pesos são mais adequados para padrões estáveis, como reflexos ou formatos que humanos passaram a aplicar de maneira consistente.
• Fine-tuning pode ser considerado para melhorar capacidade ou reduzir custos, mas requer monitoramento de mudanças e drift.
• Um sistema pode formar um ciclo em que informações passam da memória para o prompt e, quando padrões se estabilizam, da memória para os pesos.

Capítulos

Início	Capítulo	Resumo
00:01	A decisão arquitetural sobre onde o conhecimento vive	A palestra apresenta prompt, memória e adaptação do modelo como ferramentas distintas e explica como decisões cotidianas podem resultar numa arquitetura acidental.
04:46	Prompt: comportamento, não armazenamento de fatos	O prompt é indicado para instruções pequenas e estáveis sobre tom, persona e comportamento, e não para armazenar catálogos ou conhecimento extenso.
06:53	Memória: conhecimento atual, amplo e controlado	A memória abrange tanto conhecimento do agent quanto fontes externas, e deve atender a necessidades de atualização, citação e controle de acesso.
11:05	Pesos e o uso apropriado de fine-tuning	Os pesos são apresentados como lugar para padrões que se estabilizaram; documentos desatualizados ou recuperação ruim não se corrigem simplesmente com fine-tuning.
13:46	Padrões estáveis, custo e monitoramento	A palestra descreve como padrões humanos consistentes podem orientar fine-tuning e recomenda monitorar drift e distinguir objetivos de capacidade e custo.
16:56	Um ciclo entre prompt, memória e pesos	O palestrante resume a função de cada camada e descreve como informações podem circular entre memória, prompt e pesos ao longo do uso do agent.

Citações

Estas são três ferramentas diferentes para três trabalhos diferentes. — 01:04

A função do prompt é comportamento, tom e persona do agent. — 05:18

Em vez de corrigir o problema de recuperação, a equipe fez fine-tuning do modelo. — 13:12

O agent melhora no trabalho ao longo do tempo por realizar esse trabalho. — 19:01

O modelo é a parte fácil. O harness ao redor do modelo é a principal arquitetura que você precisa construir. — 19:34

Conceitos e entidades

• Anant Srivastava (pessoa): Palestrante que apresenta um método para decidir onde armazenar instruções, conhecimento e padrões de comportamento em sistemas de IA.
• prompt (conceito): Camada indicada para instruções estáveis sobre comportamento, tom e persona do agent.
• memory (conceito): Camada que fornece conhecimento amplo, atualizável, citável e, quando necessário, sujeito a controle de acesso.
• weights (conceito): Parâmetros do modelo nos quais podem ser incorporados padrões estáveis que o modelo deve aplicar reflexivamente.
• fine-tuning (conceito): Adaptação do modelo que, segundo a palestra, pode ser útil para padrões estáveis, mas não deve substituir a correção de problemas de recuperação.
• RAG (conceito): Abordagem de recuperação usada para fornecer ao modelo conhecimento externo, como políticas ou conteúdo de repositórios.
• code-aware chunking (conceito): Divisão de código em trechos que leva em conta sua estrutura para melhorar a recuperação de informações relevantes.
• ICD-10 (conceito): Sistema de códigos mencionado como exemplo de conhecimento que não deve ser confundido com padrões de formato que podem ser aprendidos pelo modelo.
• Harness (conceito): Estrutura construída ao redor do modelo para armazenar informações nos lugares adequados e fazê-las circular entre as camadas.

Tradução completa (pt-BR)

00:01 [música] Como decidir o que colocar em cada lugar? Para a maioria dos sistemas de IA corporativos, o problema interessante de engenharia não é o próprio modelo. O modelo consome tokens e produz tokens. Seu conhecimento está em arquivos,

00:33 bancos de dados e APIs. A principal decisão de arquitetura é como esse conhecimento chega à inference: pelo prompt ou pelo contexto, pela camada de retrieval ou de memória, ou por adaptações do modelo, como fine-tuning. Hoje, vou argumentar que a maioria das equipes corporativas toma essa decisão por acidente.

01:04 E o caminho para passar a fazer isso de propósito é reconhecer que não se trata de uma escada que você sobe. São três ferramentas diferentes para três tarefas diferentes. Então, como isso acontece por acidente? Bem, há dois mecanismos. Um é óbvio. O outro, nem tanto. O mecanismo óbvio é a escalada das equipes. Você não obtém a resposta certa do seu

01:34 modelo. O mais fácil é colocar algo no prompt, tipo: “Vá corrigir o prompt”. Ainda está errado? Talvez haja algo de errado com o sistema de memória ou o sistema de retrieval. Vamos dar uma olhada nisso. Mesmo assim, se a resposta continuar errada, bom, sabe de uma coisa? Vamos fazer fine-tuning do modelo. Isso não acontece com muita frequência, mas, sim, às vezes as equipes recorrem ao fine-tuning do modelo. Há uma camada abaixo disso. As equipes que não estão escalando ainda assim estão

02:06 tomando essas decisões todos os dias. Cada edição que você faz no prompt determina qual comportamento fica no prompt. Cada documento que você indexa determina qual conhecimento fica armazenado na memória. E cada exemplo de treinamento que você incorpora — cada exemplo de treinamento que você identifica — vai incorporar algo aos pesos.

02:38 Tudo isso são decisões de arquitetura. Nenhuma delas é como… Certo, vou deixar isso um pouco mais concreto para vocês. Já vi isso acontecer. Um assistente interno de suporte acaba de ser lançado. Em poucas semanas, o gerente de produto faz algumas alterações no prompt para corrigir o tom do assistente de suporte. Depois de algumas semanas, a equipe de suporte adiciona documentos sobre a política de reembolso ao sistema de retrieval ou de memória. Vou falar

03:10 sobre retrieval e memória. Estou ensinando isso. Estou tratando tudo como memória, mas já vou chegar a essa distinção. E então, como o seu modelo — o seu agent — não está dando as respostas certas, um engenheiro enfia o catálogo de produtos no prompt. Depois de algumas semanas, a equipe de machine learning decide treinar o modelo, ou fazer fine-tuning dele, com tickets de suporte de até seis meses atrás.

03:43 Todas as decisões parecem boas, exceto uma, aliás. Mas até eu já tomei decisões assim ao longo da minha trajetória. Já fiz coisas desse tipo sem pensar muito a respeito. Então, quando o novo catálogo de produtos é lançado, parece fácil, certo? “Ah, o engenheiro enfiou o catálogo de produtos no prompt. Vamos colocar o novo catálogo de produtos lá.” E você pensaria que tudo está funcionando bem, mas o seu

04:15 modelo ou o seu agent ainda está dando nomes de produtos que nem sequer existem. Como isso aconteceu? Bem, o catálogo de produtos vazou para os pesos quando você fez fine-tuning com seus tickets de suporte. E esse é o acidente. Sua arquitetura foi se acumulando. Ela não foi projetada. Esse é o acidente. É o que seis meses de trabalho normal com o produto

04:46 levaram a acontecer. Ninguém era responsável por isso. Ou seja, todo mundo era responsável por uma parte. Certo. Ninguém fez a pergunta de diagnóstico. Ninguém perguntou onde essa coisa deveria ficar. Essas perguntas de diagnóstico são a lente sobre a qual vamos falar, e o restante da palestra é sobre essa lente. Certo. Então, a primeira parte é o prompt. Qual é o

05:18 papel do prompt? O papel do prompt é definir o comportamento, o tom e a persona do agent. Coisas pequenas, estáveis e editáveis. O papel errado para o prompt é armazenar fatos. Você não coloca o catálogo de produtos no prompt porque, assim, fornece contexto desnecessário ao modelo e paga por isso. E, quando há tokens demais, você se depara com o problema de lost in the middle.

05:49 O diagnóstico para o prompt é: o conhecimento é pequeno, estável e diz respeito a como se comportar, em vez de ao que saber? Um exemplo concreto de bom uso do prompt é um agent de suporte ao cliente para um produto SaaS. No momento, esse agent tem um tom profissional. Ele

06:21 oferece encaminhamento para um atendente humano depois de três tentativas malsucedidas e fornece próximos passos concretos. Nada disso muda a cada consulta ou a cada usuário. É exatamente isso que deve ficar no prompt. E mais uma coisa: quando digo prompt, não estou falando apenas de system prompt. Estou falando de instruções escritas para o seu modelo. Elas também podem vir de arquivos MD ou de outras coisas, certo? Mas é isso que quero dizer

06:53 com prompt aqui. O segundo caminho é a memória. O papel da memória é fundamentar seu modelo ou agent em conhecimento atual, abrangente e que possa ser citado. Atual significa que muda mais rápido do que você consegue fazer fine-tuning. Muda de tempos em tempos. Abrangente porque não pode ser armazenado em nenhum lugar. Não pode ficar no seu

07:24 prompt. E que possa ser citado porque os sistemas de IA em produção precisam conseguir apontar para a fonte do conhecimento. É isso que deve ficar na memória. Quando uso o termo memória, as pessoas pensam na memória do agent: o conhecimento adquirido sobre as pessoas — sobre uma pessoa que está interagindo com o agent. O que também estou incluindo aqui é a memória externa, que você consulta usando RAG e coisas do tipo, como as políticas de reembolso.

07:55 Certo? Ela não é gerenciada pelo seu agent; é gerenciada por um aplicativo externo, que também está incluído aqui. Então, estou falando tanto da memória do agent quanto da memória mais ampla da empresa. Certo. O papel errado da memória é inserir comportamentos nela ou usá-la para definir como raciocinar. Claro, você pode ter uma espécie de RAG gráfico que ajude o agent a raciocinar, mas

08:27 é só isso. Aí é onde você para. Para raciocinar, você precisa do modelo certo. Se o seu modelo não consegue raciocinar sobre dois, três ou cinco documentos, não vai conseguir raciocinar sobre 50 documentos que você fornecer. Mais contexto não ajuda se ele não consegue raciocinar. Então, o diagnóstico, ou a pergunta que você precisa fazer, é: o conhecimento é grande demais para caber e muda mais rápido do que consigo fazer o retreinamento? Outro aspecto importante é se há algum controle de acesso, se o escopo é definido por usuário.

08:57 Você precisa ter isso na memória. Se houver algum tipo de controle de acesso que impeça este usuário de ver as informações, os dados ou qualquer outra coisa de outra pessoa, você precisa manter esse conhecimento na memória, porque assim pode controlar quem vê o quê. Um bom exemplo de algo a armazenar na memória externa, ou na memória, é um assistente de código que tem acesso a todos os repositórios da sua organização.

09:33 Então, você faria fine-tuning do modelo para ele aprender o código? Não. É simples, certo? O código muda com muita frequência. Você não faria isso. Normalmente, faria fine-tuning do modelo para aprender reflexos, não fatos. E colocaria isso no prompt? Não, você não coloca essas coisas no prompt. Pode colocar ou adicionar certas coisas que sejam importantes no context window, certo? Isso é diferente. Mas você não colocaria toda a base de código no prompt, certo? Nem mesmo uma parte dela, se não houver utilidade

10:04 ali. Outra coisa importante é que, ao criar um sistema de RAG para o seu código, você precisa garantir que está dividindo o conteúdo em chunks corretamente, usando uma divisão em chunks que leve em conta o código, talvez com… E outra coisa importante é usar filtros. Você deve desnormalizar. Talvez deva desnormalizar informações como qual é o repositório ao qual esse código pertence. Você obtém um chunk de código.

10:34 Você precisa criar metadados sobre a qual repositório ele pertence, quem é o usuário, quais usuários têm permissão para fazer commit e tudo mais, porque isso vai ajudar você a obter os dados exatos de que precisa, em vez de criar uma mistura de RAG em que você retorna muitos chunks do banco de dados sem critério e acaba confundindo o modelo. Então, de novo, o diagnóstico é: é algo grande demais para caber e muda mais rápido do que você consegue retreinar o modelo?

11:05 e tem um escopo em determinado nível. Pode ser um usuário, um repo ou qualquer outra coisa. Todo esse conhecimento pertence à memória. Pode ser uma memória externa, como o banco de dados da sua aplicação, ou também pode ser a memória do seu agent. Agora, vamos à parte mais interessante: os pesos. Então, o que pertence aos pesos?

11:36 Algo que parou de mudar. Isso é o que pertence aos pesos. E o único eixo que orienta este slide é a taxa de mudança. Você pode fixar o que parou de mudar e talvez treinar de novo. E não estou dizendo para simplesmente fixar o que parou de mudar e ir treinar o modelo de novo. Não, não é isso que você faz o tempo todo. Você precisa ter um motivo muito forte para treinar o modelo de novo. Então, o que você faz é fixar o que está mudando e seguir a partir daí. Mas, se errar, pode congelar um

12:08 limite que ainda está se movendo. Certo? E não é algo tão sutil quanto, tipo: “Ei, eu faria de novo…?” Ninguém vai treinar o modelo de novo com uma lista de preços — ou fazer fine-tuning, quis dizer, não treinar de novo, desculpe, fazer fine-tuning no modelo com uma lista de preços. Ninguém faz isso. É algo mais sutil do que isso, certo? E um exemplo atual disso é: digamos que exista um assistente interno de documentos e que a equipe de suporte, ou a sua equipe, decida fazer fine-tuning

12:40 no modelo porque ele não está dando as respostas certas. Para ensiná-lo sobre o domínio, a equipe diz: “Sabe de uma coisa? Vamos fazer fine-tuning neste modelo com a nossa documentação. Vamos fazer fine-tuning no modelo com…” Ou talvez não com toda a documentação, mas com os runbooks e procedimentos. E o que acontece? Há um problema. Se você fizer isso, o modelo vai fornecer informações desatualizadas. Na verdade, isso era um problema de recuperação. Se o modelo não estava dando a resposta certa,

13:12 o que o modelo precisava eram dos trechos certos, das partes certas da documentação. Então, em vez de corrigir o problema de recuperação, a equipe acabou fazendo fine-tuning no modelo. Não é isso que você deve fazer. Runbooks e procedimentos são fatos. Eles pertencem à memória do agente — não a essa, mas, claro, à sua memória externa. É lá que essas coisas devem ficar. Não… Se o modelo não está… >> Boa tarde. Olá. >> Ah, desculpe, eu estava pensando: quem é?

13:46 Então, se o seu modelo não está dando as respostas certas, corrija o problema de recuperação. Não saia simplesmente fazendo fine-tuning no modelo. Certo. E, se invertermos isso, continuamos com o mesmo eixo. Se invertermos a situação, um bom caso de uso para fazer fine-tuning seria, digamos, um problema difícil e ambíguo, como moderação de conteúdo ou processamento de solicitações de indenização. Certo? No início, você pode usar um modelo de fronteira que faz recomendações, e os humanos as corrigem

14:16 de forma inconsistente. Com o tempo, padrões vão surgir. Padrões vão surgir, e você terá uma espécie de núcleo que é relativamente fixo e estável. Certo? E então terá a fronteira contestada. A taxa de intervenções humanas vai se estabilizar depois de certo ponto, e provavelmente surgirá um padrão em que você terá uma fronteira contestada, na qual ainda precisará de humanos, mas também um núcleo

14:48 que é bastante estável. Certo, agora esse núcleo é algo com que você pode fazer fine-tuning no modelo. Certo, mas, quando fizer isso, precisa monitorar o desvio. Há um desvio no meu núcleo? Se isso acontecer, você vai ter problemas. E, na verdade, um exemplo estável disso — não sei se vocês já ouviram falar da codificação de solicitações médicas. Acho que existem códigos ICD 10; as anotações dos médicos são associadas a códigos para diferentes fins, como seguros e coisas do tipo. Então, Mount Si

15:22 Mount Sinai e IMO health, na verdade… >> Aliás, existem 70.000 desses códigos. Então, você faria fine-tuning no modelo para aprender esses códigos? Eles não mudam com muita frequência. Você não faria. Isso é um fato. É conhecimento. Você não deveria estar pensando em fazer fine-tuning no modelo para isso. Um dos motivos óbvios é que eles mudam às vezes. E outro é que você precisaria de um grande conjunto de dados de treinamento para sequer fazer fine-tuning no modelo com isso. Certo. O que você ensina ao modelo por meio de fine-tuning é o reflexo

15:55 — se ele entende o formato da entrada e se é capaz de, quando precisa fazer uma seleção entre os formatos, determinar qual é o correto. É para isso que você faz fine-tuning no modelo. Certo. O diagnóstico para decidir se deve fazer fine-tuning é: as informações pararam de mudar? Os humanos chegaram a um consenso? E, mais importante, você

16:25 deve ter um destes dois motivos: você está fazendo fine-tuning porque o modelo não é capaz ou está fazendo fine-tuning para reduzir os custos? Muitas vezes, não é por causa da capacidade; os modelos de fronteira são bastante capazes. Geralmente, a questão acaba sendo o custo: se você tem padrões bem definidos no seu trabalho, talvez possa usar um modelo pequeno, fazer fine-tuning nele e executar o volume de trabalho por um custo baixo, certo?

16:56 Então, se você não se lembrar de nada desta palestra, esta é uma ideia simples, certo? Esta tabela me ajuda a decidir. Você pode comparar seu sistema de IA atual com ela e decidir. Basicamente, esta é a perspectiva que ajuda a decidir o que fica em cada lugar. É claro que pode haver exceções. Não estou dizendo que esta é sempre a regra. Pode haver exceções, mas o prompt diz respeito mais ao comportamento. A memória diz respeito ao que saber e aos fatos, e os pesos dizem respeito a como

17:28 raciocinar. Certo. E esta é a arquitetura. Seu prompt, ou sua context window, sua memória e seu fine-tuning precisam se integrar. Você precisa criar um harness adequado em torno disso, para que esses elementos possam se integrar. Seu prompt, ou sua context window, contém informações. Ele gera sinais. Alguns deles se tornam memória duradoura. Certo.

17:59 Agora, quando você inicia uma nova sessão, coisas são recuperadas da memória e levadas para o prompt ou para a context window. É aí que você passa da memória para o prompt. Além disso… muitas equipes já criaram essa arquitetura, mas o que as pessoas estão buscando — ou no que estão se concentrando — é construir o fluxo do lado direito: da memória para o fine-tuning. Certo. O que acontece é que, ao longo do tempo, quando você cria um sistema agentic, terá padrões de recuperação. Terá formatos que você

18:30 acha que o modelo deveria conhecer de forma reflexa. Então, essas coisas passam da memória para o fine-tuning, depois que você faz fine-tuning. Assim, vai da memória para os pesos. Depois do fine-tuning, muda o que vale a pena recuperar. Se você fez fine-tuning no modelo com formatos de anotações e códigos ICD, não precisa recuperar certos exemplos da memória ou da memória externa

19:01 todas as vezes e fornecê-los ao modelo, porque agora o modelo conhece o formato de forma reflexa. Você não precisa dar exemplos e dizer: “Este é o formato” ou “Aquele é o formato”. Esse é o caminho dos pesos para a memória. Então, basicamente, isso se torna um ciclo ao longo do tempo, e o agent melhora no seu trabalho pelo próprio fato de realizá-lo. Certo, essa é a arquitetura. Para concluir, eu gostaria de dizer que

19:34 o modelo é a parte fácil. O que você constrói em torno do modelo — o harness que ajuda a armazenar as informações certas no lugar certo e a fazer com que circulem entre esses elementos — é a arquitetura principal que você precisa construir. Obrigado. Obrigado por terem vindo.

Transcrição original

[00:01] [music] How do you decide what to put where? For most enterprise AI systems, the interesting engineing problem is not the model itself. The model consumes tokens and produces tokens. Your knowledge lives in files,

[00:33] databases, and APIs. The key architecture decision is how that knowledge reaches inference um from the prompt or the context through the retrieval or memory layer or by model adaptations such as fine-tuning. Today I’m going to argue that this is a decision that most enterprise teams make by accident.

[01:04] And the path to rec to to making it on purpose is to recognize that this is not a ladder that you climb. These are three different tools for three different jobs. So how is this an accident? Well, there are two mechanisms. One is the obvious one. The other one not so much. So the obvious one is that teams escalate. You don’t get the right answer from your

[01:34] model. The easy thing is go put something in the prompt like go fix the prompt. Still wrong? Maybe there is something with the memory system or the retrieval system. Let’s take a look there. Even then, if you’re wrong, hey, you know what? Let’s fine-tune the model. Doesn’t happen very often, but yes, sometimes teams reach out to fine-tune the model. There is a layer underneath it. The teams that are not escalating are still

[02:06] making these decisions every day. Every edit that you make to the prompt decides what behavior lives in the prompt. Every document that you index decides what knowledge is held in the memory. And every training sample that you bake in will every every training sample that you identify will bake something into the weights. Um

[02:38] all these are architecture decisions. None like that. Okay, let me make it a little concrete for you all. Um, so and I’ve seen this play out actually. Uh, an internal support assistant just released. In a few weeks, the product manager makes some changes to the prompt to fix the tone of the support assistant. After a few weeks, the support team adds refund policy documents to your retrieval on memory systems. I’ll talk

[03:10] about retrieval and memory. I’m teaching it. I’m I’m treating it all as memory, but I’ll come to that. Um, and then since your model is not your your agent is not giving you the right answers, an engineer shuffs the product catalog into the prompt. And after a few weeks, the machine learning team decides to train the model or fine-tune the model on support tickets from 6 months ago from up to 6 months ago.

[03:43] All decisions look fine look okay except one by the way. But even I have made such decisions in my in my journey. I have made such decisions of doing such things without really giving it a lot of thought. Um, so when the new product product catalog has launched, looks easy, right? Oh, the engineer has shoved the product catalog into the prompt. Let’s put the new product catalog there. And you would think that everything is working fine, but your

[04:15] model or your agent is still giving you product names that don’t even exist. How did that happen? Well, the product catalog leaked into the weights when you fine-tuned it on your support tickets. And that is the accident. Your model, your your architecture was accumulated. It was not designed. That is the accident. It is what 6 months of normal product

[04:46] work led to. Nobody owned it. Meaning everybody owned a piece of it. Okay. Um, nobody asked the diagnostic question. Nobody asked where this should where this thing should live. That diagnostic those diagnostic questions are the lens we are going to talk about and the rest of the talk is is about the lens. Okay. So the first part is prompt. What is the

[05:18] job of the prompt? The job of the prompt is behavior, is tone, is the persona of the agent. Things that are small, stable, and editable. The wrong job for the prompt is to store facts. You don’t put product catalog into the prompt because you are unnecessarily providing context to your model and paying the cost for it. And when you have too many tokens, you run into lost in the middle problem.

[05:49] The diagnostic for prompt is is the small knowledge small stable and about how to behave rather than what to know. A concrete example for a good prompt use case is a customer support agent for a product SAS. Right now this agent is has a professional tone. It is

[06:21] it offers human escalation after three failures and it provides you concrete next steps. None of this changes per query per user. This is this this exact thing belongs to the prompt. And one other thing is prompt is something I’m not only talking about system prompt. I’m talking about authored instructions for your for your model. So they could also come from MD files. They could also come from other things, right? But this is what I mean

[06:53] by prompt here. The second path is memory. The job of memory is to ground your model or your agent in in knowledge that is current, large and citable. Current meaning it changes faster than you can fine-tune. It changes every now and then. Large is because it cannot be held anywhere. It cannot be held in your

[07:24] prompt. and citable because production AI systems need to be able to point to the source of the knowledge. This is the this is what belongs to memory. Now when I use the term memory people think of agent memory knowledge that is acquired about people about people who about a person who is interacting with the agent right what I’m also referring to here is external memory which is which you retrieve using rag and all that like the refund

[07:55] policies right it’s not being managed by your agent it is managed by an external application that is included here so I’m talking both about the agent memory and the memory Mor of the enterprise. Okay. The wrong job of for memory is shoving behavior in or thinking about how to reason with the memory. Now, of course, you can have a graphical kind of rag which will help the agent do reasoning, but that’s

[08:27] it. That’s where you stop. For reasoning, you got to have the right model. Because if your model cannot reason over two or three or five documents, it won’t be able to reason over 50 that you provide. The more context doesn’t help if it’s not able to reason. So the diagnostic or the question you need to ask is is the knowledge too large to fit changing faster than I can retrain. And another important aspect is whether it has some access control whether it is

[08:57] scope per user. You have got to have that in memory. If there is some kind of access control that this user cannot see the other person’s information or the data or whatever, you’ve got to have that knowledge in memory because then you can control who sees what. A good example for storing something in external memory or memory is a code assistant, right? Which has access to your all your repos as an organization.

[09:33] So uh would you fine-tune your model to learn the code? No. It’s it’s a simple one, right? It changes very often. You wouldn’t do that. You’d finetune your model to learn reflexes, not facts typically. And would you stuff it in the prompt? No, you don’t stuff such things into the prompt. You may stuff or you may add certain things that are important in the context window, right? That’s something different. But you wouldn’t stuff the entire code base into the prompt. Okay? Or or even a part of it if it has no use

[10:04] there. Uh now the other important thing is um when you build a rack system right like for for for your code for your code you need to make sure that you are chunking properly you are using code aware chunking with a perhaps uh and then the other important thing is use filtering. You should denormalize. You should perhaps denormalize things such as who is the what is the repo this code is for. You get a code

[10:34] chunk. You have to create metadata about which repo it belongs to. What is the user what are the users who are allowed to commit and all that because that is what is going to help you get the exact data that you need versus creating a rag mush where you are returning a lot of chunks back from the database without and and then confusing the model. So again the diagnostic is something that’s too large to fit changing the faster than you can retrain the model

[11:05] and it’s scoped at a certain level. It could be it could be a user, it could be a repo or whatever. All that knowledge belongs to memory. It could be external memory which is your like your applications database or it could be your agent memory as well. Now let’s come to the interest more interesting part which is weights. So what belongs to the weight?

[11:36] Something that stopped changing. That is what belongs to the weight. And the only axis that drives this slide is rate of change. You can lock in what has stopped changing and perhaps retrain. And I’m not saying just lock in what stopped changing and just go retrain your model. No, that’s not what you do all the time. You would you have to have a very strong reason to retrain your model. So what you do is you lock in what’s changing and then go from there. But if you get it wrong, then you could freeze a

[12:08] boundary that’s still moving. Okay? And it’s not as subtle as like, hey, can I re would I re Nobody’s going to retrain their model on like or fine-tune, I meant not retrain, sorry, fine-tune their model on pricing list. Nobody does that. It is more subtle than that, right? And a current version of that is um there is an let’s say there is an internal document assistant and the support team or the or your team starts decides to fine-tune

[12:40] the model because it’s not giving the right answers. So to teach the domain, it says, you know what, let’s fine-tune this model on on our documentation. Let’s fine-tune the model on or or maybe not all your all their documentation but runbooks and procedures. And what happens with that? There is an issue. If you do that when a your model will be giving you information that’s old. This was actually a retrieval problem. If the model was not giving the right answer,

[13:12] what the model needed was the right chunks, the right pieces of documentation. So basically instead of fixing the retrieval problem, the team actually went ahead and fine-tuned the model. That’s not what you should do. Runbooks, procedures, these are facts. These belong to either your me either your agent memory not there but of course your external memory. That is where these things should reside. Not if the if the model is not >> good afternoon. Hello. >> Oh sorry that was I was like who’s that?

[13:46] So if your if your model is not giving the right answers, fix the retrieval problem. Don’t just go ahead and fine-tune your model. Okay. Uh and if you flip it, same axis. If you reverse it, u a good use case where I could fine-tune is let’s say it’s a hard ambiguous problem such as content moderation or claims processing. Right? When you begin, you can use a frontier model that makes recommendations and humans correct

[14:16] it although inconsistently. Over a period of time, patterns will emerge. Patterns will emerge and you will have sort of a center which is sort of fixed and stable. Okay? And then you will have the contested edge. the the rates of human overrides will flatline over after a certain point and you’ll you will most likely emerge in a pattern where you have a contested edge where you still need humans but a center

[14:48] which is pretty stable. Okay, now that center is something you can fine-tune your model on. Okay, but when you do that you have to monitor for drift. Is there a drift in my center? And if that happens then you’re going to run into problem. And um actually a stable version of that is I don’t know have you heard of medical claims coding? I think we must have like ICD 10 codes doctor’s notes are mapped to like codes for different purposes like insurance purposes and all that. So Mount Si

[15:22] Mount Sinai and IMO health actually >> there are 70,000 of such codes by the way. So would you fine-tune your model to learn those codes? They don’t change so often. You won’t. That’s fact. That’s knowledge. That’s you should not be looking at fine-tuning your model. One of the obvious reasons is is that they change sometimes. And the other is you will need a large test training data to even fine-tune your model on it. Okay. What you fine-tune our model is on the reflex

[15:55] whether whether it is understanding the format of the input and whether it is able to and when it you have to make selection across the formats like which one is the right one that’s where you fine-tune your model to do that. Okay. So the diagnostic for fine-tuning is has it has the information stopped changing have the humans converged and more important you

[16:25] should either h have one of these two reasons is the is are you fine-tuning because your model is not capable or are you fine-tuning to save cost and a lot of times it’s not capability frontier models are quite capable it usually comes down to cost where you can have a small if you have nice pattern in your work, you can actually perhaps use a small model, fine-tune it and run the volume cheap, right?

[16:56] So, if you don’t remember anything from the talk, this is a simple one, right? This table helps me decide. You can b you can bounce your current AI system against this and and decide this is the lens basically that helps you decide what lives where. Of course there can be exceptions. I’m not saying this is always the rule. There can be exceptions to this but prompt is more about behavior. Memory is about what to know and facts and weights are about how to

[17:28] reason. Okay. And this is the architecture. Your prompt or your context window, your memory and your finetuning needs to circulate. You need to build a right harness around it so that these things can circulate. Your prompt or your context window has information. It generates signals. Some of them becomes durable memory. Okay.

[17:59] Now when you are restarting a new session things get pulled out of from the memory into the prompt or context window and that’s when you’re going from the memory to the prompt. The more so this is lot of teams have built this architecture but what people are looking to are focusing on building is the right side the memory to fine-tuning flow. Okay. Now what happens is when you build an agentic system over a period of time you will have retrieval patterns. You will have formats that you

[18:30] think the model should reflexively know. So those things move from your memory to fine-tuning once you have fine-tuned. So that’s memory to weights. Once you have fine-tuned what is worth retrieving changes if you have changed if you have fine- tuned your model on the formats of like notes and the ICD codes you don’t have to retrieve certain examples from your memory or external

[19:01] memory each time and provide it to the model because now the model knows the format reflexively you don’t have to provide examples to it that hey this is the format or that is the format so that’s weights to memory and so basically This becomes a loop over a period of time and the agent gets better at its job by the virtue of doing its job. Okay, that’s the architecture. So what I would like to conclude with is

[19:34] the model is is the easy part. What you build around the model, the harness around the model that helps you store the right information at the right place and circulate among them is the key architecture that you got to build. Thank you. Thanks for coming up.