Cross-Platform Information Retrieval Testing

1. Como a Recuperação Funciona no Rovo?

Antes de testar, é útil entender como o Rovo busca informações. Não se trata de uma simples busca por palavras-chave. A Atlassian implementou uma arquitetura de busca sofisticada para entregar resultados relevantes de múltiplas fontes.

A imagem a seguir ilustra o resultado final: um usuário faz uma pergunta, e o Rovo responde citando as fontes de conhecimento que usou para formular a resposta.

Para entender a tecnologia por trás disso, a Atlassian publicou um artigo técnico detalhado. Dado o seu background em engenharia e pesquisa, você achará esta exploração da arquitetura de busca do Rovo particularmente interessante.

Em resumo, o Rovo não apenas busca, mas também entende, reclassifica e combina informações de todas as fontes conectadas, usando uma abordagem em várias camadas para garantir a máxima relevância. Nosso trabalho agora é verificar se essa poderosa máquina de busca está corretamente apontada para nossas fontes de dados.

2. Abordagem 1: Teste Interativo

A maneira mais direta de testar a recuperação é simular uma tarefa real e analisar a resposta do agente. Vamos criar um cenário e um prompt que forcem o agente a consultar tanto o Google Drive quanto um repositório de código.

Cenário de Teste:

• Tarefa: Um ticket do Jira (PROJ-123) solicita a adição de uma nova regra de validação no endpoint de registro de usuário.
• Fontes de Conhecimento:
  1. A regra de negócio específica está detalhada em um documento chamado "Regras de Negócio para Autenticação" no Google Drive.
  2. As diretrizes de arquitetura, que exigem o uso de FluentValidation para todas as validações de modelo, estão no arquivo AGENTS.md do repositório de backend C#.

Para construir um prompt eficaz, podemos nos inspirar em algumas boas práticas.

Com base nisso, podemos criar o seguinte prompt para o Rovo Dev CLI ou para o Rovo Chat:

PROJ-123: Gere um plano de implementação para a nova regra de validação. Consulte o documento 'Regras de Negócio para Autenticação' e as diretrizes de arquitetura no AGENTS.md do repositório de backend.

Análise do Resultado:
Ao executar este prompt, um resultado "bom" seria uma resposta que:

1. Cita a fonte do Google Drive: "De acordo com o documento 'Regras de Negócio para Autenticação', a nova regra exige que o nome de usuário não contenha caracteres especiais."
2. Cita a fonte do repositório: "Para a implementação, conforme o AGENTS.md, deve-se criar uma nova classe de validador usando a biblioteca FluentValidation."

Se o agente não mencionar uma das fontes ou alucinar informações, isso indica um problema na etapa de recuperação para aquela fonte específica.

3. Abordagem 2: Avaliação Sistemática da Qualidade de Recuperação

Testes interativos são ótimos para verificações pontuais, mas para uma avaliação mais rigorosa e escalável, podemos adotar métricas formais, semelhantes às usadas pela própria Atlassian. Isso será familiar ao seu background de pesquisa acadêmica.

Aplicação Prática:
Embora não vamos construir um sistema de avaliação automatizado completo agora, podemos aplicar o princípio do Recall@k manualmente. Crie um pequeno "conjunto de ouro" (golden set) de pares (consulta, documento_esperado):

• Consulta 1: "Quais são as regras de negócio para complexidade de senha?"
  • Documento Esperado: password_policy.gdoc (do Google Drive).
• Consulta 2: "Qual é a maneira padrão de implementar o padrão de repositório em nosso backend C#?"
  • Documento Esperado: backend-repo/AGENTS.md (do repositório Git).
• Consulta 3: "Descreva a arquitetura para o serviço de notificações mobile."
  • Documento Esperado: mobile-architecture.gdoc (do Google Drive) e/ou mobile-repo/AGENTS.md.

Execute essas consultas no Rovo Chat. Se os documentos esperados (ou informações deles) aparecerem consistentemente entre as primeiras fontes citadas, seu Recall@k (com k pequeno, como 3 ou 5) é alto, indicando que a recuperação está funcionando bem.

4. Técnica de Teste Explícito: Saída Estruturada

Uma maneira poderosa de forçar o agente a provar de onde tirou suas informações é instruí-lo a retornar uma saída estruturada, como JSON. Esta técnica nos dá uma confirmação explícita da recuperação.

Podemos adaptar essa ideia para criar um prompt de teste que exige prova de recuperação:

PROJ-123: Analise a tarefa e as fontes de conhecimento relevantes. Responda em formato JSON com uma chave 'analysis' contendo sua análise e uma chave 'sources' que é uma lista de strings, onde cada string é a URL ou caminho do arquivo da fonte que você consultou (Google Drive e AGENTS.md).

Uma resposta bem-sucedida se pareceria com:

{
  "analysis": "A tarefa requer a implementação de uma nova regra de validação para nomes de usuário, conforme especificado nas regras de negócio. A implementação deve usar a biblioteca FluentValidation, de acordo com as diretrizes de arquitetura do repositório.",
  "sources": [
    "https://docs.google.com/document/d/...",
    "backend-repo/AGENTS.md"
  ]
}

Este método não deixa ambiguidade: se as fontes estiverem listadas, a recuperação ocorreu.

5. Diagnóstico e Melhoria (Introdução)

E se os testes falharem? Se o agente não conseguir encontrar os documentos corretos, o problema geralmente reside na forma como a informação está estruturada ou como a consulta é formulada.

Um vídeo prático ilustra problemas comuns de recuperação e como resolvê-los.

As principais conclusões são:

1. A recuperação pode falhar se houver uma incompatibilidade semântica ou lexical entre a consulta e o conteúdo do documento.
2. Podemos melhorar a recuperação seja melhorando o índice (ao segmentar e processar os documentos de forma mais inteligente) ou melhorando a consulta (ao reescrevê-la para ser mais precisa).

O Rovo já faz parte da melhoria da consulta através de sua camada de "Query Intelligence". A melhoria do índice é algo que exploraremos em detalhes na nossa próxima lição.

Exercício Prático

Vamos colocar a teoria em prática. Imagine que você está pronto para o primeiro teste real do seu agente com a seguinte tarefa:

• Ticket Jira: SEC-42: Implementar autenticação de dois fatores (2FA) para logins de usuários.
• Fonte 1 (Google Drive): Um documento chamado "Diretrizes de Negócio para 2FA" descreve os requisitos (ex: suporte para TOTP, códigos de backup).
• Fonte 2 (Git Repo): O arquivo AGENTS.md do repositório backend especifica que todos os novos recursos de segurança devem usar a biblioteca Company.Security.

Sua tarefa:

1. Escreva um prompt para o Rovo que teste sua capacidade de recuperar informações de ambas as fontes para esta tarefa.
2. Descreva como seria uma resposta "boa" do agente, indicando especificamente quais informações ele deveria ter extraído do Google Drive e do arquivo AGENTS.md.
3. Liste 2-3 consultas específicas e direcionadas que você poderia usar para criar um "conjunto de ouro" e avaliar a recuperação de cada fonte de forma independente.

Conclusão

Nesta lição, passamos da configuração à validação. Aprendemos a testar se nosso agente consegue recuperar informações de forma eficaz do Google Drive e dos repositórios de código, um passo crítico para garantir a confiabilidade de todo o sistema.

Principais Pontos:

• A recuperação de informações no Rovo é um processo sofisticado em várias camadas, combinando busca lexical, semântica e reclassificação.
• O teste interativo com prompts direcionados é a primeira linha de validação para garantir que o agente possa acessar e usar múltiplas fontes de conhecimento.
• A avaliação sistemática com métricas como Recall@k fornece uma medida quantitativa da qualidade da recuperação.
• Exigir saídas estruturadas (como JSON) é uma técnica explícita para forçar o agente a provar quais fontes ele consultou.
• Falhas de recuperação geralmente podem ser atribuídas a uma incompatibilidade entre a consulta e o conteúdo indexado.

Na Próxima Lição:

Tendo tocado no tópico de melhoria de índice, a próxima lição, Refinar estratégias de chunking e indexação com base na estrutura específica de documentos de negócio e arquivos de código, mergulhará fundo neste conceito. Exploraremos como a maneira que dividimos (chunk) e preparamos nossos documentos e código para indexação pode impactar dramaticamente a qualidade da recuperação, tornando nosso agente ainda mais preciso e eficaz.