Citações e fundamentação com Claude

Esta aula responde a uma pergunta que aparece em quase todo sistema que usa documentos: como fazer o modelo apontar, com precisão, de onde tirou cada afirmação? Pense num trabalho escolar. Uma boa bibliografia permite que o professor abra a fonte e confira a frase. Uma bibliografia escrita de cabeça pode ter autor trocado, página inventada ou um livro que nunca foi lido. Com modelos de linguagem acontece algo parecido. O modelo pode escrever “conforme o contrato, cláusula 4” com a mesma firmeza, quer a cláusula exista, quer não. Citação é o mecanismo que liga cada afirmação a um trecho real, para que quem lê possa conferir.

Esta aula trata de dois caminhos. O primeiro é pedir a citação no próprio prompt, como fiz no RAG da RAG (seções 10 a 12). O segundo é o recurso oficial de citações da API, em que a Anthropic extrai os trechos e devolve ponteiros estruturados. Vou explicar como cada um funciona, o que cada um garante, como o código lê o resultado e como medir a qualidade das citações com o que a Avaliação de RAG já ensinou. Para o recorte da busca, a Prompt e contexto mostra a montagem da mensagem que leva os documentos.

Mapa da aula

Pré-requisitos: 1.3 Mecânica da API Claude. Para o ciclo de chamada da API, veja a 4.1 Implementação de ferramentas. Os exemplos usam Python e o SDK oficial, e o código foi executado com um cliente simulado, como explico na seção 5.

1. O que é citar

Uma citação é um par. De um lado está uma afirmação que o modelo fez em texto livre. Do outro está um ponteiro para o trecho do documento que sustenta essa afirmação. O ponteiro pode ser um número de página, um intervalo de caracteres, um índice de bloco ou o título de uma fonte. O que importa é que ele seja verificável, ou seja, que alguém consiga ir até o trecho e ler.

Sem o ponteiro, a resposta vira uma afirmação de autoridade. Um assistente que diz “o prazo de troca é de 7 dias” pode estar certo por ter lido isso no documento, por ter adivinhado a partir do treino ou por misturar duas políticas diferentes. Quem recebe a resposta não tem como saber qual dos três casos aconteceu sem refazer a pesquisa inteira. Com o ponteiro, a checagem leva segundos: abre-se o trecho e lê-se a frase.

2. Por que a citação importa

A aula sobre LLMs já mostrou que o modelo não guarda uma lista de fontes para consultar depois. Ele gera texto com base no que aprendeu e no que está no contexto. Quando a resposta depende de um documento específico, a única forma confiável de saber se ela veio dele é pedir que o modelo marque a origem de cada frase, e depois conferir essa marca.

RAG resolveu isso com um truque simples: o prompt pede que cada afirmação termine com [1], [2] e assim por diante, e o índice aponta para um pedaço numerado no próprio prompt. Esse truque funciona, e RAG mostrou como validar os índices no código. Mas ele tem um limite importante. O [1] é texto que o modelo escreveu. Nada garante que o trecho apontado sustente a frase, e nada garante que o modelo copie o conteúdo do pedaço sem alterar uma vírgula. Por isso a validação de RAG confere só se o índice existe e se a frase tem algum índice. A pergunta mais importante, se o trecho diz mesmo aquilo, ficou para depois. O recurso oficial de citações tenta resolver justamente essa parte.

3. Dois jeitos de pedir a citação

O primeiro jeito é a citação pedida no prompt. Você escreve uma instrução como “cite o número do documento ao fim de cada afirmação” e recebe texto com marcadores. Esse jeito funciona com qualquer modelo, qualquer versão e qualquer provedor, porque depende só da obediência do modelo a uma instrução. Em contrapartida, o resultado é texto, e o seu código precisa interpretar esse texto para extrair as fontes.

O segundo jeito é a citação oficial, ativada por um parâmetro em cada documento. Você envia o documento com citations habilitado, e a resposta vem com blocos de texto que carregam uma lista de citações estruturadas. Cada citação diz qual documento, qual trecho e qual intervalo de caracteres, páginas ou blocos. Quem extrai o trecho e monta o ponteiro é a API, e não o modelo escrevendo texto.

Alguns exemplos mostram a diferença. Num atendimento sobre políticas de troca, com um arquivo de texto puro, o recurso oficial devolve um intervalo de caracteres. Num sistema de manuais em PDF, a citação vem com o número da página, e não com o intervalo de caracteres. Numa base de conhecimento que já tem busca própria, os resultados da busca são enviados como blocos search_result, e a citação aponta para um bloco desses. Em todos os três casos a aplicação recebe o ponteiro pronto, sem interpretar texto. Já a citação pedida no prompt serve para o caso em que você não pode usar o recurso oficial, por exemplo com um modelo que não aceita citações ou com saídas estruturadas (seção 9).

4. Como o recurso oficial funciona

Existem três passos. Primeiro você envia os documentos com citações habilitadas. Segundo a API divide o conteúdo em unidades citáveis, que dependem do tipo do documento. Terceiro o modelo responde com blocos de texto, e cada bloco pode trazer uma lista de citações que sustentam aquele trecho da resposta.

No envio, cada documento é um bloco do tipo document dentro de uma mensagem do usuário. Os campos que importam são source, que contém o conteúdo, title, que é o título do documento, context, que é metadado passado ao modelo mas que nunca é citado, e citations, que precisa ser {"enabled": true}. No exemplo abaixo, o texto é enviado inline, mas a documentação também aceita PDF em base64, uma URL, conteúdo em blocos (para documentos customizados) e referências ao Files API por file_id.

def bloco_documento(texto, titulo):
    return {
        "type": "document",
        "source": {"type": "text", "media_type": "text/plain", "data": texto},
        "title": titulo,
        "context": "Política publicada em 2026. Este contexto não é citável.",
        "citations": {"enabled": True},
    }

O segundo passo depende do tipo do documento, e esse detalhe é o que mais se erra na prática. Para texto puro, a API divide o conteúdo em frases, e a citação aponta para um intervalo de caracteres. Para PDF, o texto é extraído e dividido em frases, e a citação aponta para um intervalo de páginas numeradas a partir de 1. Para conteúdo customizado, a API não divide nada: cada bloco que você enviou é uma unidade, e a citação aponta para um intervalo de blocos. A documentação dá uma dica que vale para RAG. Se você quer que o modelo cite frases específicas de um pedaço recuperado pela busca, coloque cada pedaço num documento de texto puro. Se quer controlar exatamente a granularidade, use conteúdo customizado.

O terceiro passo é a resposta. O conteúdo vem como uma lista de blocos de texto, e alguns deles trazem citations. A afirmação fica no campo text do bloco, e a fonte fica na lista. Um mesmo parágrafo pode ter blocos sem citação, para ligações como “e”, e blocos com citação para afirmações sustentadas. A figura abaixo mostra o caminho do documento até a conferência, com as partes que a API faz e as que continuam sendo sua responsabilidade.

A figura tem quatro grupos, na ordem em que o trabalho acontece. Os dois retângulos laranja do grupo “Envio” são o que você controla, com o documento guardado e a requisição. O hexágono do modelo, no grupo “API”, é onde a extração e a divisão acontecem, e a seta pulsando marca o custo de processamento. A resposta e o losango azul do grupo “Sua aplicação” são o que você recebe e confere. A seta verde leva ao caso em que o trecho existe, e a seta pontilhada rosa leva ao caso em que a cópia guardada mudou em relação ao que foi indexado. Por fim, a seta pontilhada que sai de “Mostrar a fonte” para o juiz mostra o que a API não garante: a afirmação pode ter um trecho real e ainda assim não ser sustentada por ele. Esse é o assunto da seção 7.

5. Como o código lê as citações

Cada citação é um objeto com um campo type que diz qual tipo de localização ela descreve. Os tipos que a documentação lista para documentos são char_location, para texto puro, com start_char_index e end_char_index; page_location, para PDF, com start_page_number e end_page_number; e content_block_location, para conteúdo customizado, com start_block_index e end_block_index. Para resultados de busca existe search_result_location, que tem source, title, search_result_index, start_block_index e end_block_index. Há ainda web_search_result_location, usada pela ferramenta de busca na web, que esta aula não cobre. Em todos os tipos, o campo cited_text traz o texto citado e não conta como token de saída.

Os índices seguem convenções que precisam ser lembradas. O document_index é contado a partir de zero entre todos os blocos de documento da requisição, em todas as mensagens. Os índices de caracteres começam em zero e o fim é exclusivo. Os números de página começam em um, e o fim de página também é exclusivo. O search_result_index é a posição do resultado entre todos os blocos search_result da requisição.

O modo streaming manda as citações de outro jeito. Cada citação chega num evento content_block_delta com o tipo citations_delta, e cada evento traz uma única citação, que deve ser acrescentada à lista do bloco de texto atual. Quem renderiza a resposta conforme ela chega precisa tratar esse evento junto com os deltas de texto.

Para testar a leitura sem gastar chamadas, escrevi um cliente simulado. Ele não toca na rede. As respostas são roteirizadas por mim e montadas com o modelo Message do próprio SDK Python anthropic na versão 1.15.0, instalada em 18 de outubro de 2026. Com isso, o nome de cada campo é validado pelo pydantic do SDK. Esta é a função que decide se um trecho existe:

def conferir(c, docs_texto, resultados):
    if c.type == "char_location":
        fonte = docs_texto[c.document_index][c.start_char_index:c.end_char_index]
        return fonte == c.cited_text
    if c.type == "search_result_location":
        blocos = resultados[c.search_result_index][c.start_block_index:c.end_block_index]
        if not blocos:
            return False
        pos = 0
        for b in blocos:
            achou = c.cited_text.find(b, pos)
            if achou < 0:
                return False
            pos = achou + len(b)
        return True
    return False

A função confere o trecho contra a sua cópia guardada, e não contra alguma memória do modelo. Para texto puro, ela compara a fatia de caracteres com o cited_text. Para resultados de busca, a documentação não diz qual separador o campo cited_text usa quando junta vários blocos, então a função procura cada bloco em ordem, sem depender do separador. Os dois testes dependem de a API devolver cited_text exatamente igual ao trecho original, o que a documentação descreve, mas que não foi verificado contra a API real nesta aula.

A saída abaixo é a do script, sem edição. O script completo ficou na pasta de scratch da sessão e não foi copiado para a nota.

== cenário A: documento de texto puro com citations habilitado
  blocos enviados: ['document', 'text']
  afirmação: 'O frete de devolução é por conta do cliente e custa R$ 18,90.'
    char_location doc=0 [76:148] | trecho existe: True
  afirmação: 'Em troca por arrependimento, o prazo é de 7 dias corridos após o recebimento.'
    char_location doc=0 [0:75] | trecho existe: True

== cenário B: a cópia guardada do documento foi reindexada com outro valor
  char_location doc=0 [76:148] | trecho existe: False
  char_location doc=0 [0:75] | trecho existe: True

== cenário C: citação existe, mas a afirmação não é sustentada pelo trecho
  afirmação: 'A troca por arrependimento é gratuita.'
    trecho existe: True (a conferência não avalia a afirmação)

== cenário D: resultados de busca (search_result) e citação por bloco
  blocos enviados: ['search_result', 'search_result', 'text']
  afirmação: 'O frete de devolução é por conta do cliente e custa R$ 18,90.'
    search_result_location res=0 blocos=[1:2] | trecho existe: True

== cenário E: citação pedida no prompt, conferida por busca de texto
  trecho copiado pelo modelo existe na política: True  ('ta R$ 18,90.')
  trecho copiado pelo modelo existe na política: False  ('sta R$18,90.')
  O mesmo teste sem o espaço do 'R$' falha, sem nenhum erro da API: o trecho virou texto livre.

== cenário F: erros de forma na requisição, pegos antes do envio
  rejeitado: search_result: content precisa ser lista de blocos de texto não vazios
  rejeitado: document: faltam [], sobram ['citacoes']

== cenário G: resposta com nome de campo errado é rejeitada pelo SDK
  rejeitado pelo SDK: ValidationError

Diagnóstico do cliente: nenhum dos cenários chamou a API real.

O cenário B mostra o caso que mais interessa a quem mantém o sistema. A citação não mudou, mas a cópia guardada mudou, porque alguém reindexou o documento com outro valor. Sem a conferência, a resposta mostraria a fonte de um trecho que já não existe nela. Com a conferência, o problema aparece antes de chegar ao usuário.

6. Resultados de busca como fonte

Num RAG, quem já faz a busca tem os trechos em mãos. Em vez de transformá-los em documentos, o recurso permite enviá-los como blocos search_result, que são citáveis do mesmo jeito. Um bloco desses tem type igual a "search_result", source com um identificador estável (uma URL ou algo como kb://artigo-1234), title com um título descritivo, content com uma lista de blocos de texto e citations com enabled igual a true. Segundo a documentação consultada, todos os modelos ativos suportam isso, exceto o Claude Haiku 3, e nenhum cabeçalho beta é necessário.

Há duas formas de chegar a esse bloco. Na primeira, uma ferramenta própria devolve resultados de busca, e o laço da aplicação os envia como tool_result. Na segunda, os resultados já vêm prontos e entram direto numa mensagem do usuário, como acontece com um cache de buscas ou com um serviço de busca externo. As duas formas usam o mesmo tipo de citação na resposta.

Há uma diferença de granularidade que muda o resultado. A citação de um bloco search_result aponta para blocos inteiros do content, e não para frases. Se um resultado tem um único bloco com três parágrafos, toda citação devolve os três parágrafos. Se o mesmo resultado tem três blocos, cada um com um parágrafo, a citação devolve só o bloco certo. A documentação recomenda dividir o conteúdo em blocos menores para dar à citação limites mais finos.

A documentação também fixa algumas regras que podem quebrar um sistema. Blocos search_result só podem aparecer em mensagens do usuário, incluindo dentro de tool_result. Dentro de um tool_result, se um bloco for search_result, todos os blocos daquele resultado precisam ser search_result, e misturar tipos gera erro de validação. Quando a ferramenta de busca na web está ativa na mesma requisição, a citação precisa estar habilitada em todos os blocos search_result. E o conteúdo dos resultados aceita apenas texto, sem imagens.

Se a busca não devolve nada, a documentação recomenda devolver um bloco de texto dizendo isso, e não lançar uma exceção. Assim o modelo consegue explicar o resultado vazio ao usuário e a conversa continua. Esse ponto liga esta aula ao que a aula sobre Prompt e contexto chama de recusa: a ausência de fonte precisa ser um dado da conversa, e não um erro que quebra o fluxo.

7. O que a citação garante

Esta é a parte que mais se confunde. Uma citação oficial garante que o ponteiro é válido, ou seja, que ele aponta para um trecho existente no documento enviado. A documentação diz isso com todas as letras ao comparar o recurso com a citação por prompt: a API extrai o cited_text diretamente e os ponteiros são válidos. Na prática, isso significa que você pode confiar no formato do ponteiro, sem ter de procurar o trecho no texto, e que um ponteiro quebrado indica um problema de versão ou de cópia, como no cenário B.

A citação não garante que a afirmação esteja certa. Ela não garante que o trecho citado seja o mais relevante, nem que a afirmação seja uma leitura fiel do trecho. O modelo escolhe qual trecho cita, e a API só garante que a citação aponta para algo real. O cenário C mostra o caso. A afirmação “a troca por arrependimento é gratuita” recebeu como fonte um trecho que fala de produtos com defeito. O ponteiro existe, a conferência de existência passa, e a afirmação está errada. Nada no código de existência percebe isso.

Essa distinção organiza toda a medição. Existência é uma propriedade que se confere sem julgamento, com código. Sustentação, que é se a afirmação decorre do trecho, exige julgamento, seja de um humano, seja de um modelo juiz. A Avaliação de RAG chama essa segunda propriedade de fidelidade (seção 5 daquela aula), e a auditoria de citações da seção 6 separa as duas falhas. A citação oficial resolve a primeira. A segunda continua sendo trabalho de avaliação.

Vale notar também o que a documentação não diz. Ela afirma que, nas avaliações internas da Anthropic, o recurso de citações tende a escolher trechos mais relevantes do que a citação por prompt. Não encontrei nesta consulta um número público que permita reproduzir essa comparação, e não a medi. Por isso a afirmação fica como alegação do fornecedor.

8. Recurso oficial contra o prompt

Os dois caminhos resolvem partes diferentes do problema. A tabela compara o que cada um entrega, usando o que foi verificado nesta aula ou está escrito na documentação.

A tabela sugere uma regra prática. Use a citação oficial quando precisar do ponteiro estruturado e a aplicação for ler o resultado por código. Use a citação por prompt quando precisar de saída estruturada num contrato rígido, ou quando estiver com um modelo ou provedor que não oferece o recurso. Nos dois casos, a verificação da afirmação continua sendo sua.

9. Limites e custos

A primeira limitação é a incompatibilidade com saídas estruturadas. A documentação diz que citações não podem ser usadas junto com saídas estruturadas. Se você habilitar citações em um bloco document ou search_result e também enviar o parâmetro output_config.format (ou o antigo output_format), a API responde com erro 400. A razão é que as citações precisam ser intercaladas com o texto da resposta, e o esquema JSON estrito não aceita isso. Esta mesma restrição aparece em RAG, e agora ela tem a fonte oficial.

A segunda é a regra de tudo ou nada. As citações precisam estar habilitadas em todos os documentos de uma requisição, ou em nenhum. Misturar documentos com e sem citação gera erro. O mesmo vale para os blocos search_result.

A terceira é o custo. Habilitar citações aumenta levemente os tokens de entrada, porque a API adiciona instruções ao sistema e divide o documento em unidades. Em compensação, o cited_text não conta como token de saída, e também não conta como token de entrada quando volta em turnos seguintes da conversa. A documentação diz que o recurso é eficiente em tokens de saída. Não medi esse custo contra a API real nesta aula, então o efeito em dinheiro fica sem número.

A quarta é o cache de prompt. Você pode aplicar cache_control ao bloco do documento para reaproveitar o conteúdo entre requisições. O bloco de citação em si não pode ser colocado em cache, mas o documento que ele referencia pode. Isso importa para o custo de um RAG com o mesmo corpus repetido. Para entender o mecanismo de cache, veja a seção 17 da Prompt e contexto.

Por fim, a documentação diz que o recurso funciona com lote (Batch) e com contagem de tokens. Não testei nenhum dos dois nesta aula.

10. Medir a qualidade das citações

Medir citação é medir três coisas diferentes, e cada uma tem um instrumento. A primeira é a validade do ponteiro. Ela é a proporção de citações cujo trecho existe na cópia que você guardou, conferida pela função da seção 5. No caminho oficial, o esperado é 100 por cento, e qualquer falha indica bug de indexação ou cópia desatualizada. Esse número é barato, roda em toda requisição e deveria ser um alarme.

A segunda é a fidelidade, ou seja, a fração das afirmações que são sustentadas pelo trecho citado. Esta é a métrica que a Avaliação de RAG define na seção 5 como fidelidade ou groundedness. O procedimento é o mesmo da aula: separar as afirmações da resposta, conferir cada uma contra o trecho citado e dividir as sustentadas pelo total. Para um conjunto grande, o juiz pode ser um modelo com um prompt fechado, mas a seção 8 da Avaliação mostra por que é preciso calibrar esse juiz contra pessoas antes de confiar nele. Nesta aula não rodei nenhum juiz, então não há número de fidelidade.

A terceira é a cobertura e a recusa. A cobertura é a fração de afirmações factuais que trazem alguma citação. Afirmações de ligação, como “em resumo”, não precisam de fonte, então o alvo é a fração das afirmações factuais, e não de todas as frases. A recusa é o comportamento em perguntas sem resposta no acervo. Se o modelo cita um trecho e afirma algo em cima dele, há erro. Se diz que não encontrou a resposta, a citação não se aplica, e a validação de recusa segue o que a seção 6 da Avaliação descreve.

Essas três medidas entram no mesmo conjunto de perguntas que você já mantém para o RAG. Com 56 perguntas, como no laboratório de RAG, o ruído de uma taxa é de 8 a 13 pontos percentuais, então diferenças menores entre duas versões não significam nada sem um teste pareado. A ordem de diagnóstico importa também. Primeiro meça a recuperação, com o hit@k da seção 3 da Avaliação, porque um trecho que nunca entrou no prompt não pode ser citado. Depois meça a citação, com as três métricas acima. Se a fidelidade cai e a recuperação está boa, o problema está no modelo ou no prompt. Se a fidelidade cai junto com o hit@k, o problema está na busca.

11. Erros comuns e boas práticas

O primeiro erro é tratar a citação oficial como prova de que a resposta está certa. Ela prova que o ponteiro é real. Quem apresenta a fonte ao usuário precisa saber que a fonte pode não sustentar a afirmação, e a seção 7 explica o motivo.

O segundo erro é indexar o documento e depois alterá-lo sem reindexar as citações. A citação guarda índices de caracteres ou de blocos. Se o texto guardado mudar de tamanho ou de ordem, o índice aponta para outro lugar, e a conferência do cenário B é a única coisa que detecta isso. A boa prática é guardar o documento com uma versão e recalcular as citações sempre que a versão mudar.

O terceiro erro é misturar tipos de documento e esquecer a granularidade. Um PDF gera citações por página, e um texto puro gera citações por caractere. Se o seu código espera um campo que só existe num dos dois tipos, ele quebra sem aviso. A boa prática é ler o campo type antes de qualquer outra coisa, como faz a função da seção 5.

O quarto erro é enviar um resultado de busca grande como um único bloco e esperar citações finas. Como a citação aponta para blocos inteiros, o usuário recebe um parágrafo enorme como fonte. A prática recomendada é dividir o conteúdo em blocos com um assunto cada.

O quinto erro é habilitar citações e saídas estruturadas na mesma requisição. O erro 400 aparece só na chamada, e não em testes de montagem do prompt. Quem escreve o contrato de saída precisa saber que esse par não funciona, ou escolher um dos dois caminhos.

O sexto erro é pedir ao modelo, no prompt, que cite e também habilitar o recurso oficial. O resultado fica duplicado e confuso, porque o texto traz marcadores e a lista traz ponteiros. Escolha um caminho por requisição.

A boa prática geral é esta: use o recurso oficial quando o código precisa ler a fonte, confira a existência do ponteiro sempre, meça a fidelidade com a Avaliação de RAG e não confunda as duas medidas.

12. Prática, glossário e fontes

Os exercícios abaixo usam o script da seção 5. Faça-os na ordem.

O primeiro exercício é trocar o texto do documento por uma versão em que um valor muda de tamanho, por exemplo de “18,90” para “189,00”. Rode o cenário B de novo e explique por que a conferência por fatia de caracteres falha nesse caso, e o que aconteceria se você usasse só a comparação de texto sem índices.

O segundo exercício é escrever um caso com citação do tipo page_location para um PDF, usando o mesmo modelo Message do SDK. Acrescente uma função de conferência que receba o texto de cada página e confira se o cited_text aparece entre as páginas indicadas, e explique por que os números de página começam em um.

O terceiro exercício é montar um conjunto de 20 perguntas sobre o seu próprio acervo, com a frase-resposta de cada uma, e medir as três métricas da seção 10 com um juiz simples, como uma verificação por palavras-chave, antes de qualquer modelo juiz. Compare o resultado com a recuperação medida pelo hit@k e registre quantas falhas de fidelidade acontecem em perguntas em que o trecho certo nem entrou no prompt.

Glossário.

citação: par formado por uma afirmação e um ponteiro verificável para o trecho que a sustenta.

ponteiro: a localização de um trecho dentro de um documento, dada por caracteres, páginas, blocos ou um índice de resultado.

document: bloco de uma mensagem do usuário que envia um documento ao modelo, com source, title, context e citations.

search_result: bloco que envia um resultado de busca com source, title e uma lista de blocos de texto, citável por bloco.

char_location: tipo de citação para texto puro, com índices de caracteres de início e fim exclusivo, contados a partir de zero.

page_location: tipo de citação para PDF, com números de página a partir de um e fim exclusivo.

content_block_location: tipo de citação para conteúdo customizado, com índices de blocos a partir de zero.

search_result_location: tipo de citação para resultados de busca, com search_result_index e índices de bloco.

citations_delta: evento de streaming que traz uma citação para o bloco de texto atual.

cited_text: texto citado, que a API devolve junto do ponteiro e que não conta como token de saída.

existência: propriedade do ponteiro de apontar para um trecho real do documento enviado. Pode ser conferida por código.

sustentação: propriedade da afirmação de decorrer do trecho citado. Exige julgamento humano ou de um modelo juiz.

Fontes.

Consultadas em 18 de outubro de 2026, na documentação oficial da Anthropic:

• Citações (tipos de localização, campos, streaming, custos, incompatibilidade com saídas estruturadas): https://platform.claude.com/docs/en/build-with-claude/citations
• Resultados de busca (blocos search_result, search_result_location, limitações): https://platform.claude.com/docs/en/build-with-claude/search-results

As duas páginas são longas, e a leitura cobriu as seções sobre o funcionamento, os tipos de documento, a estrutura da resposta, o streaming, os resultados de busca, os limites e os custos. Não li integralmente os exemplos de linguagens que não são Python. O identificador de modelo usado no código é claude-haiku-5-5, que é o nome deste modelo. Os exemplos da documentação usam outro identificador, e não confirmei nas páginas consultadas se claude-haiku-5-5 aceita todos os recursos descritos aqui.

O que não foi verificado: nenhuma chamada à API real foi feita, e por isso não confirmei que cited_text vem exatamente igual ao trecho original em todos os casos, nem como os separadores são aplicados em blocos múltiplos de resultados de busca. Não medi a fidelidade de nenhuma resposta gerada por modelo, nem o custo em dólares. As afirmações sobre a comparação de qualidade com a citação por prompt são alegações da documentação, e não medidas desta aula. A seção sobre PDF foi descrita a partir da tabela de tipos e não foi testada.

Relacionados

• RAG
• Avaliação de RAG
• Prompt e contexto