Por alguma razão, os nós de armazenamento de vetores n8n sempre retornam vetores com 192 dimensões para o banco de dados de vetores.
Os modelos de incorporação que testei deveriam retornar vetores de 768 de acordo com suas fichas técnicas e o fazem se eu os chamar via terminal ou nó HTTP com alguma entrada de teste.
Portanto, o modelo e o LM-Studio como framework de hospedagem não parecem ser o problema.
Também verifiquei explicitamente com chroma e qdrant que eles permitem coleções de 768 se eu defini-las manualmente.
Pelo meu entendimento, parece haver um problema com os nós Vector Store ou com o nó da ferramenta de incorporação openai.
O problema é que você está usando o nó Embeddings OpenAI apontado para o LM-Studio. Esse nó foi construído em torno dos modelos de embedding do OpenAI e seus valores de dimensão específicos (256, 512, 1024, 1536, 3072), por isso 768 não está no dropdown. Em algum lugar no pipeline de processamento do nó, seus vetores de dimensão 768 estão sendo truncados para 192 (que é exatamente 768/4, então provavelmente não é aleatório).
Duas coisas para tentar:
Use o nó Embeddings Ollama em vez disso, se sua instância do LM-Studio expõe uma API compatível com Ollama, ou verifique se existe um nó comunitário do LM-Studio que lida adequadamente com dimensões de embedding não-OpenAI.
Como solução alternativa, tente definir a opção Dimensions explicitamente no nó Embeddings OpenAI. Mesmo que 768 não esteja no dropdown, mude o campo para o modo Expression e digite 768 manualmente. O dropdown é apenas uma conveniência da UI para os valores padrão do OpenAI, mas o parâmetro da API subjacente pode aceitar números arbitrários.
Se a solução alternativa de expression não funcionar, vale a pena abrir uma issue no GitHub. O nó Embeddings OpenAI é comumente usado com backends compatíveis com OpenAI (LM-Studio, Ollama, vLLM, etc.) e deveria passar qualquer dimensão que o modelo realmente retorna, em vez de forçar valores específicos do OpenAI.
Poderia testar a abordagem de expression e me informar?
Eu recomendaria abrir uma issue no GitHub para isso. O nó Embeddings OpenAI é amplamente utilizado com backends compatíveis com OpenAI (LM-Studio, vLLM, LocalAI, etc.) e deveria passar as dimensões nativas do modelo ou permitir valores arbitrários no campo Dimensions. Suas capturas de tela e resultados de teste formam um bom caso de reprodução.
Confirmado: o nó OpenAI Embeddings não é a opção certa aqui se não conseguir passar dimensões arbitrárias como 768.
Configurar o Ollama em paralelo é provavelmente o caminho mais limpo se você quiser manter-se dentro dos nós de AI/vector-store do n8n.
Uma alternativa a mais, se você quiser continuar com o LM Studio:
Em vez de usar o nó Embeddings OpenAI, chame o LM Studio diretamente com um nó HTTP Request, já que você já confirmou que ele retorna vetores de 768 dimensões. Depois, faça um dos dois:
envie os vetores para o Qdrant através da REST API do Qdrant usando nós HTTP Request, ou
use um nó Code para reformatar a resposta no formato esperado pelo próximo nó.
O requisito fundamental é:
Saída de embeddings do LM Studio: 768 dimensões
Tamanho de vetor da coleção Qdrant: 768
Nó do n8n passando o vetor completo sem alterações
Se algum nó no meio assumir dimensões OpenAI ou transformar o vetor, o Qdrant o rejeitará.
Além disso, ao testar, certifique-se de que a coleção Qdrant seja recriada após alterar o tamanho do vetor. O Qdrant não permitirá que uma coleção existente mude de 192 para 768 dimensões.
Portanto, sim, o nó Ollama é provavelmente a solução nativa do n8n mais fácil, mas a rota HTTP Request → LM Studio → REST do Qdrant também deve funcionar e evita completamente a limitação do nó OpenAI.
