{"id":205543,"date":"2026-04-09T16:01:54","date_gmt":"2026-04-09T19:01:54","guid":{"rendered":"https:\/\/goias.gov.br\/ligo\/?p=205543"},"modified":"2026-04-09T16:18:48","modified_gmt":"2026-04-09T19:18:48","slug":"arquitetura-para-avaliacao-de-llms-desafios-dados-e-decisoes","status":"publish","type":"post","link":"https:\/\/goias.gov.br\/ligo\/arquitetura-para-avaliacao-de-llms-desafios-dados-e-decisoes\/","title":{"rendered":"Arquitetura para Avalia\u00e7\u00e3o de LLMs: Desafios, Dados e Decis\u00f5es"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

O objetivo <\/b>deste artigo \u00e9 descrever os principais aprendizados do projeto de benchmarking de modelos de Large Language Models (LLMs). Tamb\u00e9m abordaremos detalhes sobre as decis\u00f5es de arquitetura e desafios metodol\u00f3gicos. Previamente temos uma constata\u00e7\u00e3o importante<\/b>: avaliar modelos de LLMs \u00e9 hoje um problema t\u00e3o complexo quanto utiliz\u00e1-los em produ\u00e7\u00e3o.<\/span><\/p>\n

<\/p>\n

\"A<\/figure>\n

<\/p>\n

Nos \u00faltimos anos, a explos\u00e3o de Large Language Models (LLMs) inundou o mercado com op\u00e7\u00f5es. Hoje temos modelos propriet\u00e1rios, como os oferecidos por OpenAI e Gemini, al\u00e9m de uma crescente comunidade de modelos open-source executados localmente com ferramentas como Ollama. No ambiente de um laborat\u00f3rio de inova\u00e7\u00e3o, a pergunta n\u00e3o \u00e9 ‘se’ usamos IA, mas ‘como’ validamos rapidamente o que realmente funciona para o cidad\u00e3o.<\/strong><\/p>\n

<\/p>\n

Qual modelo \u00e9 o melhor para o meu caso de uso?<\/strong><\/span><\/h6>\n

<\/p>\n

Para isso, desenvolvemos um pipeline automatizado de benchmarking de LLMs. A plataforma submete m\u00faltiplos modelos, de GPT-4 a Llama local, a um mesmo conjunto de testes paralelos. O sistema coleta m\u00e9tricas como tokens, lat\u00eancia e taxa de alucina\u00e7\u00e3o e avalia respostas com crit\u00e9rios pr\u00e9-definidos, consolidando os resultados em dashboards anal\u00edticos que geram evid\u00eancias t\u00e9cnicas sobre assertividade, custo e seguran\u00e7a. A solu\u00e7\u00e3o foi constru\u00edda utilizando:<\/p>\n

<\/p>\n

<\/p>\n

    \n
  • \n
      <\/ul>\n<\/li>\n<\/ul>\n
        \n
      • \n
          \n
        • Nuxt 3 + Vue 3<\/span><\/em><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

          <\/span><\/em><\/p>\n

            \n
          • \n
              \n
            • Node.js com runtime Nitro<\/span><\/em><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

              <\/span><\/em><\/p>\n

                \n
              • \n
                  \n
                • TypeScript<\/span><\/em><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

                  <\/span><\/em><\/p>\n

                    \n
                  • \n
                      \n
                    • PostgreSQL<\/span><\/em><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

                      <\/span><\/em><\/p>\n

                        \n
                      • \n
                          \n
                        • Prisma ORM<\/span><\/em><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

                          <\/span><\/em><\/p>\n

                            \n
                          • \n
                              \n
                            • LangChain<\/span><\/em><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

                              <\/p>\n

                              <\/p>\n

                              O objetivo foi avaliar diferentes dimens\u00f5es do comportamento dos modelos, incluindo algumas m\u00e9tricas como; compreens\u00e3o textual, racioc\u00ednio l\u00f3gico, conhecimento jur\u00eddico, comportamento em cen\u00e1rios de RAG, gera\u00e7\u00e3o de c\u00f3digo e outras.<\/p>\n

                              <\/p>\n

                              Arquitetura da Plataforma de Benchmarking<\/strong><\/span><\/h6>\n

                              <\/p>\n

                              A aplica\u00e7\u00e3o foi constru\u00edda como uma arquitetura full-stack tipada, onde frontend e backend compartilham o mesmo reposit\u00f3rio e a mesma base de tipos em TypeScript. Essa abordagem reduz inconsist\u00eancias entre camadas e acelera o desenvolvimento.<\/strong><\/p>\n

                              <\/p>\n

                              Frontend (Nuxt 3 + Vue 3 + EChar): <\/strong>O frontend foi desenvolvido com Nuxt 3 e Vue 3, focado na visualiza\u00e7\u00e3o anal\u00edtica dos resultados dos benchmarks. A biblioteca ECharts permite criar gr\u00e1ficos interativos capazes de cruzar vari\u00e1veis como taxa de acerto, custo de tokens e incid\u00eancia de alucina\u00e7\u00e3o. A Composition API do Vue 3 facilita a organiza\u00e7\u00e3o de componentes e a reutiliza\u00e7\u00e3o de l\u00f3gica, bom para iterar rapidamente na interface de an\u00e1lise.<\/p>\n

                              <\/p>\n

                              Backend (Nitro Runtime):<\/strong> O backend foi implementado utilizando Nitro, o runtime server do Nuxt. Essa camada funciona como orquestrador dos experimentos, respons\u00e1vel por executar prompts nos modelos, coletar respostas, acionar os avaliadores e persistir resultados. O Nitro traz vantagens como serverless-ready, cold start r\u00e1pido e rotas backend simples, permitindo que a aplica\u00e7\u00e3o funcione como um backend leve para orquestrar execu\u00e7\u00f5es de benchmark.<\/p>\n

                              <\/p>\n

                              Integra\u00e7\u00e3o com LLMs (LangChain):<\/strong> Para integrar diferentes provedores de modelos de linguagem, foi utilizado o LangChain, que funciona como uma camada de abstra\u00e7\u00e3o e orquestra\u00e7\u00e3o para intera\u00e7\u00e3o com LLMs. A biblioteca oferece interfaces padronizadas para chamadas de modelos, permitindo trabalhar com provedores distintos, sem alterar significativamente a l\u00f3gica da aplica\u00e7\u00e3o.<\/p>\n

                              <\/p>\n

                              Persist\u00eancia (PostgreSQL + Prisma ORM):<\/strong> Os resultados s\u00e3o armazenados em PostgreSQL, com Prisma ORM gerenciando a camada de persist\u00eancia. O PostgreSQL foi escolhido pela sua robustez, excelente suporte a consultas anal\u00edticas e campos JSON, \u00fateis para armazenar respostas estruturadas de LLMs. O Prisma oferece tipagem autom\u00e1tica para queries, migra\u00e7\u00f5es simplificadas e integra\u00e7\u00e3o nativa com TypeScript.<\/p>\n

                              <\/p>\n

                              TypeScript em vez de Python<\/strong>: Pode parecer contra intuitivo usar TypeScript em um projeto de IA, onde Python \u00e9 o padr\u00e3o. No entanto, o foco deste projeto n\u00e3o foi treinar modelos, mas sim orquestrar, avaliar e visualizar o uso deles. A escolha por TypeScript foi por tr\u00eas motivos principais. Primeiro<\/strong>, a unifica\u00e7\u00e3o full-stack permite que frontend e backend compartilhem os mesmos tipos, eliminando inconsist\u00eancias de dados entre a interface e a API. Segundo<\/strong>, a seguran\u00e7a de tipos \u00e9 cr\u00edtica para benchmarking, onde a estrutura de prompts e m\u00e9tricas deve ser rigorosamente validada. Terceiro<\/strong>, o ecossistema JavaScript lida nativamente com opera\u00e7\u00f5es ass\u00edncronas e streaming de respostas, essenciais para uma experi\u00eancia de usu\u00e1rio fluida. O LangChain em JavaScript ofereceu a abstra\u00e7\u00e3o necess\u00e1ria para integra\u00e7\u00e3o dos modelos.<\/p>\n

                              Banco de dados<\/strong><\/span><\/h6>\n

                              A avalia\u00e7\u00e3o de modelos de LLMs gera uma quantidade grande de dados, tais como: <\/span>prompts enviados, <\/span>respostas geradas, <\/span>contagem de tokens, <\/span>m\u00e9tricas derivadas e <\/span>embeddings vetoriais. <\/span>Para lidar com esse volume, utilizamos o <\/span>PostgreSQL<\/b> como motor anal\u00edtico central. J\u00e1 o<\/span>\u00a0<\/span>Prisma ORM,<\/b> foi respons\u00e1vel por acelerar o desenvolvimento, gerando automaticamente tipos TypeScript a partir do schema do banco. Isso eliminou grande parte do trabalho manual de valida\u00e7\u00e3o de estruturas de dados. <\/span>Al\u00e9m do mais, os c\u00e1lculos anal\u00edticos mais complexos, utilizamos o SQL nativo do PostgreSQL.\u00a0<\/span><\/p>\n

                              Vetores e Testes de RAG<\/span><\/strong><\/h6>\n

                              Para avaliar modelos em cen\u00e1rios de <\/span>Retrieval-Augmented Generation (RAG)<\/b> foi utilizada a extens\u00e3o <\/span>pgvector<\/b> do PostgreSQL. <\/span>Isso permitiu armazenar embeddings diretamente no banco e realizar buscas sem\u00e2nticas utilizando consultas de similaridade vetorial. <\/span>O benchmark ent\u00e3o executa um fluxo simples:<\/span><\/p>\n

                                \n
                              1. Recupera documentos relevantes por similaridade vetorial<\/span><\/li>\n
                              2. Envia esses documentos como contexto ao modelo<\/span><\/li>\n
                              3. Avalia se a resposta realmente utilizou esse contexto<\/span><\/li>\n<\/ol>\n

                                Caso o modelo invente informa\u00e7\u00f5es que n\u00e3o estavam presentes nos documentos recuperados, o sistema registra esse comportamento como <\/span>alucina\u00e7\u00e3o factual<\/b>.<\/span><\/p>\n

                                O desafio: avaliar as respostas dos modelos<\/span><\/strong><\/h6>\n

                                Imagine um benchmark com <\/span>500 perguntas, que devem ser respondidas por <\/span>10 modelos de LLMs. <\/span>Isso gera <\/span>5.000 respostas em texto livre. <\/span>Cada resposta precisa ser classificada como:<\/span><\/p>\n

                                  \n
                                • correta<\/span><\/li>\n
                                • parcialmente correta<\/span><\/li>\n
                                • incorreta<\/span><\/li>\n
                                • alucina\u00e7\u00e3o<\/span><\/li>\n<\/ul>\n

                                  Fazer isso manualmente com poucos recursos e prazos \u00e9 invi\u00e1vel. <\/span>Para resolver esse problema foi adotada uma abordagem cada vez mais comum em pipelines de IA.<\/span><\/p>\n

                                  LLM-as-a-Judge<\/strong><\/span><\/h6>\n

                                  O padr\u00e3o <\/span>LLM-as-a-Judge consiste em utilizar um segundo modelo para avaliar as respostas geradas pelo modelo testado. <\/span>O avaliador recebe tr\u00eas elementos:<\/span><\/p>\n

                                    \n
                                  • a pergunta original<\/span><\/li>\n
                                  • o gabarito correto<\/span><\/li>\n
                                  • a resposta produzida pelo modelo testado<\/span><\/li>\n<\/ul>\n

                                    Com base nesses tr\u00eas elementos, ele gera uma classifica\u00e7\u00e3o estruturada indicando se a resposta est\u00e1 correta, incorreta ou constitui uma alucina\u00e7\u00e3o. <\/span>Para garantir consist\u00eancia, o sistema exige que o avaliador retorne a resposta em <\/span>JSON estruturado, validado automaticamente no backend. <\/span>Essa abordagem permite transformar um processo manual extremamente custoso em um pipeline automatizado capaz de avaliar milhares de respostas em minutos<\/strong>.<\/span><\/p>\n

                                    Avalia\u00e7\u00e3o de C\u00f3digo Gerado por IA<\/span><\/strong><\/h6>\n

                                    Um dos testes mais interessantes do benchmark avalia a capacidade dos modelos de gerar <\/span>c\u00f3digo execut\u00e1vel<\/b>. <\/span>Nesse cen\u00e1rio, o modelo recebe um problema computacional e precisa produzir um script capaz de resolv\u00ea-lo. <\/span>O pipeline funciona em duas etapas. <\/span>Primeiro o c\u00f3digo gerado \u00e9 executado em um ambiente isolado. Caso o script falhe, a resposta recebe nota zero. <\/span>Quando o c\u00f3digo executa corretamente, um segundo processo analisa se a l\u00f3gica implementada realmente resolve o problema. <\/span>Executar c\u00f3digo gerado por IA \u00e9 um risco de seguran\u00e7a significativo. Para mitigar esse problema foi criado um <\/span>sandbox utilizando Bun<\/b>, onde o c\u00f3digo roda em um processo isolado com acesso restrito ao ambiente do servidor.<\/span><\/p>\n

                                    Stack Moderna<\/span><\/strong><\/h6>\n

                                    Uma das percep\u00e7\u00f5es mais interessantes desse projeto foi a velocidade com que o sistema evoluiu. <\/span>Isso aconteceu motivado pela <\/span>tipagem end-to-end com TypeScript e Prisma, <\/b>conven\u00e7\u00f5es e automa\u00e7\u00f5es do Nuxt e <\/b>abstra\u00e7\u00e3o de provedores via LangChain. <\/b>Essa combina\u00e7\u00e3o permitiu que os esfor\u00e7os de desenvolvimento fossem direcionados para contru\u00e7\u00e3o das <\/span>m\u00e9tricas, datasets e avalia\u00e7\u00e3o de modelos<\/b>.<\/span><\/p>\n

                                    Conclus\u00e3o<\/strong><\/span><\/h6>\n

                                    Grande parte dos esfor\u00e7os no projeto foram concentrados na curadoria de datasets, seguran\u00e7a de execu\u00e7\u00e3o e na an\u00e1lise do comportamento n\u00e3o determin\u00edstico das IAs. Avaliar modelos de forma sistem\u00e1tica e orientada a dados ser\u00e1 um dos pilares da engenharia de IA nos pr\u00f3ximos anos. Plataformas de benchmarking como essa ajudam a transformar experimenta\u00e7\u00e3o em decis\u00e3o t\u00e9cnica baseada em evid\u00eancia<\/b>, algo essencial para qualquer organiza\u00e7\u00e3o que queira utilizar IA de forma respons\u00e1vel e eficiente.<\/span><\/p>\n

                                    \u00a0<\/p>\n

                                    <\/p>\n

                                    <\/p>\n

                                    <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

                                    O objetivo deste artigo \u00e9 descrever os principais aprendizados do projeto de benchmarking de modelos de Large Language Models (LLMs). Tamb\u00e9m abordaremos detalhes sobre as decis\u00f5es de arquitetura e desafios metodol\u00f3gicos. Previamente temos uma constata\u00e7\u00e3o importante: avaliar modelos de LLMs \u00e9 hoje um problema t\u00e3o complexo quanto utiliz\u00e1-los em produ\u00e7\u00e3o. Nos \u00faltimos anos, a explos\u00e3o de Large Language Models (LLMs) inundou o mercado com op\u00e7\u00f5es. Hoje temos modelos propriet\u00e1rios, como os oferecidos por OpenAI e Gemini, al\u00e9m de uma crescente comunidade de modelos open-source executados localmente com ferramentas como Ollama. No ambiente de um laborat\u00f3rio de inova\u00e7\u00e3o, a pergunta n\u00e3o \u00e9 ‘se’ usamos IA, mas ‘como’ validamos rapidamente o que realmente funciona para o cidad\u00e3o. Qual modelo \u00e9 o melhor para o meu caso de uso? Para isso, desenvolvemos um pipeline automatizado de benchmarking de LLMs. A plataforma submete m\u00faltiplos modelos, de GPT-4 a Llama local, a um mesmo conjunto de testes paralelos. O sistema coleta m\u00e9tricas como tokens, lat\u00eancia e taxa de alucina\u00e7\u00e3o e avalia respostas com crit\u00e9rios pr\u00e9-definidos, consolidando os resultados em dashboards anal\u00edticos que geram evid\u00eancias t\u00e9cnicas sobre assertividade, custo e seguran\u00e7a. A solu\u00e7\u00e3o foi constru\u00edda utilizando: Nuxt 3 + Vue 3 Node.js com runtime Nitro TypeScript PostgreSQL Prisma ORM LangChain O objetivo foi avaliar diferentes dimens\u00f5es do comportamento dos modelos, incluindo algumas m\u00e9tricas como; compreens\u00e3o textual, racioc\u00ednio l\u00f3gico, conhecimento jur\u00eddico, comportamento em cen\u00e1rios de RAG, gera\u00e7\u00e3o de c\u00f3digo e outras. Arquitetura da Plataforma de Benchmarking A aplica\u00e7\u00e3o foi constru\u00edda como uma arquitetura full-stack tipada, onde frontend e backend compartilham o mesmo reposit\u00f3rio e a mesma base de tipos em TypeScript. Essa abordagem reduz inconsist\u00eancias entre camadas e acelera o desenvolvimento. Frontend (Nuxt 3 + Vue 3 + EChar): O frontend foi desenvolvido com Nuxt 3 e Vue 3, focado na visualiza\u00e7\u00e3o anal\u00edtica dos resultados dos benchmarks. A biblioteca ECharts permite criar gr\u00e1ficos interativos capazes de cruzar vari\u00e1veis como taxa de acerto, custo de tokens e incid\u00eancia de alucina\u00e7\u00e3o. A Composition API do Vue 3 facilita a organiza\u00e7\u00e3o de componentes e a reutiliza\u00e7\u00e3o de l\u00f3gica, bom para iterar rapidamente na interface de an\u00e1lise. Backend (Nitro Runtime): O backend foi implementado utilizando Nitro, o runtime server do Nuxt. Essa camada funciona como orquestrador dos experimentos, respons\u00e1vel por executar prompts nos modelos, coletar respostas, acionar os avaliadores e persistir resultados. O Nitro traz vantagens como serverless-ready, cold start r\u00e1pido e rotas backend simples, permitindo que a aplica\u00e7\u00e3o funcione como um backend leve para orquestrar execu\u00e7\u00f5es de benchmark. Integra\u00e7\u00e3o com LLMs (LangChain): Para integrar diferentes provedores de modelos de linguagem, foi utilizado o LangChain, que funciona como uma camada de abstra\u00e7\u00e3o e orquestra\u00e7\u00e3o para intera\u00e7\u00e3o com LLMs. A biblioteca oferece interfaces padronizadas para chamadas de modelos, permitindo trabalhar com provedores distintos, sem alterar significativamente a l\u00f3gica da aplica\u00e7\u00e3o. Persist\u00eancia (PostgreSQL + Prisma ORM): Os resultados s\u00e3o armazenados em PostgreSQL, com Prisma ORM gerenciando a camada de persist\u00eancia. O PostgreSQL foi escolhido pela sua robustez, excelente suporte a consultas anal\u00edticas e campos JSON, \u00fateis para armazenar respostas estruturadas de LLMs. O Prisma oferece tipagem autom\u00e1tica para queries, migra\u00e7\u00f5es simplificadas e integra\u00e7\u00e3o nativa com TypeScript. TypeScript em vez de Python: Pode parecer contra intuitivo usar TypeScript em um projeto de IA, onde Python \u00e9 o padr\u00e3o. No entanto, o foco deste projeto n\u00e3o foi treinar modelos, mas sim orquestrar, avaliar e visualizar o uso deles. A escolha por TypeScript foi por tr\u00eas motivos principais. Primeiro, a unifica\u00e7\u00e3o full-stack permite que frontend e backend compartilhem os mesmos tipos, eliminando inconsist\u00eancias de dados entre a interface e a API. Segundo, a seguran\u00e7a de tipos \u00e9 cr\u00edtica para benchmarking, onde a estrutura de prompts e m\u00e9tricas deve ser rigorosamente validada. Terceiro, o ecossistema JavaScript lida nativamente com opera\u00e7\u00f5es ass\u00edncronas e streaming de respostas, essenciais para uma experi\u00eancia de usu\u00e1rio fluida. O LangChain em JavaScript ofereceu a abstra\u00e7\u00e3o necess\u00e1ria para integra\u00e7\u00e3o dos modelos. Banco de dados A avalia\u00e7\u00e3o de modelos de LLMs gera uma quantidade grande de dados, tais como: prompts enviados, respostas geradas, contagem de tokens, m\u00e9tricas derivadas e embeddings vetoriais. Para lidar com esse volume, utilizamos o PostgreSQL como motor anal\u00edtico central. J\u00e1 o\u00a0Prisma ORM, foi respons\u00e1vel por acelerar o desenvolvimento, gerando automaticamente tipos TypeScript a partir do schema do banco. Isso eliminou grande parte do trabalho manual de valida\u00e7\u00e3o de estruturas de dados. Al\u00e9m do mais, os c\u00e1lculos anal\u00edticos mais complexos, utilizamos o SQL nativo do PostgreSQL.\u00a0 Vetores e Testes de RAG Para avaliar modelos em cen\u00e1rios de Retrieval-Augmented Generation (RAG) foi utilizada a extens\u00e3o pgvector do PostgreSQL. Isso permitiu armazenar embeddings diretamente no banco e realizar buscas sem\u00e2nticas utilizando consultas de similaridade vetorial. O benchmark ent\u00e3o executa um fluxo simples: Recupera documentos relevantes por similaridade vetorial Envia esses documentos como contexto ao modelo Avalia se a resposta realmente utilizou esse contexto Caso o modelo invente informa\u00e7\u00f5es que n\u00e3o estavam presentes nos documentos recuperados, o sistema registra esse comportamento como alucina\u00e7\u00e3o factual. O desafio: avaliar as respostas dos modelos Imagine um benchmark com 500 perguntas, que devem ser respondidas por 10 modelos de LLMs. Isso gera 5.000 respostas em texto livre. Cada resposta precisa ser classificada como: correta parcialmente correta incorreta alucina\u00e7\u00e3o Fazer isso manualmente com poucos recursos e prazos \u00e9 invi\u00e1vel. Para resolver esse problema foi adotada uma abordagem cada vez mais comum em pipelines de IA. LLM-as-a-Judge O padr\u00e3o LLM-as-a-Judge consiste em utilizar um segundo modelo para avaliar as respostas geradas pelo modelo testado. O avaliador recebe tr\u00eas elementos: a pergunta original o gabarito correto a resposta produzida pelo modelo testado Com base nesses tr\u00eas elementos, ele gera uma classifica\u00e7\u00e3o estruturada indicando se a resposta est\u00e1 correta, incorreta ou constitui uma alucina\u00e7\u00e3o. Para garantir consist\u00eancia, o sistema exige que o avaliador retorne a resposta em JSON estruturado, validado automaticamente no backend. Essa abordagem permite transformar um processo manual extremamente custoso em um pipeline automatizado capaz de avaliar milhares de respostas em minutos. Avalia\u00e7\u00e3o de C\u00f3digo Gerado por IA Um dos testes mais interessantes do benchmark avalia a capacidade dos modelos de gerar c\u00f3digo execut\u00e1vel. Nesse cen\u00e1rio, o modelo recebe um<\/p>\n","protected":false},"author":786,"featured_media":205549,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[55,26,48],"tags":[61],"class_list":["post-205543","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-inteligencia_artificial","category-publicacoes-ligo","category-tecnologia-publicacoes-ligo","tag-inteligencia-artificial"],"rttpg_featured_image_url":{"full":["https:\/\/goias.gov.br\/ligo\/wp-content\/uploads\/sites\/61\/2026\/03\/ChatGPT-Image-30-de-mar.-de-2026-15_42_34.jpg",1024,1536,false],"landscape":["https:\/\/goias.gov.br\/ligo\/wp-content\/uploads\/sites\/61\/2026\/03\/ChatGPT-Image-30-de-mar.-de-2026-15_42_34.jpg",1024,1536,false],"portraits":["https:\/\/goias.gov.br\/ligo\/wp-content\/uploads\/sites\/61\/2026\/03\/ChatGPT-Image-30-de-mar.-de-2026-15_42_34.jpg",1024,1536,false],"thumbnail":["https:\/\/goias.gov.br\/ligo\/wp-content\/uploads\/sites\/61\/2026\/03\/ChatGPT-Image-30-de-mar.-de-2026-15_42_34-150x150.jpg",150,150,true],"medium":["https:\/\/goias.gov.br\/ligo\/wp-content\/uploads\/sites\/61\/2026\/03\/ChatGPT-Image-30-de-mar.-de-2026-15_42_34-200x300.jpg",200,300,true],"large":["https:\/\/goias.gov.br\/ligo\/wp-content\/uploads\/sites\/61\/2026\/03\/ChatGPT-Image-30-de-mar.-de-2026-15_42_34-683x1024.jpg",683,1024,true],"1536x1536":["https:\/\/goias.gov.br\/ligo\/wp-content\/uploads\/sites\/61\/2026\/03\/ChatGPT-Image-30-de-mar.-de-2026-15_42_34.jpg",1024,1536,false],"2048x2048":["https:\/\/goias.gov.br\/ligo\/wp-content\/uploads\/sites\/61\/2026\/03\/ChatGPT-Image-30-de-mar.-de-2026-15_42_34.jpg",1024,1536,false]},"rttpg_author":{"display_name":"Hellem Correa","author_link":"https:\/\/goias.gov.br\/ligo\/author\/hellemsantos\/"},"rttpg_comment":1,"rttpg_category":"Intelig\u00eancia Artificial<\/a> Publica\u00e7\u00f5es Ligo<\/a> Tecnologia<\/a>","rttpg_excerpt":"O objetivo deste artigo \u00e9 descrever os principais aprendizados do projeto de benchmarking de modelos de Large Language Models (LLMs). Tamb\u00e9m abordaremos detalhes sobre as decis\u00f5es de arquitetura e desafios metodol\u00f3gicos. Previamente temos uma constata\u00e7\u00e3o importante: avaliar modelos de LLMs \u00e9 hoje um problema t\u00e3o complexo quanto utiliz\u00e1-los em produ\u00e7\u00e3o. Nos \u00faltimos anos, a explos\u00e3o…","_links":{"self":[{"href":"https:\/\/goias.gov.br\/ligo\/wp-json\/wp\/v2\/posts\/205543","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/goias.gov.br\/ligo\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/goias.gov.br\/ligo\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/goias.gov.br\/ligo\/wp-json\/wp\/v2\/users\/786"}],"replies":[{"embeddable":true,"href":"https:\/\/goias.gov.br\/ligo\/wp-json\/wp\/v2\/comments?post=205543"}],"version-history":[{"count":2,"href":"https:\/\/goias.gov.br\/ligo\/wp-json\/wp\/v2\/posts\/205543\/revisions"}],"predecessor-version":[{"id":205580,"href":"https:\/\/goias.gov.br\/ligo\/wp-json\/wp\/v2\/posts\/205543\/revisions\/205580"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/goias.gov.br\/ligo\/wp-json\/wp\/v2\/media\/205549"}],"wp:attachment":[{"href":"https:\/\/goias.gov.br\/ligo\/wp-json\/wp\/v2\/media?parent=205543"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/goias.gov.br\/ligo\/wp-json\/wp\/v2\/categories?post=205543"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/goias.gov.br\/ligo\/wp-json\/wp\/v2\/tags?post=205543"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}