IA local no Obsidian: a arquitetura tem duas peças, e a maioria dos guias erra uma delas

Rodar inteligência artificial sobre um cofre do Obsidian sem que nada saia da máquina exige três instalações: o Ollama como servidor de inferência local, um plugin de busca semântica e um plugin de chat. O Ollama expõe um endpoint HTTP em http://localhost:11434, os plugins apontam para ele, e nenhuma nota trafega para servidor de terceiro. Custo por consulta: zero.

O erro mais comum não está em nenhuma dessas etapas. Está em tratar "o modelo" como uma coisa só.

São dois modelos, com trabalhos distintos

O modelo de embedding converte cada bloco de texto em um vetor, uma lista de números que representa o sentido do trecho. É o que permite encontrar uma nota sobre resiliência logística ao buscar por mitigação de risco em cadeia de suprimento, sem que as duas compartilhem uma única palavra. Ele roda uma vez sobre todo o cofre e depois só sobre o que muda.

O modelo de geração escreve a resposta. Ele recebe os trechos que a busca vetorial recuperou e produz o texto final.

São arquiteturas separadas, tamanhos separados e requisitos de hardware separados. Um embedding cabe em menos de 700 MB na maioria dos casos. Um modelo de geração utilizável começa em torno de 5 GB e vai a 16 GB ou mais. Quem instala só o segundo tem um chatbot que não conhece as próprias notas. Quem instala só o primeiro tem busca boa e nenhuma resposta.

O que cada plugin resolve

A combinação padrão é Smart Connections mais Copilot. O primeiro entrega o índice vetorial e o painel lateral de notas relacionadas, o segundo entrega a janela de chat que o primeiro não tem. O Copilot suporta Ollama de forma nativa, e a configuração de CORS necessária para a conexão local está documentada oficialmente, não é gambiarra.

O Local GPT tem valor específico: não existe caminho de nuvem no plugin. Para quem trabalha sob acordo de confidencialidade e não quer depender de uma configuração correta para garantir isolamento, a ausência da opção é a garantia.

Quais modelos puxar

Para embedding, a escolha depende de espaço e de idioma.

Para cofres em português, bge-m3 e qwen3-embedding tendem a se sair melhor que o nomic-embed-text, treinado com foco em inglês. Vale medir no próprio cofre antes de decidir, porque a diferença varia bastante conforme o vocabulário.

Para geração, a faixa de 7 a 8 bilhões de parâmetros é o piso prático. Modelos menores, na casa de 2 bilhões, falham com frequência em seguir instrução dentro de um pipeline de recuperação: ignoram o contexto injetado, respondem por conhecimento próprio, inventam citação de nota que não existe. Em 8 GB de VRAM, um modelo de 8B em quantização Q4_K_M ocupa cerca de 5 GB e deixa margem para o embedding rodar em paralelo.

Cuidado com listas de recomendação publicadas em blogs de SEO. A checagem feita para esta matéria encontrou guias de 2026 citando versões de modelo que não existem na biblioteca do Ollama, e recomendando tags diferentes para o mesmo caso de uso com meses de diferença. Confira o nome exato na biblioteca oficial antes de rodar o ollama pull.

O gargalo é o disco e a memória

O arquivo do modelo de geração vai de 4 a 16 GB. Esse é o primeiro limite real, antes de qualquer consideração sobre qualidade.

O segundo é a VRAM. Modelo que cabe inteiro na memória da GPU indexa e responde muito mais rápido que um que transborda para a RAM do sistema. Em Apple Silicon a memória é unificada e o problema muda de forma, mas não desaparece.

A indexação inicial é a operação mais pesada e acontece uma vez. Depois disso o custo é incremental: uma nota salva dispara a reembedagem apenas daquele arquivo, normalmente abaixo de um segundo.

O que ninguém mediu

Aqui está a lacuna que os tutoriais escondem.

Não existe benchmark público comparando a qualidade de recuperação entre Smart Connections, Copilot em modo Vault QA e as demais opções. As comparações disponíveis descrevem funcionalidades, não medem acerto. Escolher entre eles hoje é decisão por preferência de interface, não por evidência.

O tempo de indexação também não tem número confiável. Para um cofre de 10 mil notas em Apple Silicon, relatos publicados variam de cerca de 2,5 minutos a aproximadamente 25 minutos, uma diferença de uma ordem de grandeza. As metodologias não são descritas, o modelo de embedding usado nem sempre é informado e o tamanho médio das notas quase nunca aparece. Trate qualquer estimativa desse tipo como ordem de grandeza, não como previsão.

Quando a nuvem ainda ganha

Modelo local de 8B não escreve como modelo de fronteira. Para síntese longa, argumentação encadeada e reescrita de texto autoral, a diferença permanece visível.

O uso via API de fornecedor comercial custa, para carga moderada em um cofre pessoal, algo entre 3 e 10 dólares por mês. É pouco dinheiro por uma diferença de qualidade que ainda é grande.

O que se paga junto é a saída dos dados. Cofre de Obsidian costuma reunir pesquisa não publicada, negociação salarial, diário, estratégia de empresa e material sob sigilo. Uma configuração híbrida resolve boa parte do dilema: embedding sempre local, já que ele passa por cem por cento das notas, e geração na nuvem apenas nos casos em que a qualidade compensa, com o trecho enviado limitado ao que a busca recuperou.