Modelos de linguagem de contexto: seu agent não precisa de compactação

Autoria: Prompt Engineering · 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: Context Language Models: Your Agent Doesn’t Need Compaction · Canal: Prompt Engineering · 13:32 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de prompts e contexto, Inferência e otimização de modelos, Segurança de IA

Resumo

O vídeo apresenta os Context Language Models (CLM), uma abordagem em que o modelo pode editar seu próprio contexto em vez de depender de resumos periódicos que podem perder informações importantes. Uma demonstração com Pi mostra o modelo substituindo registros já lidos por notas concisas, e o vídeo compara essa abordagem com a sumarização padrão em tarefas envolvendo logs. O CLM teve bons resultados nesses testes, mas depende de configurações adequadas do harness e pode aumentar custo e latência, além de exigir atenção à segurança e à capacidade do modelo. O vídeo conclui que permitir que o modelo gerencie o contexto pode ajudar, desde que se monitorem o cache e as limitações da abordagem.

Pontos-chave

A compactação tradicional pode descartar informações que só se tornam relevantes mais tarde, sem que o agent perceba o que foi perdido.
No CLM, o modelo pode manter, reduzir, apagar ou reescrever o contexto antes da próxima solicitação.
A extensão para Pi permite visualizar o tamanho do contexto e as edições feitas pelo modelo.
Nos testes apresentados, a sumarização padrão inventou códigos de lacre e ignorou informações presentes nos logs.
O CLM manteve os códigos de lacre corretos e acertou quase todas as respostas nas tarefas descritas.
Chamadas paralelas de ferramentas podem fazer o contexto ultrapassar o limite antes que o modelo consiga editá-lo; o vídeo recomenda uma chamada por turno e uma nota de tamanho após cada resultado.
Editar partes intermediárias do contexto pode prejudicar o reaproveitamento do cache de prefixo, aumentando latência e custo.
O CLM não é automaticamente mais barato: em um teste, processou cerca do dobro de tokens que Pi.
A qualidade do modelo importa, e uma prompt injection pode persistir entre turnos se puder alterar a memória do modelo.

Capítulos

Início	Capítulo	Resumo
00:00	O problema da compactação de contexto	O vídeo apresenta uma demonstração em que o modelo edita seu contexto e explica como resumos tradicionais podem perder informações.
03:09	Como funciona um Context Language Model	O CLM trata o contexto como um arquivo editável e pode reorganizar ou condensar seu conteúdo entre turnos.
05:45	Instalação e testes com Pi	O apresentador descreve a extensão para Pi e compara a sumarização padrão com o CLM em tarefas baseadas em logs.
09:55	Limitações de configuração, custo e cache	O vídeo discute chamadas paralelas de ferramentas, efeitos no cache de prefixo e o aumento possível de tokens, custo e latência.
11:58	Qualidade do modelo e riscos de segurança	O apresentador aborda a importância da capacidade do modelo, os resultados com diferentes limites de contexto e a persistência de prompt injection.
13:01	Conclusão	O vídeo recomenda explorar a abordagem com atenção ao harness e ao cache e convida o público a compartilhar usos e alternativas.

Citações

O gerenciamento de contexto é um dos verdadeiros gargalos dos agents que temos hoje. — 00:00

O modelo decide como será todo o contexto na próxima interação. — 03:42

Todos os 18 códigos estavam corretos. — 09:24

Se o modelo pode escrever na própria memória, uma prompt injection também pode. — 12:28

Conceitos e entidades

Context Language Model (conceito): Abordagem em que o modelo edita o conteúdo do próprio contexto para decidir o que será usado na próxima interação.
Context Bench (benchmark): Benchmark apresentado no vídeo para avaliar tarefas de manutenção e atualização de informações no contexto.
Pi (ferramenta): Agent de programação open source usado na demonstração e nos testes de sumarização.
Meta (empresa): Empresa cuja equipe, junto com pesquisadores da University of Washington, é associada ao artigo sobre Context Language Models.
University of Washington (empresa): Universidade que participou, junto com a Meta, do trabalho apresentado sobre Context Language Models.
BrowseComp Plus (benchmark): Benchmark de Deep Research citado no vídeo ao apresentar resultados do artigo.
vLLM (ferramenta): Servidor usado para executar localmente o modelo nos experimentos do apresentador.
SGLang (ferramenta): Projeto mencionado em relação a uma implementação experimental de suffix cache reuse.
suffix cache reuse (conceito): Método descrito no vídeo para preservar o trabalho em texto inalterado que vem depois de uma edição.
prefix caching (conceito): Reaproveitamento do processamento de um prefixo do prompt, que pode ser afetado pelo local em que o modelo edita o contexto.

Tradução completa (pt-BR)

00:00 O gerenciamento de contexto é um dos verdadeiros gargalos dos agents que temos hoje. Quando eles se aproximam do fim da context window, forçamos o agent a resumir tudo o que aconteceu até então. E o resumo pode descartar as informações mais relevantes. Então, e se, em vez de resumir, deixássemos o agent editar a própria context window? Foi exatamente isso que a equipe da Meta e da University of Washington fez em um novo artigo chamado Context Language Model. Agora, antes de mostrar como funciona, deixe

00:31 que eu mostre uma demonstração rápida. Aqui está o Pi, o agent de programação open source. Ele está rodando localmente na minha máquina DGX. Dei a ele um conjunto de registros de turnos de um armazém para analisar, que é muito maior do que cabe na context window. Normalmente, nesse ponto, o harness interviria e escreveria um resumo para preservar o contexto. Mas veja o que está acontecendo aqui. O agent abre um arquivo. Esse arquivo é o próprio contexto dele. E ele pega este registro de 3.000 tokens

01:02 que leu algumas interações atrás e o substitui por uma linha, que preserva exatamente as informações que aquele contexto fornece. E, se você olhar este painel, verá o tamanho do contexto aumentar a cada arquivo que ele lê e depois diminuir sempre que o modelo faz uma limpeza. O melhor é que não há regras sobre o que manter e o que descartar. O modelo decide quais são exatamente as informações mais importantes. Certo, então, no restante do vídeo, eu

01:33 quero falar sobre como isso funciona exatamente e como você pode executar por conta própria. Depois, vamos falar de alguns problemas que encontrei ao testar, porque há um custo que é muito fácil não perceber. Certo, mas primeiro vamos falar sobre por que isso importa. Todos os harnesses de agents atuais, como Claude Code, Codex ou Pi, lidam com um contexto cheio de maneira muito parecida. Em um ponto fixo, digamos, com 75% da janela ocupada, o modelo escreve um resumo, e o harness mantém as últimas interações e

02:06 basicamente substitui as conversas anteriores por esse resumo. Se você usa Codex ou Claude Code, pode até acionar isso com o comando {slash} compact. Mas aqui está o problema. Digamos que seu agent esteja depurando um serviço e que, 40 interações atrás, tenha lido um arquivo de configuração com um valor que acaba sendo o mais importante mais tarde. O resumo foi escrito antes de alguém saber que esse valor seria importante. Se esse valor não entrou no resumo, basicamente desapareceu, e o

02:37 agent nem sabe o que está faltando. E o agent talvez passe muito mais tempo vasculhando os registros ou, bem, gastando muitos tokens para tentar descobrir isso de novo. O artigo criou um pequeno benchmark em torno disso, chamado Context Bench, que inclui tarefas simples, como manter um tabuleiro de Sudoku atualizado enquanto os movimentos chegam. Nesse benchmark simples, a maioria das técnicas de compactação existentes falha. Uma maneira de lidar com isso seria

03:09 acionar prompts de resumo mais inteligentes ou compactar com mais frequência. Isso poderia ajudar, mas o problema é que a compactação ainda acontece em um ponto específico e o resumo continua sendo escrito. No fim, você vai acabar com um resumo de resumos, que pode perder todas as informações mais importantes que você quer preservar. Então, o que exatamente é um modelo de linguagem de contexto? Em um modelo de linguagem normal, cada interação é acrescentada ao fim do contexto.

03:42 Então, essencialmente, o novo contexto enviado ao modelo na próxima interação é o contexto antigo mais o que quer que o modelo tenha produzido. Um modelo de linguagem de contexto substitui esse sinal de mais por uma função. O modelo decide como será o contexto inteiro na próxima interação. Assim, ele pode manter, reduzir, excluir ou reescrever o que precisar. Certo, veja como funciona na prática. Antes de cada solicitação, o harness

04:14 grava o contexto em um arquivo. Depois, cada interação é um bloco com um cabeçalho. O modelo pode abrir esse arquivo e editá-lo com um pequeno script Python, exatamente como faria com código. E tudo o que restar nesse arquivo ao fim da interação se torna o próximo prompt. Foi exatamente isso que vimos na demonstração. Quando você dá esse tipo de controle a um modelo, ele cria suas próprias estratégias. No artigo, ele inventou uma

04:45 nova função de chat chamada notes, só para uso próprio. Escreveu uma pequena função auxiliar para compactar resultados antigos de buscas e a chamou 37 vezes. E, em uma execução com vários agents, manteve no próprio contexto um placar de 21 subagents e o atualizou no próprio lugar 163 vezes. O melhor é que você pode acionar a compactação com instruções muito simples, em inglês comum. Por

05:15 exemplo, se disser algo como: “Quando passar de 24.000 tokens, compacte para 4.000.” E isso realmente funcionou. Isso basta para mudar exatamente quando o modelo vai compactar. E, segundo o artigo, isso funciona no BrowseComp Plus, um benchmark de Deep Research: o modelo obteve 59,4% com 20.627B. Isso é cerca de 11% a mais do que a melhor abordagem de resumo, usando cerca de um quinto a menos de computação.

05:45 Certo, como você pode executar isso por conta própria? Os autores lançaram uma extensão para o Pi, que você pode instalar com um único comando. Depois, dentro do Pi, você pode digitar {slash} CLM. Isso abre o painel que você viu na demonstração, com o tamanho do contexto ao longo do tempo, e uma página que mostra, lado a lado, cada edição feita pelo modelo. Certo, nos meus testes, executei com quant 3.8 27B, servido

06:19 localmente com VLLM. O artigo usou uma versão anterior do 27B, então estou usando a versão mais recente. Eles deram ao modelo um orçamento de 32.000 tokens, então vamos manter o mesmo orçamento. Vou colocar as configurações exatas na descrição, caso você queira reproduzir o teste. Meu objetivo era ver como isso se sai em tarefas reais. Então, criei três tarefas diferentes que não

06:49 cabiam na janela e comparei o resultado com a própria sumarização do Pi. Certo, vamos analisá-las, mas aqui está um exemplo. Descrevi os registros do armazém no começo do vídeo. São registros de 16 dias, e o agent precisa acompanhar os códigos dos lacres dos caminhões. Depois, precisa descobrir qual deles foi anulado um dia depois ou após alguns dias e listar os que ainda são válidos. Este é um exemplo sintético. Não o trate como um

07:20 benchmark, mas encontrei algumas coisas realmente interessantes que o modelo de linguagem de contexto faz com isso. Certo, para estabelecer uma linha de base, usamos a sumarização do Pi, e surgiram algumas coisas muito interessantes na própria linha de base. O Pi resumiu três vezes, e nós comparamos cada resumo com os registros. Certo, o primeiro resumo listou 12 códigos de lacre, mas o problema é que 11 deles não existiam em lugar nenhum. Então, ele

07:51 basicamente alucinou esses códigos. No terceiro resumo, 14 dos 18 códigos eram inventados. Ele até inventou uma pequena sequência que ficava bem ao lado do código real. Esse é um dos principais problemas dos resumos de resumos, porque muita informação acaba se perdendo, e os agents, especialmente os modelos menores, podem alucinar bastante. O resumo parece perfeitamente confiante, com as caixas de seleção

08:23 e os próximos passos. Então, o agent não tem como saber que está errado. O interessante é que o agent acertou a resposta apesar desses resumos, mas não porque se lembrava das coisas. Na verdade, voltou e releu todos os arquivos do disco usando grep, embora o prompt dissesse explicitamente para não fazer isso. Em outra tarefa, depois de um resumo, o agent decidiu que os registros não continham nenhuma informação sobre deploy, mas, na verdade, a linha do deploy estava bem ali. E ele já a tinha lido, mas, durante a sumarização, ignorou-a completamente. Isso foi com a sumarização padrão do Pi. Agora, vamos ver o que aconteceu com o Pi CLM nas mesmas tarefas. O modelo escreveu todo o contexto em um único bloco de notes. Neste caso, ele acompanha cada código de lacre que foi aplicado, cada lacre

08:54 informações de deploy, mas, na realidade, a linha de deploy estava bem ali. E ele já a tinha lido, mas, durante o processo de sumarização, a ignorou completamente. Isso aconteceu com a sumarização padrão do Pi. Agora, vamos ver o que aconteceu com o Pi CLM nas mesmas tarefas. O modelo escreveu todo o seu contexto em um único bloco de notas. Nesse caso, ele registra cada código de selo que foi aplicado, cada selo

09:24 o que foi invalidado e o que ler em seguida. Todos os 18 códigos estavam exatos. E, nas tarefas de seal e incident, acertou todas as respostas, exceto uma. Já o Pi precisou do resgate do grip; caso contrário, basicamente alucinava. Certo, então a melhor parte é que isso realmente funciona. Você pode usar. No entanto, precisa ter em mente algumas ressalvas importantes, porque, se pretende desenvolver algo com base nisso, é importante conhecer as

09:55 limitações, mais do que os pontos fortes. E é isso que sempre sugiro: observe onde o sistema falhou, especialmente com esses novos modelos de linguagem. Certo, então a primeira coisa é que a dificuldade importa mais do que você imagina. Em três dos quatro turnos padrão, o modelo nem sequer editou o próprio contexto. O Pi CLM tem uma rede de segurança que substitui saídas antigas de ferramentas por uma nota curta quando o contexto está prestes a exceder o limite. E, na

10:26 maioria dos casos, essa rede de segurança fez todo o trabalho. O motivo são as chamadas paralelas de ferramentas. O modelo leu quatro arquivos em um turno e depois ultrapassou o restante antes que pudesse reagir de fato. Então, se quiser usar isso, você precisa ativar uma chamada de ferramenta por turno e a nota de tamanho depois de cada resultado, que é como funciona o harness do artigo original. Com essas duas configurações, o modelo editou o próprio contexto. A segunda coisa

10:57 é o custo e a latência. Quando um servidor como o VLLM lê seu prompt, ele salva o trabalho em um cache. E, se nada puder reutilizar esse prefixo do prompt, não há armazenamento em cache do prefixo. No caso do context language model, importa muito onde o modelo altera o arquivo de contexto. Por exemplo, se ele alterar o contexto perto do fim do arquivo, ainda poderá preservar e reutilizar a maior parte do contexto

11:27 como um prefixo em cache. As respostas serão mais rápidas. No entanto, se ele começar a editar o arquivo no meio, tudo depois desse ponto será perdido no cache de prefixo, o que significa que terá de reprocessar tudo a partir dali. Isso não só aumentará a latência, como também o custo de geração. E a terceira coisa é que isso não é automaticamente mais barato. Em uma das minhas execuções de seal, o Pi CLM processou cerca de duas vezes mais tokens que o

11:58 Pi. E, em outra, apenas 10% do prompt veio do cache. O artigo também criou uma solução chamada reutilização de cache de sufixo, que preserva o trabalho feito no texto inalterado após uma edição. Mas, por enquanto, é um patch do SGLang para um modelo em uma GPU. Então, não consegui realmente testar isso. E a quarta coisa é que o modelo precisa ser bom nisso. No artigo, o modelo de 9 bilhões de parâmetros

12:28 ficou seis pontos atrás de resumos limpos até ser treinado com aprendizado por reforço. E os resultados de destaque usam um orçamento pequeno de 32.000 tokens. Com 128.000 tokens, CLM e o resumo ficam basicamente empatados. E mais uma coisa sobre segurança: se o modelo pode escrever na própria memória, uma injeção de prompt também pode. E qualquer injeção de prompt vai persistir entre os turnos. Essa é uma das

13:01 preocupações que o próprio artigo destaca. No geral, gosto muito dessa direção. Os resumos são escritos uma vez e depois considerados confiáveis para sempre. E, nas minhas execuções, foi exatamente aí que as coisas deram errado. Deixar o modelo gerenciar o próprio contexto resolveu esses problemas para mim. Mas o principal é que, desde que o harness dê espaço para ele reagir e você fique de olho no cache, é uma abordagem muito interessante, para ser sincero, né? Acho que vamos ver evoluções

13:32 disso, mas me contem nos comentários para que vocês usariam isso, se já viram algo parecido ou se desenvolveram abordagens que estejam usando para gerenciar a context window. Compartilhem nos comentários abaixo. Enfim, espero que tenham achado este vídeo útil. Obrigado por assistir e, como sempre, até o próximo.

Transcrição original

[00:00] Context management is one of the real bottlenecks for agents that we have today. As they get close to the end of the context window, we force the agent to summarize everything that has happened so far. And the summary can throw away the most relevant information. So, what if instead of summarization, we let the agent edit his own context window? That’s exactly what the team at Meta and University of Washington did in a new paper called the context language model. Now, before I show you how it works, let

[00:31] me show you a quick demo. So, here’s Pi, the open-source coding agent. It’s running locally on my DGX box. So, I have given it a stack of warehouse shift logs to go through, which is a lot more than that can fit in its context window. Now, normally at this point, the harness would step in and write a summary in order to preserve the context. But look at what is happening here. The agent opens a file. That file is its own context. And it takes this 3,000 token

[01:02] log it read a few turns ago and replaces it with one line, which preserves the exact information that context is providing. And if you look at this panel, you can see the context size climbing at every file it reads and then dropping every time the model cleans up after itself. Now, the beauty is there are no rules what to keep and what not to keep. The model is deciding what exactly is the most important information. Okay, so in the rest of the video, I

[01:33] want to talk about how exactly does this work and how you can run it yourself. And then we’re going to talk about some gotchas I ran into while testing it because there is one cost that’s really easy to miss. All right, but let’s first talk about why this matters. Every agent harness today, like Cloud Code, Codex, or Pi, handles a full context in a very similar way. At a fixed point, say 75% of the window, the model writes a summary and the high earnest keeps those last few turns and

[02:06] basically replaces the previous conversations with that summary. If you use Codex or Cloud Code, you can actually trigger this with the {slash} compact. But, here’s the problem. Say your agent is debugging a service and say 40 turns ago it read a configuration file uh with one value that turns out to matter the most later on. Now, the summary was written before anyone knew it’s going to matter. If that value didn’t make it into the summary, it’s basically gone and the

[02:37] agent doesn’t even know what is missing. And the agent might spend a lot more time in order to dig through the logs or well, spend a lot of tokens trying to figure that out again. Now, the paper built a small benchmark around this called Context Bench, which includes simple tasks like keeping a Sudoku board up to date while the moves streams in. Now, on this simple benchmark, most of the existing compaction techniques actually fail. Now, one way to tackle this is you could

[03:09] trigger smarter summary prompts or compact more often. Now, this could potentially help, but the problem is that the compaction still happens at a specific point and the summary is still written. At the end, you’re going to be end with a summary of summaries, which is going to potentially lose all of the most important information that you want to preserve. So, what exactly is a context language model? In a normal language model, every turn adds to the end of the context.

[03:42] So, essentially the new context that is fed into the model on the next turn is the old context plus whatever the model produced. Now, a context language model replaces that plus sign with a function. The model decides what the entire context is going to look like on the next turn. So, it can essentially keep, shrink, delete, or rewrite anything it needs. Okay, so here’s how it actually works. So, before every request, the harness

[04:14] writes the context out to a file. Then every turn is a block with a header. Now, the model can open that file, edit it with a small Python script exactly the same way it would edit code. And whatever is left in that file at the end of the turn becomes the next prompt. That’s exactly what we saw in the demo. Now, when you hand a model this kind of control, it comes up with its own strategies. In the paper, it invented a

[04:45] new chat role called notes just for itself. It wrote a little helper function to compact old search results and called it 37 times. And in a multi-agent run, it kept a scoreboard of 21 sub-agents inside its own context and updated it in place 163 times. Now, the beauty is that you can actually trigger compaction uh with very simple instructions in plain English. For

[05:15] example, if you say something like, “Once you pass 24,000 tokens, compact it down to 4,000.” And it actually worked. Now, this is enough to actually change exactly when the model is going to compact. And according to paper, this works on BrowseComp Plus, which is a Deep Research benchmark, it scored 59.4% with 20.627B. That’s about 11% higher than and best

[05:45] summary approach with about a fifth less compute. Okay, so how do you run this yourself? The authors actually released an extension for Pi and you can install it with a single command. Then inside Pi, you can type {slash} CLM. This is going to open up a panel you saw in the demo with the context size over time and a page that shows every edit the model made side by side. Okay, so for my experimentation, I ran it with quant 3.8 27B, which is served

[06:19] locally with VLLM. Now, though the paper actually used a previous iteration of the 27B, so I’m using the latest version. They had a 32,000 tokens token budget for the model, so we’re going to stick to the same budget as well. I’m going to put the exact settings in the description if you are interested in replicating this. Now, my goal was to see how this actually holds up in real tasks. So, I built three different tasks that didn’t really

[06:49] fit in the window and ran them against Pi’s own summarization. Okay, we’re going to look at those, but here is one example. I described the warehouse logs in the beginning of the video. These are basically 16 days logs and the agent has to track truck seal codes. Then it actually needs to figure out which one got voided a day later or after a few days and list the ones that are still valid. Now, this is a synthetic example. Don’t treat it as a

[07:20] benchmark, but I actually found some really interesting things the context language model does with this. Okay, so to establish a baseline, we used the Pi summarization and there were some really interesting things that came out of the baseline itself. Pi summarizes three times and then we We every summary against the logs. Okay, so the first summary listed 12 seal codes, but the problem was that 11 of those uh didn’t exist anywhere. So, it

[07:51] basically hallucinated those codes. Now, by the third summary, 14 of 18 codes were basically made up. It even invented a little sequence, which was right next to the real code. Now, this is one of the main problem with summarization of summaries, because you are going to lose a lot of information, and the agents, especially the smaller models, can hallucinate a lot. Now, the summary actually looks perfectly confident with the check boxes

[08:23] and the next steps. So, the agent has no way to know it’s wrong. Now, the interesting thing was that the agent actually got the answer right uh despite those summaries, but the reason was not that it remembered things. It actually went back and really reread every file from disk with grep, even though the prompt told it not to do so explicitly. On another task after a summary, the agent decided that the logs didn’t contain any

[08:54] deploy information, but in reality, the deploy line was right there. And it had already read it, but during the summarization process, it had completely ignored it. Now, this was with the default summarization in Pi. Now, let’s look at what happened with Pi CLM on the same tasks. The model wrote its whole context into one notes block. In this case, it keeps track of every seal code that was applied, every seal

[09:24] that was voided, and what to read next. All 18 codes were exact. And across the seal and incident tasks, it got every answer right except one. While Pi needed the grip rescue or it basically hallucinated. Okay, so the best part is that it actually works. You can use it. However, you need to keep a few important gotchas in mind because if you’re going to be building on this, it’s important to know the

[09:55] limitations than the strengths. And this is what I always suggest. Look at where the system failed, especially with these new language models. Okay, so the first one is that the hardness matters more than you would think. And three of the four default turns, the model never edited its own context at all. Pi CLM has a safety net that swaps old tool outputs for a short note when the context is about to overflow. And in

[10:26] most cases, that safety net did all the work. The reason is parallel tool calls. The model read four files in one turn and then blew past the remainders before it could actually react. So, if you want to use this, you need to turn on one tool call per turn and the size note after every result, which is how the actual paper harness works. So, with those two settings, the model edited its own context. The second one

[10:57] is cost and latency. So, when a server like VLLM reads your prompt, it saves its work in a cache. And if nothing can actually reuse that prompt prefix caching. Now, for context language model, it really matters where the model is changing its context file. So, say if it’s changing context towards the end of the file, it can still preserve and reuse most of the context

[11:27] as a prefix caching. The responses are going to be faster. However, say if it starts editing the file in the middle, then anything beyond that point is going to be lost in the prefix caching, which means it has to reprocess everything beyond that point. It will not only increase the latency, but also the cost of generation. And the third one is that it’s not automatically cheaper. So, in one of my seal runs, Pi CLM processed about twice as many token as

[11:58] Pi. And on another another one, only 10% of the prompt came from the cache. Now, the paper also built a fix called suffix cache reuse that keeps the work for unchanged text after an edit. But for now, uh it’s an SGL lang patch for a one model on one GPU. So, I couldn’t really test that. And the fourth one is that the model has to be good at this. In the paper, uh the 9 billion parameter

[12:28] model was six points behind clean summaries until they trained it with reinforcement learning. And their headline results uses a small 32,000 token budget. At a 128,000 tokens, CLM and the summary basically is a tie. And one more thing on security, if the model can write to its own memory, so can a prompt injection. And any prompt injection is going to stay across turns. This is one of the

[13:01] concerns that the paper itself highlights. So, overall, I really like this direction. Summaries are written once and then trusted forever. And in my runs, uh that’s exactly where things kind of went wrong. Letting the model manage its own context fixed those problems for me. But the main thing is that as long as the harness gives it the room to react, and uh you keep an eye on the cache. It’s a very interesting approach to be honest, right? We’re going to see I think there are going to be evolutions

[13:32] of this, but let me know in the comments what you would use this for or if you have seen anything like this or have come up with approaches that you’re using for managing the contacts window, please do share them in the comments section below. Anyways, I hope you found this video useful. Thanks for watching and as always, see you in the next one.