Como está
nosso experimento.
Comparar cinco hipóteses nos 1.000 documentos reservados do FINDSum: medir, com ROUGE e BERTScore, quanto cada resumo gerado se aproxima da referência.
O experimento
Ling Flash Fin, Qwen3.7 Flash e Gemma 4 26B A4B. Os mesmos 1.000 casos em C1, C1t, C2, C3, C4 e C5. Fonte com prosa e tabelas brutas; avaliação textual por referência.
As últimas correções
Filtro financeiro das tabelas removido. Métricas numéricas e revisão humana retiradas do fluxo padrão. Sorteio reproduzível e registro de IDs no preparo full. Plano de comparação atualizado.
Fechar a execução
Dev10 integrado concluído: 180 respostas e métricas calculadas. Agora, preparar todos os prompts dos 1.000 casos e congelar configuração e orçamento antes do full.
Vamos observar escores, médias, medianas e diferenças entre configurações. Resultados ruins e ausência de diferença significativa também são resultados do experimento. Nenhuma hipótese está confirmada.
O que já rodou: histórico do dev com 50 documentos
900 tentativas de geração; 898 respostas completas; custo reportado de US$ 1,25, incluindo calibração Qwen. Duas respostas do Ling atingiram o limite.
Essa execução usou o filtro anterior, que excluiu todas as tabelas auditadas. Os arquivos permanecem intactos. Ela não é uma execução da entrada corrigida nem uma avaliação das hipóteses com ROUGE/BERTScore completos.
Na revisão do código, 249 testes passaram, excluindo slow e dados reais. Testes de software não substituem a execução do experimento.
Como ler este guia: o fluxo e as métricas descrevem o desenho atual. Os 54 prompts e as saídas do explorador são artefatos reais do dev anterior, identificados como históricos. Os prompts finais com tabelas ainda precisam ser preparados e validados.
Leia os resumos dos três modelos
Rodada concluída: 180 respostas dos mesmos dez documentos nos seis braços, tabelas preservadas e BERTScore integral com XLNet. Um caso Gemma encerrou por limite e foi preservado; os demais 179 terminaram normalmente. Custo total com calibração: US$ 0,2052. Orientação de até 750 palavras mantida.
Um caso real, da entrada à saída
GOOD-0001683168-21-001122, sorteado no dev. Seis braços executados no Ling gratuito com tabelas preservadas. ROUGE e BERTScore calculados; a auditoria identificou corte de textos longos na janela do avaliador BERTScore, descrito na página.
Abrir o exemplo completo: dados, RAG, few-shot, prompts, respostas e métricas →
O caminho de um relatório
Preparação, embeddings e métricas ficam na máquina local. A geração dos resumos acontece pelo OpenRouter.
O que é enviado para geração
Instruções + contexto do relatório-alvo + quatro pares de demonstração, quando o braço usa few-shot.
C1, C1t e C2 recebem zero exemplos. C3, C4 e C5 recebem quatro.
Onde fica o resumo de referência
A referência do alvo fica do lado da avaliação. Ela não é a consulta do RAG e não entra no prompt do alvo.
As referências de outras empresas do conjunto examples entram nas demonstrações de C3–C5.
O que chamamos de “documento”
Usamos a tarefa Liquidity do FINDSum: liquidez, fluxos de caixa, dívida e recursos de capital de relatórios anuais em inglês.
O corpus já traz conteúdo selecionado do 10-K. “Fonte inteira” significa esse extrato concatenado, com as tabelas brutas da seção da tarefa. Não significa buscar ou enviar o 10-K original completo.
Reconstrução da entrada
A linha r dos arquivos segment_0, segment_1 e segment_2 pertence ao mesmo relatório. Concatenamos nessa ordem.
As três partes do resumo de referência também são concatenadas. Cada relatório continua sendo um único caso.
O JSON de tuplas da mesma linha fornece ticker, accession number e tabelas. O ID é ticker + accession.
Separação experimental
O código combina os splits originais train/val/test, mantém um relatório por empresa — o mais recente entre os elegíveis — e reparte por empresa com semente 42.
Há filtro inicial de referência com pelo menos 100 palavras e presença de identificadores. Esse filtro de integridade não é uma validação da janela dos prompts.
A comparação principal é interna ao nosso desenho. Não é o mesmo split oficial de uma avaliação publicada do FINDSum.
| Conjunto | Documentos / empresas | Uso | Estado |
|---|---|---|---|
| examples | 1.000 / 1.000 | Banco de pares documento + referência para os quatro exemplos. | Usado no dev. |
| dev | 500 / 500 | Correções, checagens e piloto. Última rodada usou os primeiros 50 do manifesto. | 50 executados, não os 500. |
| eval | 1.000 / 1.000 | Os 1.000 casos da avaliação final, em empresas separadas dos demais conjuntos. | Sem geração final. |
O dev50 começa em ABEO-0001493152-21-006705 e termina em BCDAW-0001437749-20-007405. Não foi selecionado pelo resultado dos resumos. Os tamanhos e IDs acima vêm do manifesto real.
Sorteio sem reposição, semente 42, dentro do split reservado. O script grava IDs, empresa, relatório, origem e ordem em selected-cases.csv e selection.json. No full, usar os 1.000 de um eval com 1.000 muda apenas a ordem; não troca empresas nem seleciona os melhores resultados.
Ver caminhos e origem dos registros
data/raw/findsum/
text/FINDSum-Liquidity/liquidity_input_2000/
{train,val,test}_liquidity_segment_{0,1,2}_input_2_1000.csv
table/FINDSum-Liquidity/
{train,val,test}_liquidity_all_tuples_diff_sec.txt
data/interim/splits-liquidity.jsonEmpresas não se repetem entre os conjuntos do manifesto. O full continua avaliando empresas reservadas dentro do FINDSum; não demonstra generalização a outro corpus, idioma ou domínio.
Tabelas preservadas; filtro anterior removido
O filtro antigo exigia um rótulo de coluna preenchido. Na amostra auditada, todas as células têm esse campo vazio.
Uma célula real de ABEO
Formato: [linha, coluna, valor, data, posição da linha, posição da coluna]. O campo de valor junta duas representações com &; a tupla não explicita a conversão.
O que o filtro fez
Exigiu linha, coluna, período, valor atômico e unidade explícita; também rejeitou conflitos e descrições de direção ambígua.
Células auditadas → células elegíveis no dev50. A prosa continuou disponível e foi a fonte efetiva dos seis braços.
Isso não prova que as 9.448 células sejam inúteis. O campo de coluna vazio, sozinho, já excluiu todas. Parte do problema está no critério adotado pelo nosso filtro.
Uma célula pode ter vários motivos; as contagens não devem ser somadas como células distintas. Os dados brutos foram preservados em table-audit.json.
O filtro não era exigido pelo planejamento e foi removido. Serializamos os valores como vieram no dataset, sem validar montantes, converter unidades ou eliminar conflitos. A nova preparação usará prosa e tabelas da tarefa. Os prompts abaixo são históricos: ainda refletem o dev com tabelas excluídas.
RAG dentro do relatório-alvo
Uma consulta fixa sobre a tarefa procura os trechos semanticamente mais próximos dentro da fonte daquele relatório.
Respeitar as passagens do corpus. Passagens longas são divididas em até 220 palavras, com 40 palavras de sobreposição.
sentence-transformers/all-MiniLM-L6-v2. Textos longos são cobertos por janelas que cabem no encoder; os vetores são agregados por média ponderada e normalizados.
FAISS IndexFlatIP, busca exata. Com vetores normalizados, produto interno equivale à similaridade de cosseno.
Preservar a ordem de similaridade, numerar os trechos e ajustar o contexto para até 3.072 tokens, compartilhado por C2–C5.
A consulta real do RAG
É o texto da instrução de Liquidity. Não é o resumo de referência. O embedding do relatório inteiro tem outra função: selecionar exemplos em C5.
Dois limites diferentes
220 palavras define o tamanho dos trechos; 3.072 tokens limita o contexto recuperado. Não são unidades equivalentes.
Doze candidatos não garantem doze trechos inteiros no prompt: o orçamento pode reduzir o contexto. O corte tenta preservar células tabulares completas.
Não há reranker, busca híbrida, consulta gerada pela LLM ou treinamento adicional neste fluxo.
Os exemplos não alteram a recuperação do alvo. Entre modelos, o ajuste por tokenizer pode produzir fronteiras diferentes; não afirmamos que o texto final do contexto seja idêntico nos três.
Quatro demonstrações, três formas de escolher
Cada demonstração contém a prosa completa de outro relatório do conjunto examples e o seu resumo de referência. As tabelas desse banco não são carregadas.
Os mesmos quatro
Ordenar o banco por doc_id e pegar os quatro primeiros, excluindo o próprio alvo. Não são exemplos escolhidos manualmente pela qualidade.
Sorteio reproduzível
Sortear quatro pares usando a semente 42:doc_id. Muda de um alvo para outro, mas pode ser reproduzido. Não é um novo sorteio em cada retry.
Vizinhos semânticos
Comparar o vetor da prosa inteira do alvo com os vetores dos documentos do banco. Selecionar os quatro mais similares, excluindo o próprio alvo. A referência não participa dessa busca.
No dev corrigido, example_max_words: null e referência integral. Esses exemplos podem consumir mais tokens que o próprio contexto recuperado. IDs são preservados por caso e compartilhados entre as preparações dos modelos.
Por que delimitar EXAMPLES e TARGET_REPORT?
Exemplos ensinam a forma da tarefa; seus fatos pertencem a outras empresas. O prompt declara que somente TARGET_REPORT é evidência sobre o alvo. Mesmo assim, o Ling copiou fatos dos exemplos em um caso inspecionado. Isso fica como resultado do modelo, sem reescrever a saída.
Uma referência demonstrativa pode conter informação ausente da prosa do exemplo. Manter texto integral evita truncamento artificial, mas não resolve automaticamente essa limitação do corpus.
O que muda entre os seis braços
A instrução de sumarização é a mesma. Mudam a origem do contexto e a presença ou identidade das quatro demonstrações.
| Braço | Contexto do alvo | Exemplos | Função na comparação |
|---|---|---|---|
| C1 | Fonte inteira disponível, sem duplicação pelos chunks. | 0 | Baseline de entrada completa. |
| C1t | Prefixo da fonte, com tokens iguais aos de C2. | 0 | Controle da quantidade de contexto. |
| C2 | Trechos recuperados por RAG. | 0 | Efeito da recuperação. |
| C3 | Mesmo contexto de C2. | 4 fixos | Efeito de incluir demonstrações. |
| C4 | Mesmo contexto de C2. | 4 aleatórios | Sensibilidade à identidade dos exemplos. |
| C5 | Mesmo contexto de C2. | 4 similares | Efeito da seleção semântica. |
O ajuste reduz os prefixos até igualar as duas contagens. O teto de 3.072 tokens pode não ser atingido exatamente. Não igualamos o tamanho total de C2 com C3–C5: os quatro exemplos são justamente parte da intervenção.
Use o explorador para entender a estrutura, o contexto e as demonstrações. Estes prompts foram executados quando o filtro ainda excluía as tabelas; não foram regenerados com a entrada corrigida.
O prompt que foi enviado
Escolha um modelo, um dos três documentos de demonstração e um braço. Os conteúdos vêm dos preflights e das respostas salvas, sem reconstrução inventada.
Mensagem system — instrução compartilhada integral
Mensagem user — conteúdo exato do caso selecionado
O painel tem rolagem própria. Nada foi abreviado no conteúdo copiado ou baixado. O JSON contém as duas mensagens, não inclui credenciais.
Contexto do alvo isolado — sem os exemplos
Candidatos do RAG antes do ajuste de tokens
Ordem de recuperação salva. As notas de similaridade não foram persistidas neste artefato; não mostramos scores inventados.
Saída real do modelo para este prompt
Mantida como gerada. Não é uma resposta revisada ou corrigida para apresentação.
ABEO ilustra uma entrada típica; ACET contém a ocorrência de mistura de exemplos do Ling em C4; ADEX permite observar abstenção mesmo com alguma informação financeira disponível. São exemplos dirigidos para explicar o fluxo, não uma amostra para estimar qualidade.
Caber no prompt é uma condição verificável
O limite precisa considerar a mensagem de sistema, instruções, quatro exemplos completos, contexto, template de chat e espaço reservado para a resposta.
tokens_do_prompt + limite_da_saída + margem ≤ janela_do_endpoint C1 preserva a fonte inteira disponível. C1t e C2 limitam o contexto de propósito, pelo desenho experimental. O preflight não corta o prompt inteiro para fazê-lo caber.
Como contamos no dev
Ling e Gemma: tokenizer e template locais, com conferência posterior contra usage.prompt_tokens da API.
Qwen3.7: sondas na API medem cada prompt. Para contexto, usamos o incremento de tokens em uma mensagem fixa, descontando a mensagem vazia. Não temos IDs de tokens nativos locais desse modelo.
A equivalência entre as duas medidas de contexto não foi demonstrada. Os contrastes são pareados dentro de cada modelo.
O manifesto não garante a janela
A divisão inicial separou empresas e registros. Os tokens finais dependem dos exemplos escolhidos e do tokenizer do modelo.
A preparação do full deve verificar os seis braços nos três modelos e congelar uma seleção comum de casos elegíveis antes de gerar resumos. Excluídos terão IDs e motivos registrados; o manifesto original permanece intacto.
Simulador de janela · sem chamadas à API
Use os endpoints configurados como referência. Este simulador ilustra a regra; não substitui a contagem real de cada prompt nem valida disponibilidade atual do provedor.
| Aspecto | Dev executado | Full em organização |
|---|---|---|
| Limite de saída | 3.072 tokens em todos os braços. | Rascunho usa 8.192 em todos os braços. Ainda não validado em execução. |
| Instrução de extensão | Até 750 palavras. | Mantida. Um teto em tokens maior não muda a instrução em palavras. |
| Retentativas | Até seis tentativas para HTTP 429; esperas 1, 2, 4, 8, 16 s, respeitando Retry-After. | Ampliar para falhas transitórias definidas, com registro e teto de custo. |
| Falha de contexto | Overflow bloqueia antes de gerar. | Preflight completo + coorte comum; não resolver cortando C1 silenciosamente. |
Resposta length | Rejeitada como incompleta; bruta preservada. O Ling teve duas. | Proposta: preservar e pontuar como observada, sinalizando truncamento. Falta integrar essa regra ao executor/exportador. |
| Retomada | Ledger, hashes, respostas salvas e reaproveitamento das chamadas concluídas. | Generalizar de 5/50 documentos para a seleção final congelada. |
HTTP 429 é uma falha transitória de acesso. finish_reason=length é uma resposta que atingiu o limite de geração. Entrada que cabe e saída reservada evitam overflow, mas não garantem obediência à instrução de 750 palavras. Não vamos escolher documentos pelo comportamento favorável da resposta.
Camada operacional adicional
- Provedor fixo, sem fallback automático para outro endpoint.
- Temperature 0, reasoning desativado; seed não enviada à API. A semente 42 controla as seleções locais.
- Limite de 20 requisições por minuto no controle do free tier; uma requisição não é um documento: cada documento tem seis braços, e retries também contam.
- Cota diária e limitação temporária do provedor são causas distintas de 429. Créditos pagos não garantem disponibilidade do pool gratuito.
- Ling pago/DeepInfra continua sendo uma contingência separada, previamente autorizada para esgotamento diário. Não deve ser misturado silenciosamente com Novita no mesmo bloco experimental.
- Erros permanentes de configuração ou autenticação não se resolvem por retries indefinidos. Timeouts podem ter custo mesmo sem resposta recebida.
O que vamos medir
O DOCX nomeia ROUGE e BERTScore. Pela decisão atual, os complementos numéricos/factuais foram retirados: não haverá F1 numérico, grounding nem revisão humana. ROUGE-L como endpoint é uma escolha operacional; o DOCX não especifica variantes.
| Métrica | O que compara | Interpretação e limite |
|---|---|---|
| BERTScore F1 | Resumo gerado × referência. | Similaridade contextual; não comprova correção de números, períodos ou fatos. Implementação atual usa XLNet-base-cased, camada 5, sem reescala; auditoria rejeita qualquer corte de tokens. |
| ROUGE-L F1 | Resumo gerado × referência. | Sobreposição pela subsequência comum mais longa. Endpoint textual dos cinco contrastes, junto com BERTScore. |
| ROUGE-1 / ROUGE-2 F1 | Sobreposição de palavras e pares de palavras com a referência. | Também reportados, descritivamente, por documento e por configuração. |
| Operacionais | Tokens, custo, completude, extensão e erros. | Medem funcionamento e custo. Não substituem as métricas da tarefa. |
Cinco contrastes operacionais
O DOCX descreve cinco configurações e uma hipótese geral. Estes contrastes detalham o desenho, com C1t como controle adicional.
| H1 | C2 − C1 | RAG versus fonte inteira. |
| H1b | C2 − C1t | Recuperação com orçamento controlado. |
| H2 | C3 − C2 | Presença dos quatro exemplos. |
| H3 | C4 − C3 | Sensibilidade à identidade dos exemplos. |
| H4 | C5 − C4 | Seleção semântica versus aleatória. |
Análise prevista no código
Cinco contrastes × duas métricas primárias = dez testes bilaterais de Wilcoxon por análise. Correção de Holm, alfa 0,05. Dados incompletos são rejeitados pelo comparador atual.
H3 não testa equivalência. Um resultado não significativo significa que não detectamos diferença sob esse teste; não prova que os métodos sejam iguais.
A família de dez testes será separada por modelo. Não sustenta uma conclusão conjunta entre modelos. Além dos testes, apresentar médias, medianas, distribuições e deltas emparelhados dos escores.
O dev10 usa o executor integrado, ROUGE e BERTScore com cobertura integral. A página da rodada mostra os resultados reais; não depende de obter significância.
Vamos medir quão próximos os resumos ficam das referências, lexical e semanticamente. Esses escores não são porcentagem de correção factual. A avaliação numérica está fora do escopo.
Resultados operacionais do último dev
¹ Contagens de palavras entre respostas aceitas tecnicamente; não incluem as duas saídas truncadas do Ling.
Custos são os reportados pela API nesta rodada, sem taxas de compra de créditos. Qwen: US$ 0,4632 de geração + US$ 0,5061 de calibração. Não são estimativas do preço futuro do full.
Ling: 298 completas, duas truncadas em C5. Gemma: 68 respostas abaixo de 50 palavras. Qwen: três acima de 750 palavras. Essas contagens descrevem comportamentos, não medem diretamente factualidade.
Decidido, em implementação e em aberto
A avaliação final permanece sem execução. O plano abaixo mostra o estado atual, inclusive o que ainda não está pronto.
O desenho que seguimos
- Ling Flash Fin gratuito, Qwen3.7 Flash/Alibaba e Gemma26/Darkbloom.
- Seis braços em cada modelo.
- Os mesmos 1.000 documentos reservados entre braços e modelos.
- Retries limitados para falhas transitórias.
- ROUGE e BERTScore, sem avaliação numérica/factual ou revisão humana.
- Manifesto original preservado.
Executor integrado
- Preparação dos três modelos integrada, inclusive sondas Qwen.
- Exigir preflight completo nos 1.000 casos, seis braços e três modelos; bloquear incompatibilidades sem reduzir a amostra.
- Executor generalizado, com retries, retomada e exportação.
- BERTScore integral e comparações conectados aos controles de completude.
- 180 resultados com métricas e cobertura integral conferidos no dev10.
Preparar os 1.000 casos
- Tabelas brutas preservadas, sem filtrar números. Revalidar todos os prompts da coorte final.
- Respostas encerradas por limite serão mantidas, sinalizadas e avaliadas como produzidas.
- Dev10 integrado concluído; congelar versões e configuração para o full.
- Orçamento de geração e calibração após o preflight final.
Escala pretendida
1.000 documentos × 6 braços × 3 modelos = 18.000 resumos.
Todos os 1.000 devem caber nos prompts completos. Se algum falhar, o preflight bloqueia a execução para resolver a incompatibilidade antes de gerar. Não reduzimos a amostra silenciosamente. Sondas Qwen e retries são chamadas adicionais; resultados ruins não justificam substituição de casos.
O rascunho está em configs/full_openrouter.yaml, configs/openrouter_full.json, scripts/full_common.py e scripts/prepare_full_openrouter.py. O executor integrado está em scripts/run_experiment_openrouter.py; a rodada dev10 documenta sua validação. O comando principal findsum run não foi apresentado aqui como uma integração paga pronta para o full.
Fonte definida: prosa e tabelas brutas → conferir a execução integrada e as métricas no dev10 → prevalidar os prompts da avaliação → congelar coorte, configurações e orçamento → executar o full quando autorizado. Não há necessidade de continuar ajustando prompts para buscar resultados melhores.
De onde vêm estas informações
O guia foi revisado após reler o DOCX original, e montado lendo o código, o manifesto e os artefatos do último dev. Ele é um snapshot, não um painel conectado à API.
Glossário rápido
Prosa: o texto corrido do relatório. Fonte disponível: o material após o pré-processamento. Contexto entregue: a parte dessa fonte que entra no prompt.
Chunk: um trecho recuperável. Embedding: um vetor que representa o texto para busca por similaridade. Token: unidade usada pelo tokenizer; não equivale a palavra.
Few-shot: demonstrações colocadas no prompt. Não há atualização dos pesos do modelo. Preflight: checagens antes de gerar. Ledger: registro persistente das tentativas, respostas e custos.
Coorte elegível: conjunto congelado de documentos que atende aos critérios técnicos. Referência: o resumo fornecido pelo dataset, usado como comparação nas métricas.
Notas e saídas históricas podem conter métricas numéricas e o antigo filtro de tabelas; não representam o escopo atual. Neste guia, fatos executados vêm dos artefatos e do código; decisões novas estão identificadas como tais. O protocolo já registra avaliação somente por métricas e mantém a revisão humana apenas como ferramenta legada opcional. As regras finais do full continuam em elaboração.