Perplexity pplx-embed-v2-late divide a busca multimodal entre indexação de 9B e consultas de 0,6B

A Perplexity lançou dois modelos pplx-embed-v2-late com uma divisão notável: um modelo de 9B cria índices mais ricos, enquanto um modelo de 0,6B processa consultas mais rápidas. Ambos os modelos pesquisam texto, imagens e páginas de documentos renderizadas no mesmo espaço de embeddings.

Essa combinação importa mais do que as contagens de parâmetros. Equipes de recuperação geralmente escolhem um único modelo de embeddings e aceitam seus custos de qualidade, latência e infraestrutura em toda a operação. A Perplexity propõe, em vez disso, gastar mais computação quando os documentos entram no índice e usar um codificador menor no caminho da solicitação.

Os modelos também desafiam o pipeline padrão de busca em PDFs visualmente complexos. Em vez de extrair texto por OCR, um desenvolvedor pode codificar uma página renderizada e recuperá-la com uma consulta de texto. No entanto, a abordagem substitui parte dos custos de análise por índices maiores e pontuação mais cara.

A Perplexity lançou dois modelos que funcionam como um único sistema de recuperação

O lançamento central não é simplesmente um par de checkpoints. Trata-se de um design assimétrico de recuperação construído em torno de um espaço de embeddings compartilhado.

A Perplexity publicou as versões de 0,6B e 9B do pplx-embed-v2-late sob licença MIT. Os pesos estão disponíveis em repositórios separados de modelos no Hugging Face, incluindo o modelo de 0,6B e sua contraparte maior de 9B.

Ambos os modelos são recuperadores multimodais de interação tardia. Interação tardia significa que documentos e consultas são codificados separadamente, mas seus vetores individuais de tokens interagem durante a pontuação. Isso difere da recuperação densa, que geralmente reduz cada entrada a um único vetor.

Cada modelo produz um vetor de 128 dimensões por token. A pontuação MaxSim então encontra a correspondência mais forte de token do documento para cada token da consulta e soma essas similaridades máximas. Diferentes termos da consulta podem, portanto, corresponder a diferentes regiões de uma página.

A Perplexity construiu a família sobre backbones Qwen3.5 com atenção bidirecional. De acordo com o model card, ambos os modelos lançados foram destilados de um professor interno ColBERT de 18B. ColBERT é uma arquitetura de recuperação que preserva representações em nível de token para comparação tardia.

A empresa fez fine-tuning completo do modelo menor. Para a versão de 9B, ajustou integralmente as oito camadas finais do transformer, enquanto adaptou as camadas restantes e o codificador de visão com LoRA.

Os tamanhos anunciados também exigem contexto. O checkpoint menor contém cerca de 594 milhões de parâmetros totais, mas a Perplexity informa 340 milhões de parâmetros ativos. A codificação de texto ativa aproximadamente 240 milhões de parâmetros, enquanto a codificação de imagens ativa cerca de 340 milhões.

A Perplexity produziu a torre de texto menor ao podar uma torre Qwen3.5-0.8B de 24 camadas para 12 camadas. Sua tabela de embeddings de tokens responde por outros 254 milhões de parâmetros, segundo a empresa.

Essa construção mira a economia no tempo de consulta. A indexação pode ser executada offline, em hardware paralelo, e apenas quando os documentos mudam. A codificação de consultas fica no caminho de solicitações ao vivo, onde cada milissegundo adicional afeta a experiência do usuário.

O espaço compartilhado conecta essas duas cargas de trabalho. Uma empresa pode codificar documentos com o modelo de 9B e depois pesquisar o índice resultante com consultas codificadas pelo modelo de 0,6B. Substituir o codificador de consultas não exige reconstruir esse índice.

A Perplexity também descreve uma configuração local-nuvem. Um dispositivo poderia codificar uma consulta privada ou um documento local com o modelo menor e então comparar essa representação com resultados de um índice de 9B hospedado na nuvem.

Essa flexibilidade continua sendo uma proposta técnica, e não uma promessa de produto gerenciado. O model card afirma que os checkpoints funcionam com versões recentes de Sentence Transformers e Transformers. Também afirma que nenhum provedor de inferência atualmente atende ao checkpoint menor.

A Perplexity diz que embeddings de interação tardia, densos e contextuais chegarão progressivamente à sua plataforma de API. Até isso acontecer, as equipes que avaliam o pplx-embed-v2-late devem presumir que precisarão operar os próprios modelos e a infraestrutura de recuperação.

O mecanismo do Perplexity pplx-embed-v2-late preserva detalhes da página

A Perplexity aposta que a correspondência em nível de token pode reter evidências que um único vetor de documento frequentemente comprime ou elimina.

Um modelo de embeddings densos representa uma consulta e um documento com um vetor cada. A recuperação se torna uma busca eficiente por vizinhos mais próximos, que funciona bem em coleções muito grandes. Ainda assim, o vetor precisa resumir todos os detalhes potencialmente relevantes.

Essa compressão se torna mais difícil à medida que os documentos ficam mais longos ou contêm seções não relacionadas. Torna-se ainda mais difícil quando as páginas incluem gráficos, tabelas, diagramas, legendas e significado dependente do layout. Uma única representação tem espaço limitado para todos esses sinais.

A segmentação reduz a quantidade de informação inserida em cada vetor. No entanto, ela pode separar uma tabela de seu rótulo, um gráfico de sua legenda ou uma cláusula de uma qualificação importante. As regras de análise também variam entre formatos de documento.

Um cross-encoder resolve parte do problema ao processar uma consulta e um candidato em conjunto. Essa atenção conjunta permite comparações detalhadas, mas o modelo precisa ser executado novamente para cada par consulta-candidato. Em geral, é prático apenas para reordenar uma lista curta de candidatos.

A interação tardia ocupa o meio-termo. Os documentos ainda recebem suas representações antes da chegada de uma consulta. O sistema de recuperação então realiza várias comparações em nível de token, em vez de calcular um único produto interno por candidato.

A explicação técnica da Perplexity ilustra o método com MaxSim. Cada token da consulta seleciona sua melhor correspondência de token do documento, e o sistema adiciona essas similaridades a uma pontuação do documento.

Considere uma consulta sobre uma lei, um prazo e uma exceção. Um único vetor de consulta mistura esses conceitos. O MaxSim pode associar cada conceito a uma passagem, rótulo ou região visual separada dentro da mesma página.

O mesmo mecanismo se aplica a imagens. Uma página de PDF renderizada entra no codificador de visão como imagem, em vez de passar primeiro por OCR. Uma consulta de texto pode então recuperar diretamente a representação visual.

Isso não significa que o modelo “lê” um arquivo PDF sem preparação. A aplicação precisa renderizar cada página relevante como imagem e codificar essa imagem. A distinção diz respeito à forma como a representação pesquisável é produzida.

Ignorar o OCR pode preservar layout e relações visuais que a extração de texto perde. As posições de linhas e colunas de uma tabela financeira podem carregar um significado essencial. Um diagrama pode comunicar relações que sua legenda descreve apenas parcialmente.

A recuperação sem OCR também pode evitar erros de reconhecimento em digitalizações, fontes incomuns e estruturas de página complexas. No entanto, ela não fornece automaticamente texto extraído para destaque, citação, controles de acesso ou contexto posterior de modelos de linguagem.

Por isso, muitas aplicações manterão a análise em conjunto com a recuperação visual. Embeddings visuais podem identificar uma página promissora, enquanto OCR ou texto nativo de PDF fornece trechos exatos posteriormente. As técnicas podem se complementar.

A Perplexity treinou os dois modelos com 186 milhões de pares consulta-documento extraídos de 594 conjuntos de dados e 46 idiomas. Ela informa que 88,3% eram pares texto-para-texto, 8,3% texto-para-imagem e 3,4% texto-para-documento visual.

A mistura de amostragem aumentou a presença relativa de dados visuais. A Perplexity afirma que seus pesos finais de amostragem produziram 56,5% de exemplos texto-para-texto, 30,9% texto-para-imagem e 12,6% texto-para-documento visual.

Esses detalhes importam porque “multimodal” cobre diversos problemas diferentes. Recuperar uma fotografia não é idêntico a encontrar evidências dentro de uma página densa de relatório anual. O equilíbrio do treinamento influencia quais casos de uso recebem a representação mais forte.

O model card divulgado também especifica uma restrição de implementação. Itens somente de texto e somente de imagem exigem chamadas de codificação separadas, e entradas mistas de texto com imagem não são compatíveis em um único item. As aplicações precisam projetar a ingestão adequadamente.

Embeddings compartilhados pressionam pipelines de recuperação de modelo único

A pressão competitiva recai sobre sistemas de recuperação que usam um único tamanho de codificador tanto para indexação offline quanto para consultas sensíveis à latência.

A maioria das implantações de embeddings trata o modelo como um componente uniforme. O mesmo checkpoint incorpora um corpus e cada consulta recebida. Essa simetria simplifica as operações, mas ignora a economia diferente desses trabalhos.

A codificação de documentos geralmente é uma despesa amortizada. Uma empresa pode processar uma página uma vez e depois responder a milhares de buscas sobre sua representação armazenada. Ela pode agendar a indexação em hardware maior ou executar o trabalho em lotes.

A codificação de consultas se repete a cada busca. Ela afeta tempo de resposta, concorrência e viabilidade em dispositivos. Executar um grande codificador de visão e linguagem para cada solicitação pode eliminar os ganhos obtidos durante a indexação offline.

O espaço compartilhado da Perplexity separa essas escolhas. O modelo de 9B pode gastar computação adicional capturando informações dos documentos, enquanto o modelo de 0,6B produz consultas compatíveis. O índice retém parte do benefício do codificador maior de documentos.

Na avaliação da Perplexity em 72 tarefas de recuperação específicas de domínio, a configuração assimétrica obteve, em média, 1,6 ponto percentual a mais do que usar 0,6B nos dois lados. O codificador de consultas permaneceu inalterado.

Para recuperação de imagens no ViDoRe v3, a configuração de consulta com 0,6B e documento com 9B obteve 63,5% de nDCG@10. A configuração simétrica de 0,6B obteve 62,3%, uma diferença de 1,2 ponto.

Usar o modelo de 9B tanto para consultas quanto para documentos ainda produziu a média de domínio mais alta relatada, de 81,3%. A Perplexity afirma que a configuração assimétrica recuperou aproximadamente metade da lacuna de qualidade de texto sem aumentar a codificação no tempo de consulta.

Esse é o argumento mais prático do lançamento. O modelo menor não precisa igualar sozinho todos os resultados do modelo de 9B. Ele só precisa tornar um índice de 9B de alta qualidade útil sob restrições mais rigorosas de atendimento.

A abordagem pressiona modelos densos padrão, mas também compete com outros recuperadores multivetor. A Perplexity compara seus modelos com Qwen3-VL-Embedding, EVIE, TopK Embed e a família Nemotron ColEmbed da Nvidia.

Na parte pública de imagens do ViDoRe v3, a Perplexity informa 65,2% de nDCG@10 para o modelo de 9B e 62,3% para o modelo de 0,6B. As pontuações correspondentes em markdown foram 64,7% e 61,2%.

A Perplexity afirma que o modelo de 0,6B ficou a 1,2 ponto do Nemotron ColEmbed V2 8B em recuperação de imagens. Também enfatiza que suas saídas usam 128 dimensões por token.

Essa comparação de dimensões fala diretamente da viabilidade do índice. A Perplexity lista dimensões de saída de 2.048 para EVIE-4.5B e 4.096 para modelos maiores de EVIE e Nemotron. Menos dimensões podem reduzir o tamanho de cada vetor de token armazenado.

As dimensões, por si só, não determinam o custo em produção. O número de tokens retidos, a precisão numérica, o método de compressão, a estrutura do índice e a estratégia de geração de candidatos também importam. A Perplexity não publicou um cálculo completo de armazenamento para corpora representativos.

A alternativa não está desaparecendo. A recuperação densa continua mais fácil de indexar e pesquisar em escala enorme. Cross-encoders continuam atraentes para reordenação. A busca lexical híbrida ainda protege identificadores exatos, nomes e termos técnicos raros.

Pplx-embed-v2-late tem, portanto, mais probabilidade de se tornar uma etapa em uma pilha de recuperação do que uma substituição universal. A própria Perplexity descreve a interação tardia como uma recuperação inicial mais rica ou como uma etapa posterior em sistemas em escala web.

Para equipes que criam uma base de conhecimento pesquisável, a questão de design se torna mais específica. Elas precisam decidir quais documentos justificam indexação visual de múltiplos vetores e quais continuam eficientes com recuperação de texto.

Os Resultados de Benchmark São Fortes, mas Continuam Sendo Reportados pela Empresa

As pontuações publicadas justificam testes sérios, mas não definem a latência, o armazenamento ou a qualidade de recuperação no mundo real.

A Perplexity reporta uma pontuação de 64,0% em precisão de respostas para o modelo de 9B no BrowseComp+. Esse resultado superou o modelo ColBERT seguinte em 4,9 pontos percentuais e o modelo denso seguinte em 8,7 pontos.

O BrowseComp+ usa um corpus fixo em vez de pesquisa web ao vivo. Seu design de benchmark inclui 830 consultas difíceis e cerca de 100.000 documentos web selecionados, com evidências de apoio verificadas por humanos.

Uma coleção fixa melhora a reprodutibilidade. Pesquisadores podem separar a qualidade de recuperação das mudanças em mecanismos de busca comerciais ou na web aberta. Ela também torna o benchmark mais restrito do que operar um índice web ao vivo e em constante mudança.

A Perplexity combinou seu recuperador com o GPT-OSS-120B em alto esforço. Outro modelo de linguagem avaliou se a resposta gerada correspondia à referência. Os 64,0% reportados, portanto, medem um sistema de agente e recuperador, não uma pontuação de embeddings isolada.

A empresa afirma que o modelo de 0,6B também superou todos os modelos fora da família pplx-embed-v2-late. No entanto, o anúncio não fornece todas as pontuações subjacentes como texto pesquisável. O relatório técnico completo está programado para publicação posterior.

No MADQA, a Perplexity reporta 92,4% de precisão de respostas para seu recuperador de 9B e 90,1% para o modelo de 0,6B. Ambos foram combinados com o Gemini 3.5 Flash.

O MADQA avalia busca agêntica em PDFs heterogêneos. O artigo do MADQA descreve 2.250 perguntas elaboradas por humanos e fundamentadas em 800 documentos, enquanto a avaliação reportada usa um subconjunto de 500 perguntas.

A Perplexity afirma que esse subconjunto abrange mais de 18.000 páginas. As perguntas não podem ser respondidas com conhecimento geral, portanto o agente precisa recuperar evidências da coleção de documentos.

O resultado de 9B superou um recuperador padrão da Mixedbread com o mesmo agente por 3,5 pontos. O Mixedbread Agentic Search atingiu 93,4%, resultado que, segundo a Perplexity, ficou dentro de seu intervalo de confiança.

Essa distinção é importante. O Mixedbread Agentic Search inclui um subagente de busca capaz de planejar e executar várias pesquisas por chamada externa. O Pplx-embed-v2-late funciona como um recuperador dentro do agente, e não como um serviço inteiro de busca agêntica.

Os autores do MADQA também identificam uma limitação mais ampla nos agentes de documentos. O estudo constatou que sistemas fortes podem se aproximar da precisão humana enquanto acertam perguntas diferentes. Agentes frequentemente compensam estratégias fracas por meio de buscas repetidas.

Um recuperador melhor pode reduzir esse desperdício, mas não pode garantir bom planejamento de busca ou síntese de evidências. Precisão de recuperação, precisão de respostas, qualidade de evidências no nível da página, latência e contagem de chamadas de ferramentas devem ser avaliadas separadamente.

A Perplexity também reporta resultados fortes no ViDoRe v3. Esse benchmark público oferece aos desenvolvedores uma visão mais direta da recuperação de páginas do que testes de geração de respostas. Ainda assim, coleções de benchmark não conseguem reproduzir todos os formatos de documentos corporativos.

Corpora reais contêm duplicatas, restrições de acesso, revisões, anotações manuscritas, digitalizações de baixa resolução e páginas com layouts quase idênticos. Também contêm abreviações específicas de domínio que podem estar ausentes de misturas gerais de treinamento.

O benchmark interno PPLX-Q2I introduz outra lacuna de verificação. A Perplexity o construiu a partir de logs de produção de busca de imagens e avaliou 10.000 consultas em relação a 100.000 imagens. Pesquisadores externos ainda não conseguem reproduzir esse teste privado.

A Perplexity afirma que ambos os modelos superaram o Qwen3-VL-Embedding-8B em mais de nove pontos no PPLX-Q2I. Também afirma que o modelo de 9B ficou cerca de dois pontos atrás do Gemini Embedding 2. Essas conclusões devem continuar atribuídas à empresa.

O lançamento merece atenção porque os pesos e os checkpoints de benchmarks públicos permitem testes independentes. Ele não merece aceitação automática como a melhor opção para todos os corpora.

Desenvolvedores devem construir um conjunto de avaliação a partir de seus próprios documentos e consultas reais. Ele deve incluir buscas exatas, evidências entre páginas, tabelas visuais, terminologia obscura e negativos intencionalmente difíceis.

Eles também devem comparar sistemas completos equivalentes. Uma configuração não deve receber OCR melhor, mais rodadas de busca ou um reranqueador mais forte, a menos que essas diferenças representem o design de produção pretendido.

A Busca Multi-Vetor Desloca Custos em Vez de Eliminá-los

O Pplx-embed-v2-late evita um gargalo de compressão ao aceitar representações maiores e uma pontuação de candidatos mais complexa.

A recuperação densa armazena um vetor para cada documento ou trecho. A interação tardia mantém vários vetores, frequentemente um para cada token não podado. Uma página longa pode, portanto, gerar muitas representações pesquisáveis.

Mesmo com 128 dimensões, esses vetores se acumulam. O armazenamento do índice depende da contagem de tokens, do formato numérico, do esquema de compressão, dos metadados e do mecanismo de recuperação. Representações visuais no nível da página podem alterar ainda mais o cálculo.

O MaxSim também exige mais trabalho do que um único produto interno entre consulta e documento. Cada token da consulta precisa localizar sua correspondência mais forte entre os tokens do documento. Um serviço eficiente exige indexação especializada, poda ou recuperação em etapas.

A Perplexity reconhece essa troca em seu anúncio. A empresa afirma que a interação tardia exige escolhas de indexação e serviço diferentes da recuperação aproximada de vizinhos mais próximos com vetor único. Documentos mais longos elevam o custo.

O espaço de modelo compartilhado ajuda na codificação de consultas, mas não elimina os custos de pontuação dos candidatos. Um codificador leve de consultas ainda pode produzir uma solicitação cara de comparar com milhões de vetores de tokens.

As equipes devem, portanto, medir quatro componentes de latência separados: codificação da consulta, geração de candidatos, pontuação MaxSim e reranqueamento ou geração posteriores. Reportar apenas o tempo de inferência do modelo oculta grande parte da experiência do usuário.

O uso de memória também exige medição cuidadosa. O checkpoint de 9B pode ser um componente offline, mas indexar um corpus que muda com frequência ainda pode exigir capacidade persistente de GPU. Recodificar revisões de documentos acrescenta trabalho operacional.

Um pipeline de documentos visuais exige renderização de páginas antes da inferência do modelo. PDFs grandes demandam paginação, normalização de imagens, tratamento de falhas, mapeamento de metadados e fluxos de exclusão. O OCR pode desaparecer da recuperação, mas a ingestão continua sendo um problema de sistema.

O OCR também mantém vantagens. O texto extraído oferece suporte a busca por palavras-chave, destaque, citações, revisão de conformidade e contexto direto para modelos de linguagem. Um embedding de página renderizada não consegue reproduzir essas funções sozinho.

O design de produção mais provável é híbrido. Um sistema pode indexar texto nativo para recuperação exata, manter embeddings visuais para páginas sensíveis ao layout e usar um reranqueador em um conjunto limitado de candidatos.

O controle de acesso merece a mesma atenção. Índices de recuperação precisam filtrar materiais não autorizados antes que os resultados cheguem a um agente. Um espaço compartilhado de embeddings local-nuvem não fornece automaticamente permissões de documentos ou garantias de privacidade.

O caminho de consultas proposto no dispositivo levanta outras questões. A Perplexity considera o modelo de 0,6B adequado para dispositivos de borda, mas as classes de dispositivos variam amplamente. Limites de memória, suporte a aceleração, quantização e uso de bateria determinarão a viabilidade real.

O checkpoint publicado usa tensores F32 em sua página no Hugging Face. Desenvolvedores provavelmente testarão variantes de menor precisão ou específicas de plataforma, mas essas conversões exigem verificações de qualidade. A quantização pode alterar os rankings de recuperação.

A compatibilidade é outra preocupação em estágio inicial. O cartão do modelo exige Sentence Transformers 6.0 ou mais recente e Transformers 5.4 ou mais recente. Ele também alerta que o PyLate insere marcadores de consulta e documento em uma posição diferente.

A exportação usa módulos nativos do Sentence Transformers e não exige código Python personalizado. Isso reduz o atrito de integração, mas não fornece um índice completo de produção nem um endpoint gerenciado.

O licenciamento é comparativamente simples. A licença MIT permite amplo uso e modificação. Ainda assim, adotantes precisam analisar dependências do modelo, considerações sobre dados de treinamento e seu próprio tratamento de documentos sensíveis.

“Código aberto” também pode obscurecer distinções importantes. A Perplexity lançou pesos abertos e instruções de implementação, mas não divulgou o corpus completo de treinamento nem o professor interno de 18B.

A empresa afirma ter excluído do treinamento conjuntos de dados relacionados aos benchmarks avaliados. Essa é uma alegação metodológica útil, mas pesquisadores independentes precisam do relatório técnico prometido para examinar os controles de contaminação e os detalhes da avaliação.

A conclusão prudente não é que a interação tardia custa demais. É que a despesa muda de lugar. As equipes trocam a dependência de OCR e a compressão de vetor único por índices mais ricos, pontuação no nível de token e infraestrutura mais especializada.

Três Sinais Mostrarão se o Design Vai Além dos Benchmarks

O próximo teste é verificar se implantações independentes conseguem reproduzir os ganhos de qualidade sem armazenamento, latência ou complexidade operacional inaceitáveis.

O primeiro sinal é a avaliação independente dos pesos lançados. Pesquisadores e fornecedores de recuperação agora podem comparar ambos os modelos em tarefas públicas de documentos visuais e corpora privados do setor.

A reprodução deve abranger a configuração assimétrica, e não apenas testes simétricos de 0,6B e 9B. A alegação central depende de consultas com modelos pequenos manterem valor frente a um índice de modelo grande.

Se resultados independentes preservarem os ganhos reportados em documentos jurídicos, financeiros, técnicos e digitalizados, o design da Perplexity se tornará um padrão de implantação crível. Grandes quedas de qualidade enfraqueceriam o argumento do espaço compartilhado.

O segundo sinal é um relatório técnico completo com medições de índice. A Perplexity afirma que esse relatório chegará ainda este ano. Ele deve divulgar configurações de recuperação, compressão, hardware, latência e armazenamento por token de documento.

O relatório também deve explicar intervalos de confiança, filtragem de dados de treinamento e configuração dos benchmarks. Esses detalhes mostrarão se os ganhos de precisão reportados resistem a limites comparáveis de recursos.

O armazenamento é especialmente importante porque a dimensão de saída é apenas uma variável. Um vetor de token com 128 dimensões parece compacto diante de uma alternativa de 4.096 dimensões, mas o tamanho total do índice depende das contagens de tokens retidos.

O terceiro sinal é o suporte a produtos. A Perplexity afirma que adicionará progressivamente embeddings de interação tardia, densos e contextuais à sua plataforma de API. Um endpoint gerenciado revelaria como a empresa empacota as trocas entre indexação e serviço.

O suporte por API também ampliaria os testes para além das equipes capazes de operar infraestrutura de GPU personalizada. A adoção continuará mais restrita se os usuários precisarem montar por conta própria renderização, indexação, busca MaxSim e escalonamento.

A implementação deverá esclarecer se os clientes podem combinar índices de documentos de 9B com consultas de 0,6B por meio de um serviço gerenciado. Essa configuração é a ideia operacional mais forte do lançamento.

A precificação ainda não é uma comparação útil, e nenhum valor deve ser inferido a partir dos serviços anteriores de embeddings da Perplexity. O armazenamento e a pontuação multi-vetor diferem substancialmente dos embeddings de texto de vetor único.

As respostas dos concorrentes também importam, mas servem como evidência de apoio, e não como o principal teste. Qwen, Nvidia, Google, Mixedbread e outros provedores de recuperação podem melhorar a qualidade, reduzir dimensões ou oferecer sistemas gerenciados mais simples.

A vantagem da Perplexity não dependerá de um único retrato de um leaderboard. Ela dependerá de saber se o espaço compartilhado reduz os custos de consultas em produção, preservando qualidade de recuperação suficiente do indexador maior.

Para desenvolvedores, a ação imediata é uma avaliação delimitada. Monte um corpus representativo, renderize as páginas visualmente complexas e mantenha uma linha de base em texto. Em seguida, compare configurações simétricas e assimétricas sob o mesmo orçamento de recuperação.

Meça a precisão das respostas, o recall das páginas com evidências, o tamanho do índice, a taxa de processamento de ingestão, a latência de consulta e os casos de falha. Inclua pipelines de OCR e híbridos, pois a recuperação visual não elimina todos os motivos para analisar texto.

O Perplexity pplx-embed-v2-late apresenta uma hipótese clara: a codificação de documentos e a codificação de consultas não devem compartilhar o mesmo orçamento computacional. Os pesos abertos tornam essa hipótese testável.

A questão restante é operacional, não conceitual. Um índice de 9B e um caminho de consulta de 0,6B conseguem superar uma recuperação mais simples depois de contabilizados armazenamento, pontuação, atualizações, permissões e extração de evidências posteriores?