Anexe PDFs, imagens, gravações de áudio, documentos Office, folhas de cálculo, slides e ficheiros de texto a qualquer pedido de enriquecimento, geração de esquemas, geração de amostras, edição de esquemas com IA ou playground. Os ficheiros chegam ao modelo como bytes nativos (para modelos com capacidade de PDF, visão e áudio) ou como texto extraído no servidor e inserido no prompt — sem necessidade de OCR, transcrição, conversão ou divisão manuais.
Cada tipo MIME suportado tem um modo de entrega configurado pelo administrador. O modo determina como o ficheiro chega ao model.
Os bytes originais são passados ao modelo como BinaryContent. O modelo lê o ficheiro diretamente — sem pré-processamento do lado do servidor.
Requer um modelo com a flag de capacidade correspondente (supports_pdf_input para PDFs,supports_vision para imagens,supports_audio_input para áudio). O seletor de modelos é filtrado automaticamente para mostrar apenas modelos compatíveis.
Um extrator do lado do servidor é executado uma vez no momento do carregamento e coloca em cache o texto resultante. Em cada chamada LLM subsequente, o texto em cache é incorporado no prompt do utilizador.
Nenhuma capacidade de modelo necessária — funciona com todos os modelos. Texto simples e Markdown ignoram o extrator e descodificam os bytes brutos diretamente.
19 formatos são ativados por predefinição. Os administradores de sistema podem alternar qualquer formato entre o modo binary einline_text, alterar o respetivo rótulo ou desativá-lo por completo em Gestão de Modelos → Políticas de documentos.
| Formato | Extensões | Modo predefinido | Capacidade / extrator |
|---|---|---|---|
| Documento PDF | binary | supports_pdf_input | |
| Imagem PNG | .png | binary | supports_vision |
| Imagem JPEG | .jpg, .jpeg | binary | supports_vision |
| Áudio MP3 | .mp3 | binary | supports_audio_input |
| Áudio WAV | .wav | binary | supports_audio_input |
| Áudio M4A | .m4a | binary | supports_audio_input |
| Áudio OGG | .ogg, .oga | binary | supports_audio_input |
| Áudio FLAC | .flac | binary | supports_audio_input |
| Texto simples | .txt | inline_text | descodificação em bruto |
| Markdown | .md, .markdown | inline_text | descodificação em bruto |
| Word (.doc antigo) | .doc | binary | docx2txt |
| Word (.docx) | .docx | binary | python-docx |
| Texto OpenDocument | .odt | binary | odfpy |
| Rich Text Format | .rtf | binary | striprtf |
| Ebook EPUB | .epub | binary | ebooklib |
| HTML | .html, .htm | binary | beautifulsoup |
| CSV | .csv | binary | csv (stdlib) |
| Folha de cálculo (.xlsx) | .xlsx | binary | openpyxl |
| Apresentação (.pptx) | .pptx | binary | python-pptx |
Quando anexa mais do que um ficheiro à geração de amostras, a primeira questão é qual a relação entre eles — e errar aí produz silenciosamente uma amostra sem sentido. Por isso, é perguntado explicitamente antes de ser gerado o que quer que seja.
Um contrato e a sua adenda, uma especificação e a sua ficha técnica: os ficheiros são lidos em conjunto como uma única entidade.
Dez faturas, dez currículos. É derivado o tipo mais restrito que abrange todos eles, e os valores da amostra provêm de um documento escolhido em vez de serem misturados entre os dez — uma amostra costurada a partir de dez fontes não descreve nada real.
Nove faturas e uma fotografia de férias: em vez de adivinhar, o trabalho faz uma pausa e pergunta se deve excluir o intruso. Ficheiros sem absolutamente nada em comum fazem o trabalho falhar de imediato, indicando esse motivo.
O mesmo mecanismo de pausa-e-pergunta cobre qualquer outra ambiguidade que o planeador encontre: a tarefa para, expõe as suas perguntas e retoma com as suas respostas — na aplicação sob a forma de caixa de diálogo e, através da API e do MCP, como um passo de resposta explícito. Uma suposição errada é mais barata de evitar do que de descobrir no schema gerado.
Há uma coisa de que os documentos não o dispensam: um esquema gerado a partir dos seus ficheiros começa com a verificação de ambiguidade ativa, tal como qualquer outro. Essa verificação pergunta se o nome de uma propriedade admite mais do que um significado — uma questão sobre a forma como o esquema está redigido, não sobre a origem dos valores desta execução. O seu documento fixou os valores uma vez; o esquema continua a ser reutilizado com entidades que nunca abrangeu.
(organization_id, sha256).inline_text, o extrator é executado no momento do carregamento e o texto resultante é armazenado em cache na linha do anexo. As chamadas LLM subsequentes reutilizam o texto em cache — sem custo de reextração. Os formatos binary ignoram este passo.DELETE /api/attachments/{id} — um prático passo de limpeza pós-enriquecimento. A eliminação é limitada à organização e devolve { success, id, filename }.Os anexos podem ser carregados e eliminados programaticamente, não apenas a partir da interface web: o conector n8n carrega através de multipart nativo, os conectores Make.com e MCP carregam através da rota base64 JSON, e qualquer cliente pode usar diretamente a REST API (DELETE /api/attachments/{id} para limpeza).
Quando anexa um ficheiro binário com um requisito de capacidade (PDF, imagem ou áudio), o seletor de modelos é filtrado para mostrar apenas os modelos que declaram essa capacidade. Se anexar vários ficheiros com requisitos diferentes, apenas aparecem os modelos que satisfazem todos os requisitos.
A API aplica a mesma regra: associar um model incompatível a um attachment binário devolve 400 model_lacks_attachment_capability, pelo que as integrações que contornam a interface obtêm um erro claro de pré-verificação em vez de uma falha do provider a meio do trabalho. Os attachments de texto inline nunca impõem qualquer requisito.
| Ficheiros anexados | Models elegíveis |
|---|---|
| 1 PDF | supports_pdf_input |
| 1 PNG | supports_vision |
| 1 MP3 | supports_audio_input |
| 1 PDF + 1 PNG | supports_pdf_input E supports_vision |
| 1 DOCX (modo binário, sem capacidade) | Todos os modelos — assume-se suporte nativo de bytes quando nenhum sinalizador de capacidade está definido |
| 1 TXT ou 1 MD (modo inline_text) | Todos os modelos — o texto é incorporado no prompt |
Os anexos são faturados como tokens de entrada reportados pelo provider do model — o Entity Enricher não cobra uma taxa separada por documento. O custo depende do tipo de ficheiro e do model selecionado.
Consomem tokens de entrada específicos de cada modelo. A Anthropic cobra cerca de 1700 tokens por página de PDF; a OpenAI cobra as entradas de visão pelo número de blocos; os modelos com capacidade de áudio medem a entrada de áudio em proporção à respetiva duração. Consulte a ficha de preços do seu modelo em Modelos e Preços.
O texto extraído consome tokens de entrada à taxa padrão de texto. Documentos grandes estão limitados a 500 KB de texto extraído — conteúdo mais longo é truncado.