O que chega completo e o que chega só como nome

A recuperação tem duas tarefas. Escolher o conhecimento certo é a mais conhecida. Decidir quanto espaço cada entrada escolhida merece é a que determina se a boa resposta realmente cabe.

Um design mais simples resolve a segunda questão com uma única regra: tudo o que é priorizado vai com o conteúdo completo, na ordem de prioridade, até o espaço acabar. A oitava entrada recebe exatamente o mesmo tratamento que a primeira, e a seguinte não recebe nada, mesmo quando é relevante. A relevância decide a ordem e mais nada.

No Pathrule, a relevância decide a forma.

Três formas, uma única priorização

• As poucas mais próximas chegam com o conteúdo completo. O assistente as lê e age, sem uma busca separada e sem ida e volta.
• Todo o resto que é relevante chega como um nome, um id e uma linha. O suficiente para o assistente reconhecer a entrada e buscar o corpo quando ela se mostrar importante.
• Skills chegam apenas pelo nome, por mais alta que seja sua prioridade. Falamos mais sobre isso abaixo.

A propriedade importante é a do fim da lista: uma entrada relevante não é descartada por falta de espaço. O que não cabe no orçamento por prompt é listado pelo título, e é a forma enxuta que torna isso viável.

A quantidade de corpos que chegam completos é escolhida para manter inteiras as correspondências mais fortes, custando menos do que enviar todas as entradas priorizadas por completo. O orçamento exato faz parte do motor do Pathrule e pode mudar entre versões.

Por que uma skill nunca é enviada sem pedido

Uma memória é um fato. Uma regra é uma restrição. As duas são coisas que um assistente deveria simplesmente saber enquanto trabalha, então as duas podem chegar como conteúdo.

Uma skill é um procedimento. Colocar um procedimento no contexto de um turno que não pediu um não informa o assistente, dá instruções a ele, e um assistente que recebeu um checklist tende a seguir o checklist. Por isso as skills são oferecidas pelo nome, e o assistente recorre a uma quando o trabalho é de fato aquele que a skill descreve. Ao invocá-la, por exemplo com ::skill-name, o corpo completo é carregado. Veja como escrever skills para entender o que uma skill deve ser.

As regras também precisam merecer seu espaço

Se as regras pulassem o teste de relevância, uma restrição sobre migrações de banco de dados poderia tirar o lugar da memória que responderia a uma pergunta sobre um botão. Por isso as regras passam pelo mesmo teste de relevância que todo o resto, e uma regra sem relação com a tarefa chega como um nome em vez de ocupar um espaço completo.

A exceção é intencional: uma regra marcada como strict mantém seu corpo, porque uma restrição rígida cuja violação causa uma regressão não é algo para racionar. Veja Regras como guardrails.

É o rebaixamento que torna a relevância observável

Há um segundo motivo pelo qual a forma enxuta importa, e ele tem a ver com aprendizado, não com custo.

Quando toda entrada priorizada é enviada como corpo, a camada nunca descobre se alguma delas era desejada. Um corpo que chega sem ter sido pedido não gera evidência em nenhum sentido. Um nome oferecido é diferente: o assistente o busca ou não, e uma busca é um ato deliberado de quem sabe do que o trabalho precisava.

Essa busca é um sinal de relevância útil, e uma entrada que continua sendo buscada tem mais chance de chegar completa da próxima vez. Isso se encaixa no ciclo mais amplo descrito em como a recuperação encontra o conhecimento certo: a camada mede o que entregou em vez de pedir ao assistente que relate o resultado.

O limiar precisa valer em todos os idiomas

Se uma entrada é enviada ou não depende de um limiar de relevância, e esse limiar pode depender do idioma sem que ninguém perceba. A mesma memória pode ter uma pontuação para um prompt escrito em inglês e uma pontuação menor para uma tradução fiel desse prompt, porque a correspondência baseada em significado não produz resultados idênticos entre idiomas para a mesma ideia. Um limiar ajustado apenas com prompts em inglês cortaria os outros idiomas sem que ninguém notasse, e o sintoma não seria um erro. Seria uma equipe que escreve seus prompts em turco recebendo menos contexto do que uma equipe que escreve os mesmos prompts em inglês.

Por isso o limiar é definido onde ele vale para todos os idiomas, e o Pathrule testa isso com prompts em vários idiomas em vez de presumir. Como o Pathrule comprova afirmações fortes descreve como afirmações como essa são verificadas.

Um prompt que pergunta duas coisas recebe conhecimento para as duas

Faça uma pergunta e a correspondência baseada em significado funciona bem. Faça duas na mesma mensagem e ela tem um problema estrutural: a solicitação vira uma única média de duas ideias diferentes, e a média de duas coisas muitas vezes não fica perto de nenhuma delas. A entrada que responde à sua primeira pergunta e a que responde à segunda podem ambas ficar abaixo de um limiar que qualquer uma delas teria superado sozinha.

O Pathrule lê uma solicitação com várias partes como suas partes. Cada parte é comparada separadamente e os resultados são combinados, então uma pergunta em duas partes recebe conhecimento para as duas, enquanto uma pergunta de uma parte só é comparada como antes.

O espaço disponível cresce com a pergunta, e não com o espaço de trabalho. Perguntar duas coisas custa um pouco mais do que perguntar uma. Ter dez mil memórias em vez de cem custa o mesmo.

O que ler em seguida

• Como a recuperação encontra o conhecimento certo, para a seleção sobre a qual esse modelo de entrega se apoia.
• Como os hooks funcionam, para ver como a parte selecionada chega ao assistente antes da primeira chamada de ferramenta.
• Como o Pathrule comprova afirmações fortes, para ver como afirmações como o comportamento entre idiomas são testadas.