Manual de Saídas Estruturadas com LLM

• Grandes modelos de linguagem (LLM): um guia prático para desenvolvedores para resolver a instabilidade que ocorre quando geram formatos estruturados como JSON, XML e código
• Devido à sua natureza probabilística, a saída pode se quebrar de forma não determinística, e o material aborda técnicas determinísticas de estruturação para compensar isso
• Abrange todo o processo, incluindo princípios de funcionamento internos, escolha de ferramentas e técnicas, implantação, escalabilidade e otimização de custos, e melhoria da qualidade da saída
• Reúne as informações mais recentes de uma área de geração estruturada em rápida evolução em um documento continuamente atualizado
• Material de referência essencial para desenvolvedores que usam LLMs programaticamente em extração de dados, geração de código e chamada de ferramentas

---

Necessidade de saídas estruturadas de LLM

• LLMs geralmente geram saídas sintaticamente válidas em JSON, XML, código etc., mas, devido à sua natureza probabilística, podem ocorrer erros de formato ou resultados incompletos
  • Isso causa problemas em processos automatizados como extração de dados, geração de código e chamada de ferramentas
• Para resolver esses problemas, são necessários métodos determinísticos de saída estruturada
• O manual cobre o conjunto de ferramentas e técnicas para ajudar desenvolvedores a implementar saídas estruturadas de forma confiável

Principais conteúdos do manual

• Inclui temas práticos como princípios de funcionamento internos, ferramentas e técnicas ideais, critérios para escolha de ferramentas, métodos de construção, implantação e escalabilidade de sistemas, otimização de latência e custos e melhoria da qualidade da saída
• Cada tópico é organizado em uma abordagem passo a passo aplicável diretamente por desenvolvedores
• Consolida em um único documento as pesquisas mais recentes e as ferramentas open source relacionadas a saídas estruturadas

Atualidade e atualizações

• Como as tecnologias de geração estruturada estão evoluindo muito rapidamente, materiais existentes ficam defasados em pouco tempo
• Este manual é mantido como um documento vivo (living document), atualizado regularmente
• Assim, desenvolvedores podem acessar informações atualizadas em um só lugar sem precisar vasculhar diversos artigos, blogs e repositórios no GitHub

Como usar

• Pode ser lido do começo ao fim ou usado como material de consulta para encontrar imediatamente os tópicos necessários
• Com foco em desenvolvedores em atividade, permite referência rápida ao resolver problemas específicos

Criadores e comunidade

• O manual foi produzido pela equipe da Nanonets
  • Eles mantêm o modelo Nanonets-OCR e a biblioteca open source de processamento de documentos docstrange
• Por meio de uma newsletter da comunidade de desenvolvedores de LLM, oferecem quinzenalmente os insights mais recentes, avanços e ferramentas e técnicas úteis

[GN⁺]

Comentários no Hacker News

• Um guia realmente lindo. Gostei especialmente das animações de troca de abas em várias páginas
  Eu achava que entendia bem generation com restrição por gramática (até contribui um pouco para a implementação de grammar no llama.cpp), mas mesmo assim tirei novos insights deste guia
  Acho que saída estruturada é um dos recursos mais subestimados dos motores de LLM. Graças às restrições gramaticais, dá para usar LLMs de forma confiável como parte de pipelines maiores, como um agent com tool-calling
  A saída pode estar semanticamente errada, mas gramaticalmente estará sempre correta. Isso é especialmente importante ao usar modelos locais
  Por exemplo, como no exemplo do filtro de spam em Raspberry Pi do Jart, se você aplicar uma grammar para que o modelo TinyLlama produza apenas "yes" ou "no", ele funciona de forma confiável mesmo em hardware pequeno

  • Fiquei curioso sobre o que acontece quando o modelo quer produzir outra saída, e se é melhor tratar isso dentro do llamafile ou num wrapper externo. Também queria saber como configurar retries ou delimitar faixas em JSON

• Guia excelente. Pesquisei structured generation no doutorado, então estou compartilhando alguns materiais para quem tiver interesse
  Como bibliotecas, há Outlines, Guidance e XGrammar
  Como artigos, recomendo Efficient Guided Generation for Large Language Models, Automata-based constraints for language model decoding e Pitfalls, Subtleties, and Techniques in Automata-Based Subword-Level Constrained Generation
  Como posts de blog, há LLM Decoding with Regex Constraints e Coalescence: making LLM inference 5x faster

  • Não entendo exatamente qual é o papel do Outlines na stack. Queria saber se ele é parecido com as APIs de saída estruturada oferecidas por grandes provedores de modelos, ou se dá para compará-lo a projetos como o BAML
  • Na paper DFybOGeGDS, a parte de canonical filtering parece não considerar pretokenization. Gostaria de saber se existe pesquisa sobre canonical generation que reflita regexes reais de pretokenization
  • Você chamou isso de “outras referências”, mas parece que só repetiu a lista de bibliotecas que já está no guia
  • Parece um verdadeiro tesouro. Restrições baseadas em autômatos são um tema fascinante

• Guia muito bem organizado. Se quiser saber mais sobre as otimizações de Guidance & llguidance, vale consultar nosso artigo curto

  • Sou um dos autores que leu o artigo. Fiquei especialmente impressionado com a implementação de slicing para dense token mask

• Este guia cobre bem os dois métodos mais usados. Ainda assim, a constrained generation pode divergir da distribuição original do LLM
  Por exemplo, quando o LLM gera um objeto estruturado longo, ele tende a preferir padrões como '…', mas a geração restrita pode forçar o fechamento com aspas e afins, produzindo um resultado pior
  Já o resampling é mais estável, porque repete até sair um resultado válido
  Além disso, em vez de ir aumentando o contexto ao acrescentar erros de schema, acho melhor simplesmente tentar de novo, tanto em qualidade quanto em custo

  • Também dá para usar uma abordagem híbrida. Primeiro tenta geração não restrita (unconstrained) e, só se falhar, aplica geração restrita (constrained)

• Fico curioso se modelos SoTA, como Opus e Gemini, ainda precisam de enforcement de schema de saída
  Hoje em dia, esses modelos quase não cometem erros de sintaxe ao gerar JSON ou código, então queria saber se ainda fazem validação de schema internamente
  Entendo que modelos pequenos precisem de geração estruturada

  • Quanto mais complexo o schema, mais útil isso continua sendo, porque LLMs ainda são fracos em contagem. Mesmo com modelos melhores, eles não são perfeitos por causa da natureza probabilística
  • Até modelos recentes às vezes acrescentam tokens desnecessários como json\n, então ainda é mais seguro especificar um schema de resposta JSON

• Forçar saída estruturada causa queda de desempenho. Em alguns casos, pode ficar 2 a 3 vezes mais lento. É preciso avaliar se esse custo vale a pena em cada situação

• Guia realmente impressionante. Queria que algo assim existisse um ano atrás. Com certeza vou compartilhar com as pessoas ao meu redor

• Bom guia. Gostei especialmente do diagrama de masked decoding

  • Sou um dos autores. Vou verificar o problema do link. Como todos os provedores de modelos comerciais estão adicionando recursos de saída estruturada, vamos continuar atualizando o guia

• Fico curioso se existe algum formato de saída mais confiável e fácil de fazer parsing do que JSON. YAML e TOML têm suas próprias desvantagens, mas talvez sejam melhores em número de tokens ou custo

  • Eu uso o formato TOON para esse propósito
  • Assim como pessoas acham chato escrever JSON, talvez para LLMs seja melhor gerar resultados em forma de código, como TypeScript. Mas, por segurança, isso exigiria sandboxing e limite de recursos
  • Estamos desenvolvendo um pipeline de transformação de conteúdo baseado em Markdown + YAML front matter. O tooling para JSON é fraco, mas validar não é difícil
  • Eu forço schema XML com regex e decodifico com um parser XML. Em especial, envolvo blocos de código em CDATA para dar mais liberdade. A saída estruturada por regex da API da OpenAI é mais adequada para código do que JSON
  • Vale a pena fazer uma avaliação (evaluation) você mesmo. Nos meus experimentos, XML sempre teve resultados melhores que JSON em tarefas out-of-distribution

• Fiquei curioso sobre a stack técnica da página de docs/cookbook. Não parece MkDocs nem GitBook, então queria saber o que foi usado

  • Foi usado Docusaurus