Digamos que você está criando busca sobre a documentação interna da sua equipe — guias, runbooks, postmortems. Você tem uma tabela com embeddings automáticos: você insere texto, o Manticore executa o modelo e preenche a coluna vetorial para você. Você carrega um documento de 4.000 palavras. A inserção funciona. A busca funciona. Exceto que o modelo tem uma janela de entrada de 512 tokens, e aquele documento tem cerca de 5.000 tokens. O modelo leu as primeiras 380 palavras e descartou as outras 3.600.

O Manticore agora lida com isso na definição da tabela: adicione chunk_strategy à coluna vetorial no CREATE TABLE, e o Manticore divide cada documento em fragmentos, faz embedding de cada fragmento e busca em todos eles. Cinco estratégias: truncate, mean, fixed, recursive, sentence. Um documento continua sendo um único resultado de busca. Os fragmentos competem individualmente, e o Manticore retorna o documento uma vez, com knn_dist() reportando a distância para seu fragmento mais próximo. k conta documentos, não fragmentos.

Medido no manual do Manticore (189 páginas, ~298k palavras): recall@5 subiu de 55,1% para 83,3% e MRR de 0,44 para 0,70, com ~2,5× a RAM e ~4× o tempo de ingestão. Consultas nunca são fragmentadas. Uma consulta é curta o suficiente para ser embedada como um todo; apenas documentos armazenados são divididos.