As configurações descritas nesta página são acessadas pelo ícone de engrenagem ao lado de cada Fonte Operacional na tela Knowledge → Fontes Operacionais do Console.
Campos indexáveis
Cada campo da fonte é listado com seu formato indicado por um badge ao lado do nome. O formato reflete o tipo do dado armazenado na tabela DuckDB correspondente e não é editável pelo usuário — ele é detectado automaticamente a partir do schema do conector.
Apenas os campos marcados como indexáveis podem ser configurados com estratégia de chunking. Campos de ID, timestamps e metadados numéricos são usados como Filtros Estruturais e não passam pelo pipeline de embedding.
Chunking
O chunking define como o conteúdo de um campo é particionado antes de ser transformado em vetores. A escolha da estratégia depende do formato do campo e do tamanho típico do conteúdo.Completo
Indexa o campo inteiro como um único chunk. Indicado para campos curtos onde preservar o texto integral é mais importante do que granularidade — como títulos, nomes de usuário ou status textuais. Evite para textos com mais de 512 tokens: o chunk excederá o limite de contexto e será truncado.
Semântico
Divide o texto em blocos menores preservando coerência semântica — parágrafos e seções são mantidos íntegros, sem cortes no meio de instruções ou argumentos. Indicado para campos HTML longos como
description e body, onde fragmentos isolados mantêm significado autônomo. Esta é a estratégia padrão para campos com badge HTML.Por Item
Para campos com badge JSON Array: cada elemento do array é indexado como um chunk independente. Indicado para campos como
tags, labels ou attachments, onde cada item tem significado próprio e a busca deve ser capaz de recuperar itens individuais sem retornar o array completo.Guia de escolha por formato
Max Tokens
O Max Tokens define o tamanho máximo de cada chunk em tokens antes da vetorização. Este parâmetro controla o trade-off entre granularidade da busca e custo de embedding.
O Max Tokens só tem efeito prático nas estratégias Semântico e Completo. Na estratégia Por Item, o limite é aplicado por elemento do array.
Filtros Estruturais
Os Filtros Estruturais são campos usados para restringir resultados durante a busca semântica — sem passar pelo pipeline de embedding. São derivados automaticamente do schema do conector e não são editáveis. Exemplos típicos por conector:
Na busca via API, os filtros estruturais são passados como metadados para o Qdrant, permitindo que o agente restrinja a busca a subconjuntos específicos da base — por exemplo, apenas tickets com
status: open ou deals em um pipeline_stage específico.
Filtros Estruturais não consomem tokens de embedding e não impactam o custo de indexação. Eles são armazenados como metadados escalares no Qdrant e usados apenas para filtragem pré-busca.
SLA (minutos)
O SLA define a frequência de sincronização esperada para a fonte, em minutos. Este valor não controla o agendamento da sync — ele define o limite de tempo após o qual o status da fonte é marcado comoem risco no Console.
O status visual no Console reflete o estado atual da fonte em relação ao SLA configurado:
120 ou superior.
Tabela DuckDB
O campo Tabela DuckDB exibe o nome da tabela no data lake onde os dados brutos do conector são armazenados. Este campo é somente leitura e é determinado pelo pipeline de ingestão configurado no Data Pipelines. O Knowledge Worker lê desta tabela para executar o pipeline de chunking e embedding. O formato do nome segue a convenção:Se a tabela exibida estiver vazia ou ausente, significa que o pipeline de ingestão correspondente ainda não executou com sucesso. Verifique o status do pipeline em Data Pipelines antes de configurar a indexação.
Exemplo de configuração completa
A seguir, uma configuração típica para a Fonte Operacional Zendesk Tickets, onde o campodescription é HTML longo e o campo subject é texto curto:
SLA: 60 minutos
Tabela DuckDB:
strattum.zendesk__tickets