Modelos pequenos, grandes resultados: treinamento de um agente financeiro por menos de US$ 500 — Charles Dickens, Snorkel AI

Autoria: AI Engineer · 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: Small Models, Big Results: Training a Finance Agent for Under $500 — Charles Dickens, Snorkel AI · Canal: AI Engineer · 16:44 · Assistir no YouTube

Tópicos: Agentes de IA, Aplicações empresariais de IA, Avaliação e benchmarks de IA, Dados, bancos de dados e embeddings, Modelos de IA

Resumo

Charles Dickens, pesquisador da Snorkel AI, apresenta um estudo em que um modelo Qwen de 4 bilhões de parâmetros, treinado com aprendizado por reforço e dados financeiros especializados, superou a variante de 235 bilhões em tarefas do FinQA. O conjunto de dados foi criado a partir de relatórios 10-K, com verificações programáticas, revisão automatizada e validação humana especializada. O treinamento custou menos de US$ 500 e também trouxe ganhos em tarefas com várias tabelas, sem prejudicar significativamente a capacidade geral de uso de ferramentas. O estudo indica que, em tarefas empresariais especializadas, dados de qualidade e confiabilidade podem ser mais importantes que a escala do modelo.

Pontos-chave

Um modelo Qwen de 4 bilhões de parâmetros obteve quase 60% de acurácia pass@1, superando os 51% da variante de 235 bilhões no benchmark financeiro apresentado.
O FinQA foi criado a partir de relatórios 10-K e inclui perguntas e respostas financeiras validadas por especialistas.
A validação dos dados combinou verificações programáticas, revisão por agentes independentes e análise manual de especialistas.
Entre as falhas observadas em modelos estão alucinação de esquemas, excesso de consultas que inundam o contexto e recuperação deficiente após erros.
O treinamento usou GRPO, recompensa binária e cerca de mil ambientes concorrentes, com custo total inferior a US$ 500.
A disciplina no uso de ferramentas adquirida com exemplos de uma única tabela também se transferiu para tarefas que exigem duas a cinco tabelas.
O ajuste não reduziu a competência geral de tool calling, medida pelo benchmark BFCL; houve pequenos ganhos em algumas categorias.
Nas ablações, treinar com dados mais simples e usar uma recompensa binária superou misturas de dados e recompensas mais elaboradas.
Para avaliar agentes, o palestrante destaca a complexidade do ambiente, o horizonte de autonomia e a complexidade das saídas.

Capítulos

Início	Capítulo	Resumo
00:01	Apresentação e resultado principal	Charles Dickens apresenta o estudo e argumenta que especialização e dados de qualidade podem permitir que modelos menores rivalizem com modelos muito maiores.
03:49	Por que criar um benchmark financeiro especializado	A palestra explica as necessidades de confiabilidade em instituições financeiras e descreve a criação do FinQA a partir de relatórios 10-K.
06:35	Dados, falhas dos modelos e ambiente de treinamento	O palestrante detalha a divisão dos dados, as falhas recorrentes dos modelos e o ambiente usado para treinar o agente com ferramentas.
08:13	Treinamento e resultados do modelo de 4 bilhões	A palestra apresenta o framework RLLM, os custos do treinamento e o resultado em que o modelo menor supera a variante de 235 bilhões.
10:23	Generalização para tarefas mais complexas	O modelo é avaliado em tarefas com várias tabelas e em um benchmark geral de tool calling, com transferência de habilidades sem perda relevante de capacidade.
12:29	Estudos de ablação e recomendações para agentes empresariais	As ablações mostram que dados mais simples e recompensa binária deram os melhores resultados, e a palestra apresenta dimensões para avaliar agentes.
14:06	Avaliação de agentes, financiamento e encerramento	O palestrante destaca os eixos de avaliação, apresenta os subsídios para benchmarks open source e indica onde encontrar os artefatos do projeto.

Citações

Em cargas de trabalho empresariais de IA, confiabilidade e especialização podem superar a escala bruta de parâmetros. — 00:34

Fluxos de trabalho especializados não precisam de generalistas. — 04:21

Tudo isso custou menos de US$ 500 para obter os resultados que vimos. — 09:49

Um único sinal de recompensa binário foi o que nos trouxe o maior ganho nesses dados. — 13:32

Conceitos e entidades

Charles Dickens (pessoa): Pesquisador da Snorkel AI que apresenta o estudo sobre treinamento de modelos para tarefas financeiras.
Snorkel AI (empresa): Empresa de IA que colaborou na criação dos dados e no treinamento do modelo financeiro apresentado.
UC Berkeley Sky Computing Lab (empresa): Laboratório da UC Berkeley que colaborou no projeto e desenvolveu o framework RLLM mencionado na palestra.
FinQA (conceito): Conjunto de dados e benchmark de perguntas e respostas financeiras usado para treinar e avaliar modelos.
Qwen3 4B (modelo): Modelo de 4 bilhões de parâmetros usado como modelo-base para o treinamento descrito.
Qwen 3 30B (modelo): Modelo usado para transformar tabelas extraídas de relatórios 10-K em dados tabulares estruturados.
RLLM (ferramenta): Framework usado para treinar o agente com aprendizado por reforço.
GRPO (conceito): Algoritmo de aprendizado por reforço usado na otimização do modelo.
BFCL (conceito): Benchmark usado para medir a capacidade geral de tool calling do modelo.
GPT-5 nano (modelo): Modelo usado como LLM as a judge para avaliar respostas com base em referências.

Tradução completa (pt-BR)

00:01 [música] >> Pessoal, obrigado por participar. Sou Charles, pesquisador na Snorkel AI. Hoje vou falar sobre como fizemos um modelo de 4 bilhões de parâmetros superar em inteligência sua variante de 235 bilhões de parâmetros. Esse é um resultado específico em um ambiente financeiro simulado,

00:34 mas acho que há aprendizados gerais que quero garantir que vocês levem daqui. O primeiro é que, para cargas de trabalho de IA corporativa, confiabilidade e especialização podem, na verdade, ser mais importantes do que a escala bruta de parâmetros. Isso é possível com dados de alta qualidade que realmente representem o domínio e a distribuição de tarefas que vocês querem atingir. E isso pode resultar em modelos menores capazes de alcançar paridade com modelos de ponta por uma fração do custo. Então,

01:06 antes de chegar a isso, vou aproveitar a oportunidade para nos apresentar um pouco. Esta é a nossa equipe. Somos um laboratório de dados de IA de ponta. Nossa equipe inclui fundadores de laboratórios da University of Washington, da Wisconsin e de Stanford, além de uma equipe interna de funcionários em tempo integral e pesquisadores muito talentosos. Estamos em uma posição privilegiada para atuar — com isso quero dizer construir e implantar conjuntos de dados e ambientes para IA de ponta. Isso acontece na interseção entre pesquisa acadêmica e industrial, mas também tem os pés no chão, com implantações corporativas.

01:39 E tudo isso quer dizer que temos uma equipe preparada para se concentrar em criar os melhores dados possíveis para definir a IA avançada. Fazemos isso de três maneiras. A primeira é pesquisa aberta e benchmarks: estamos sempre contribuindo para o benchmarking open source, e o projeto sobre o qual vou falar hoje se enquadra nessa área. Mas também quero destacar os dados e ambientes ativos de ponta, assim como as implantações corporativas, que são coisas em que trabalhamos

02:11 também. Na área de pesquisa aberta e benchmarks, apoiamos a pesquisa por meio de bolsas, e vou falar sobre oportunidades aqui no fim desta palestra, então fiquem atentos. Também somos coautores com parceiros acadêmicos ou do setor e lideramos pesquisas independentes, publicando artefatos abertos. O que vou apresentar hoje é uma parceria com o UC Berkeley Sky Computing Lab. Construímos, como eu disse, um modelo Qwen de 4 bilhões de parâmetros

02:43 para superar sua variante de 235 bilhões de parâmetros em tarefas financeiras. Vimos o modelo de 4 bilhões de parâmetros — alerta de spoiler — alcançar quase 60% de pass@1, enquanto o modelo de 235 bilhões alcançou 51%. São resultados animadores, e tudo isso foi feito em colaboração com — é preciso dar crédito a quem merece — Manon Rupta e Shujian Tang, do Sky Computing Lab, além de Bhavishya, Chris Glaze e eu, da Snorkel. Vocês podem encontrar todos os recursos, os scripts de treinamento e os dados sintéticos

03:17 no nosso GitHub. Então, deem uma olhada: tudo isso é open source e está disponível para vocês. Hoje vou falar sobre o que, com base no que aprendemos nas nossas implantações corporativas, vemos que as instituições financeiras precisam da IA, assim como sobre o benchmark open source FinQA. Ele contém dados de perguntas e respostas financeiras validados por especialistas, com os quais treinamos e avaliamos nosso modelo. Por fim, vou falar sobre o processo de treinamento do modelo RLLM FinQA 4B.

03:49 Vamos começar. Esta é a única referência a Charles Dickens nos slides, prometo, mas eu diria que esta é a história de dois modelos. Primeiro, o generalista grande versus o especialista pequeno. O ponto aqui é que, quando instituições financeiras nos perguntam quão bem o modelo ou o agent raciocina, o que normalmente querem saber é: ele consegue operar na minha pilha de esquemas complexos, APIs legadas e dívida técnica? E podemos confiar nele em workflows realistas e longos sem que os erros se acumulem? E podemos auditar o agent de forma confiável? Isso é importante nos domínios financeiro e jurídico, por exemplo.

04:21 Isso nos leva à pergunta: como podemos avaliar e melhorar agents para torná-los confiáveis nesses ambientes do mundo real? A reação imediata pode ser aumentar a escala. Todos já vimos resultados de leis de escala, mas hoje vou defender que workflows especializados não precisam, na verdade, de generalistas. Não precisamos de polímatas. Sabe, você não chamaria Terence Tao para uma auditoria fiscal, se tiver a sorte de tê-lo entre seus contatos. Chamaria o especialista que

04:52 conhece os formulários, as ferramentas e as regras. Foi por isso que criamos o FinQA. São dados de perguntas e respostas financeiras validados por especialistas. Vou explicar o pipeline de várias etapas que usamos para criar esse benchmark e os dados de treinamento. A primeira etapa é a extração de esquemas e dados. Esses dados vêm de relatórios 10-K. São relatórios anuais exigidos pela SEC para todas as empresas de capital aberto e são usados por analistas para identificar riscos e embasar decisões de investimento. Nós os extraímos do sistema Edgar

05:26 e usamos o modelo Qwen 3 30 billion para produzir tabelas, tabelas SQL — aproximadamente 6.900 delas. Usamos cada tabela para gerar um único par de pergunta e resposta. Isso é produzido junto com a taxonomia de perguntas desenvolvida com especialistas financeiros que trabalham com esses documentos. Esses elementos são usados como contexto para o modelo gerar um par de pergunta e resposta, acompanhado de metadados. Mais adiante, veremos para que eles servem. E, por fim, a terceira etapa é

06:00 a verificação. Trata-se de um processo de verificação em três camadas. A primeira consiste em verificações programáticas de consistência. Nessa etapa, usamos os metadados — que incluem a linhagem dos dados e os nomes das tabelas e colunas — para garantir que não estejamos alucinando essas informações. A segunda camada é formada por revisões automatizadas feitas por agents independentes. E, por fim, há a revisão manual por especialistas. Ou seja, pessoas analisam esses itens para garantir que as perguntas e respostas sejam realistas e estejam verificadas. O resultado são os dados FinQA da Snorkel. Esta é nossa primeira versão.

06:35 Consultas realistas que exigem planejamento, uso de ferramentas, tool calling e raciocínio. As respostas são finais, únicas e verificáveis. Com base nisso, do conjunto original de aproximadamente 7.000 tabelas, ficamos com 4.000 para treino, 500 para validação e 290 no benchmark reservado. Os dados são divididos de modo que nenhuma empresa do benchmark apareça em mais de uma divisão. E, com esses dados, nós

07:11 identificamos falhas recorrentes de disciplina e modos de falha, mesmo em modelos de ponta. A primeira é a alucinação de esquemas. O modelo pode presumir que certas tabelas e nomes de colunas existem, o que pode ser um reflexo dos dados de pré-treinamento, de algo que viu anteriormente. A próxima é o excesso de contexto. O modelo pode, na prática, inundar o próprio contexto com consultas mal planejadas. Por exemplo, simplesmente chamar select star. Se isso der certo, pode sobrecarregar os limites do contexto

07:43 dele. Por fim, há a recuperação inadequada diante de erros. Quando o 3235 cometia um erro, repetia a mesma estratégia malsucedida em vez de considerar as mensagens de erro e se adaptar. Esses modos de falha não aparecem apenas no ambiente financeiro de que estou falando hoje; também os vimos na avaliação de risco de seguros. Esse é um trabalho que estou destacando, apresentado na conferência CAIS há algumas

08:13 semanas. Agora vou falar sobre o treinamento do modelo RLLM FinQA de 4 bilhões de parâmetros. Para isso, usamos o framework RLLM, desenvolvido pelos colaboradores do R Sky Computing Lab. Se vocês ainda não o usaram, é uma ferramenta realmente fácil de usar. Quero destacar alguns recursos principais: funciona com qualquer framework de agent, exige quase nenhuma alteração no código e usa um padrão de decorator;

08:45 workflow voltado para CLI e resultados testados em condições reais. O RLLM demonstrou melhorar o desempenho não apenas neste estudo de caso financeiro, mas também, por exemplo, em raciocínio matemático. Vários algoritmos de RL vêm integrados, como GRPO, reinforce RL e OOO, e vocês podem personalizá-los. Além disso, há suporte a vários backends de treinamento. Certo, agora vamos ao nosso ambiente de treinamento. Este é o ambiente de treinamento

09:16 que usamos para o modelo. O agent executa um loop de ReAct e tem acesso a ferramentas para interagir com as tabelas que geramos. O ambiente inclui as aproximadamente 7.000 tabelas que criamos. Por fim, a recompensa é binária — correta ou incorreta — e determinada por um LLM como juiz. Neste caso, usamos GPT 5 nano com avaliação baseada em uma resposta de referência. Os detalhes do treinamento estão listados aqui. Acho que isso pode interessar a vocês. Nosso modelo base é o Qwen 3 4 billion;

09:49 usamos GRPO e recompensa binária para a otimização, com o framework RL. Executamos aproximadamente 1.000 ambientes simultâneos para gerar trajetórias, e tudo isso custou menos de US$ 500 para obter os resultados que vimos. Desse total, cerca de US$ 420 foram para computação e US$ 40 para a API do juiz. Fizemos isso em oito H100. O primeiro resultado

10:23 Essa é a questão central: um modelo de 4 bilhões, equipado com ferramentas e treinamento especializados, consegue competir com sua variante maior? E a resposta é sim. O que vimos foi que a precisão do modelo-base mais que dobrou, e ele supera sua variante maior, o modelo de 235 parâmetros. E isso apesar de ter apenas uma fração do tamanho. Avaliamos todos os modelos mostrados aqui com base nos 290 exemplos reservados, selecionados por especialistas.

10:54 Então, uma preocupação natural é se isso realmente se transfere para problemas mais difíceis. Aqui, temos apenas pares de pergunta e resposta em uma única tabela. Para investigar isso, analisamos nossos dados de raciocínio do FinQA. Trata-se de um desenvolvimento dos dados do FinQA que apresentei antes. A diferença agora é que há dependências entre várias tabelas, de duas a cinco, e é necessário tomar decisões e planejar em sequência.

11:24 E avaliamos esse conjunto de dados. Vocês também podem ver a distribuição. Temos aproximadamente 1.000 exemplos de treinamento, 120 de validação e 80 nos benchmarks. O que vemos é que a disciplina no uso de ferramentas se generalizou diretamente a partir do treinamento com os dados simples. Na verdade, não foi necessário treinamento explícito com exemplos de várias tabelas para observar ganhos nessa variante do conjunto de dados com várias tabelas. E vamos

11:57 investigar o motivo com os estudos de ablação. Mas a próxima preocupação era se esse resultado se generalizaria para casos de uso mais gerais. Para isso, usamos o benchmark BFCL, que mede a capacidade geral de tool calling. No geral, a precisão melhorou ligeiramente, e também tivemos ganhos menores em interações de vários turnos e memória. Portanto, a especialização não prejudicou a competência mais ampla do modelo no uso de ferramentas quando fizemos fine-tuning com RL nesse modelo.

12:29 Para identificar o que levou a esse desempenho, realizamos um estudo de ablação das misturas de dados, ou seja, diferentes maneiras de combinar os dados de treinamento que tínhamos. A primeira opção é treinar apenas com dados do FinQA; a segunda, com dados de uma e de várias tabelas; e, por fim, um currículo em que começamos com uma tabela e depois passamos para várias. Surpreendentemente, treinar apenas com o conjunto mais simples resultou nos maiores ganhos. E isso explica parcialmente o resultado de generalização que vimos

13:00 antes. O gargalo nunca foi a profundidade do raciocínio; era apenas o uso de ferramentas, ou seja, onde o modelo estava falhando, e melhorar sua confiabilidade. Depois de dominar os fundamentos, ele conseguia combinar essas habilidades. Sim, opa, deixa eu voltar. A próxima pergunta natural é se sinais de recompensa mais informativos — por exemplo, recompensar etapas intermediárias, acesso às tabelas, completude das consultas e coisas assim — poderiam

13:32 acelerar o aprendizado. Isso é diferente de um currículo, por exemplo. A variante mais sofisticada que criamos foi uma rubrica. Ela usa pontuação detalhada, com vários componentes ponderados, e foi criada com a ajuda de especialistas. Apesar desse investimento na engenharia de recompensas, vimos novamente que o mais simples era melhor. Um único sinal de recompensa binário foi o que gerou os maiores ganhos com esses dados. Isso nos levou a um plano para agents empresariais que estamos desenvolvendo.

14:06 De modo geral, eu diria que este estudo nos mostrou que modelos pequenos podem ser treinados com sucesso com RL quando há dados de qualidade que representem os resultados e as tarefas desejados. Isso pode levar a uma economia melhor no deploy para tarefas e domínios especializados. Vimos e repetimos esse resultado em outras áreas, incluindo saúde, direito e seguros, como mencionei antes. Então, confiram. E

14:40 nosso ponto de vista sobre a criação de eixos para avaliar agents é que a complexidade do ambiente é um dos eixos mais importantes. Quão complexos, realistas e dinâmicos são os ambientes em que os agents operam? O próximo eixo é o horizonte de autonomia. Os agents são testados e avaliados por períodos e horizontes que correspondem à forma como as pessoas realmente querem usá-los? Eles tomam decisões boas e seguras por conta própria? E conseguem

15:10 melhorar o próprio julgamento ao longo do tempo como copilotos? Por fim, há a complexidade da saída. Queremos abranger a ampla variedade de resultados do nosso trabalho cotidiano. Eu diria que isso ainda é pouco explorado. Estão surgindo novos benchmarks nessa direção, mas ainda vejo um grande foco principal em artefatos de texto, e há uma grande oportunidade de criar avaliações mais rigorosas nesses contextos.

15:42 Há progresso nessa área. Então, aproveitando o assunto, vou divulgar nossos subsídios para benchmarks abertos, que financiaram este projeto. Trata-se de um compromisso de vários milhões de dólares para produzir benchmarks abertos como este. Tivemos muito sucesso com Agent, Last Exam, Judgment Bench; outros estão sendo lançados, e isso está realmente acelerando nossa capacidade de medir a fronteira e moldá-la.

16:14 Para se candidatar, acesse nosso site. Vocês passarão por um processo de envio, seleção e análise da proposta, desenvolvimento e, por fim, publicação, lançamento e divulgação. Também quero mencionar que estamos contratando profissionais de pesquisa, engenheiros, entre outros. Então, confiram. Vocês podem acessar nosso site e, por fim, obrigado

16:44 a todos por participarem. Vocês podem usar este QR code para ver o blog e também acessar os links para todos os materiais publicados no GitHub e no Hugging Face. Obrigado a todos.

Transcrição original

[00:01] [music] >> Everyone, thanks for joining. I’m Charles and I’m a research scientist at Snorkel AI. And today I’m going to be talking about how we got a 4 billion parameter model to outsmart its 235 billion parameter variant. And this is a specific result in a simulated financial environment,

[00:34] but I think there are general takeaways that I want to make sure taken home. And the first is for enterprise AI workloads, reliability and specialization uh can actually outweigh raw parameter scale. And this is possible with high-quality data that actually represents the domain and task distribution that you’re targeting. And uh this can result in smaller models that can achieve parity with frontier models at just a fraction of the cost. So,

[01:06] before I get to it, I’m going to take this opportunity to introduce ourselves a little bit. This is our team. We’re a frontier AI data lab and our team, we have founders from labs at University of Washington, Wisconsin, Stanford, and an internal team of really talented FTEs, researchers, and we’re in a fortunate position to play in, by that I mean build and deploy data sets and environments uh for frontier AI. And that’s at the intersection of academia and industry research, but also grounded in enterprise deployments.

[01:39] Um and this is all to say that we have a team that’s built to focus on building the best data possible to define in advanced AI. And the way we do this is threefold. First is open research and benchmarks, so we’re constantly contributing to open-source benchmarking, and the project I’ll be talking about today actually falls under this pillar. Um but I also want to acknowledge frontier live data and environments, as well as enterprise uh deployments are the things we work

[02:11] on. And under open research and benchmarks, we support research through grants, and I’ll talk about opportunities here at the end of this talk, so um get ready for that. And then co-authoring with academic uh or industry partners um and leading independent research and publishing open artifacts. So, what I’m talking about today is uh a partnership with UC Berkeley Sky Computing Lab, and we built, like I said, a 4 billion parameter Qwen model

[02:43] to outperform its 235 billion model variant on financial tasks. We saw the 4 billion parameter model, spoiler alert, uh achieve almost a 60% pass at one, while the 235 billion model uh achieved 51%. So, exciting results, and this is all uh in collaboration with I got to give credit where credit’s due, Manon Rupta, Shujian Tang from the Sky Computing Lab, as well as Bhavishya and Chris Glaze and myself uh from Snorkel. And you can find all the assets, the uh training scripts, synthetic data

[03:17] uh on our GitHub, so check those out, and this is all open-source and available to you. So, I’ll cover today what uh we see financial institutions need um from AI, and this is from our enterprise deployments uh learnings, as well as the FinQA open-source benchmark. And this is expert-validated financial question-answering data that we trained our uh and evaluated our model on. And finally, uh the training process for the RLLM FinQA 4B model.

[03:49] So, let’s get started. This is uh the one and only slide with the Charles Dickens reference, I promise, but this is a tale of two models, I’d say. First, the large generalist versus small specialist. And the point is here, when financial institutions ask us how well does the model or the agent reason, what they typically mean is can it operate in my stack of complex schemas, legacy APIs, and tech debt? And can we trust it in realistic uh and long workflows without compounding errors? And can we reliably audit the agent? That’s important in

[04:21] financial and legal domains, for example. Which brings us to the question is uh how can we evaluate and improve agents to make them reliable in these uh real-world environments? So, um the reflex may be to scale. We’ve all seen scaling law results, uh but today I’m going to argue that specialized workflows don’t actually need generalists. We don’t need polymaths. You know, you wouldn’t call Terence Tao for a tax audit, um if you’re lucky enough to have him in your contacts. You’d call the specialist that

[04:52] knows the forms, the tools, and the rules. So, that’s why we built FinQA. This is expert-validated financial question-answering data. And I’ll walk through the multi-stage pipeline of how we built this benchmark and training data. So, first is schema and data extraction. This is coming from 10-K reports. Uh these are annual reports required by the SEC for all public companies, and they’re used uh by analysts for identifying risks and informing investment decisions. Uh we pull these from the Edgar system

[05:26] and use the Qwen 3 30 billion model to produce tables, SQL tables, approximately 6,900 of those. And we use each table to generate a single question-answer pair. And this is uh produced along with the question taxonomy that was developed with financial experts that work with these documents. And these are used as context uh for the model to generate a question-answer pair along with metadata that we’ll see uh what that’s used for later. And finally, the third step is

[06:00] verification. And this is a three-layer verification process. First is programmatic consistency checks. That’s where we use um the metadata, uh which includes lineage and table names and columns to make sure we’re not hallucinating those. The second is automated reviews from independent agents. And finally, expert manual review. So, humans actually going through these and making sure the questions and answers are realistic and verified. And the outcome is Snorkel’s FinQA data. And this is our first pass at this.

[06:35] Uh realistic queries requiring planning, tool use, uh tool calling, and reasoning. And um answers are single, verifiable, final answers. And from this, um we get from the uh original set of roughly 7,000 tables, 4,000 in train, 500 in val, and 290 in the held-out benchmark. And the data is split so that no company in the benchmark overlaps um in any split. And on this data, we

[07:11] identified um even with frontier models, uh reoccurring discipline gaps, uh failure modes. And the first is schema hallucination. So, a model will actually assume that tables exist, column names exist, and um this can be an artifact of pre-training data, something it’s seen um in its past. The next is context flooding. So, actually flooding its own context um with poorly playing queries. For example, just calling select star, um and this could overwhelm its context

[07:43] limits if successful. And finally, poor recovery um from errors. So, when 3235 would actually repeat the same failed strategy um instead of considering the error messages and adapting. And these failure modes are not actually just seen in the financial environment that I’m talking about today, but also what we saw in insurance underwriting. And this is a work that I’m calling out that was presented at the CAIS conference um

[08:13] few weeks ago. So, now I’ll get into actually training the R LLM FinQA 4 billion model. Uh for this we used the R LLM uh framework and this was developed by the R Sky Computing Lab collaborators. And if you haven’t used this yet, um this is a really user-friendly tool and a few core features um I want to call out is it really works with any agent framework, requires near zero code changes just using uh a decorator

[08:45] pattern, CLI first workflow, battle-tested results. So, um we’ve seen R LLM actually improve not just on this finance um case study, but also in math reasoning for example. Um multiple RL algorithms are built in, GRPO, reinforce RL, OOO for example, and you can customize those and then supports multiple uh training backends. All right, now for our training environment, um this is the uh training

[09:16] environment we used for our model. The agent runs in a react loop and has access to tools uh to interact with the tables we generated. The environment includes the roughly 7,000 tables we created and finally reward is binary correctness uh determined by a language model as judge. In this case, GPT 5 nano using reference-based evaluation. Training details are listed here. This is uh I guess would be interesting to folks. We have the Qwen 3 4 billion model is

[09:49] our base model, GRPO and binary reward uh for optimization and the RL and framework. Um we ran roughly 1,000 concurrent environments to generate trajectories and this all was a cost under $500 to get the results that we saw. Um broken down between compute roughly 420 and $40 for a judge uh the judge API. And this was on eight H100s. The first result um

[10:23] is the central question, can a 4 billion model uh armed with the specialized tools and training actually compete with its larger variant? And the answer is yes. So, what we saw was actually the base model’s accuracy um more than doubled and it outperforms its larger variant, the 235 parameter model. And this is uh despite being a fraction of the size. And we evaluate all models shown here um on the expert curated held out 290

[10:54] samples. So, a natural concern is whether this actually transfers to harder problems. So, this is just single question answer pairs on a single table. Um and to investigate this, we uh looked at our FinQA reasoning data. So, this is a development on the FinQA um data I presented earlier. And the difference here is that now we’re having a dependencies on multiple tables, two to five tables, and requires sequential um

[11:24] decision-making and planning. And we evaluated on this data set. You can see the breakdown um as well. We have roughly 1,000 in train, 120 in validation, 80 in benchmarks. And what we see is the tool use discipline actually generalized directly from training on the simple data. And no explicit training on multi-table examples was needed actually to see lift in this multi-table variant of the data set. And we’ll

[11:57] investigate why with the ablation studies. But the next concern we had was whether this result would generalize to more general use cases. So for this we use the BFCL benchmark and this measures general tool calling capability. And overall accuracy was actually slightly improved and then um we had also minor gains on multi-turn and memory. So specialization didn’t actually erode the model’s broader tool

[12:29] use competence when we did RL fine-tuning for this model. So to isolate what drove this performance, we ran ablation study on data mixtures, so different ways we can combine the training data we had. The first is just training on FinQA data and the second single and multi-table and finally a curriculum where we start with single and then move to multi. And surprisingly, just training on the simpler set resulted in the most lift. And this partially explains why the generalization result we saw

[13:00] earlier. The bottleneck was never reasoning depth, it was just tool use, meaning the model where it was actually failing and improving the reliability of that. And once you master the fundamentals, it could compose those skills. Yeah, so oops, let me go back. The next natural question is whether more informative reward signals, Um, for example, rewarding intermediate steps, uh, table access, query completeness, things like that could

[13:32] actually accelerate learning. Uh, so this is different from curriculum, for example. And the most sophisticated variant we came up with was, uh, a rubric. And this uses fine-grained scoring with, uh, multiple weighted components. And this is actually coming came up with with experts. Um, and despite this investment in reward engineering, we actually again saw, um, simpler was better. A single binary reward signal, um, was what got us the most lift on this data. Which led us to a blueprint, um, that we’ve been developing for enterprise

[14:06] agents. Um, and generally, I’d say this study showed us that small models uh, can successfully be trained uh, with RL um, when you have quality data to uh, represent the target um, outcomes and tasks. And this can result in better deployment economics uh, for specialized tasks and domains. And um, we’ve seen this and repeated this result in other areas including health care, law, and insurance, um, which I pointed to earlier. So, check that out. Um, and

[14:40] our point of view as far as building um, axes for evaluating agents is this is environment complexity is um, one of the most important axes. How complex, how realistic and dynamic are the environments uh, the agents operating in. The next is autonomy horizon. Um, are agents being tested and evaluated at the lengths and the horizon lengths in the way people actually want to use agents? Um, are they making safe and good decisions by themselves? And can they actually

[15:10] improve um, their judgment as a co-pilot over time? And finally, output complexity. We want to capture the wide range of outputs in our day-to-day work. Um, and I would say that this is currently under explored. New benchmarks are coming up in this direction, but uh still I see a big primary focus on um text artifacts and creating more rigorous evaluations and these settings is a big opportunity.

[15:42] Progress is being made here. So, on that note, um I’m going to advertise our open benchmarks grants, which funded this project. And this is a multi-million dollar commitment to producing open benchmarks like this. We’ve had a lot of success agent, last exam, judgment bench, um others are coming out and this is um really accelerating our ability to measure the frontier and shape the frontier.

[16:14] So, to apply uh check out our website. Um you’ll go through a submission selection review process, develop, and then finally publication, launch, um and promotion. And I also want to call out that we’re hiring in professional research, um you name it, engineers, and um yeah, check that out. You can check out our website and finally, thank

[16:44] you so much for attending. Um you can use this QR code to see the blog as well as pointers to all the artifacts that released on GitHub, Hugging Face. Yeah, thank you all.