Análise Pós-Morte: Construindo um Servidor MCP Local para Memória de Código com Ollama e ChromaDB

Os desenvolvedores estão se opondo à cobrança de API na nuvem e aos riscos de privacidade de enviar bases de código proprietárias para endpoints de terceiros. Um tópico no Hacker News deste ano deixou isso claro: o problema não é o preço por token, mas a imprevisibilidade da cobrança baseada em uso quando agentes de IA estão continuamente consultando APIs. No Reddit, a preocupação com a privacidade é ainda mais evidente -- para trabalho empresarial e de defesa, enviar propriedade intelectual da empresa para OpenAI ou Anthropic é um não absoluto, independentemente do custo.

zerikai_memory tem um modo local exatamente para isso: tudo roda através do Ollama, nada sai da sua máquina. Nós enviamos mistral:7b como o modelo local padrão. ornith:9b foi lançado em junho de 2026, treinado especificamente para tarefas de codificação agentivas, então testamos ambos. Aqui está o que encontramos.

Como o zerikai_memory Usa um Modelo Local

zerikai_memory opera em três modos: cloud (DeepSeek), local (Ollama) e hybrid. O roteamento entre eles é gerenciado pela função _should_use_cloud() em main.py:986, uma cadeia de prioridade de 4 etapas: substituição explícita, correspondência de palavras-chave, limite de contagem de palavras e, por fim, fallback da variável de ambiente MEMORY_MODE. No modo local, essa função sempre retorna falso -- tudo permanece no dispositivo.

No modo local, cada chamada de síntese atinge _query_ollama em main.py:1555. O modelo recebe um resumo do projeto de _load_project_context mais cargas úteis estruturadas de entidades ChromaDB: assinaturas de funções, caminhos de arquivos, intervalos de linhas, docstrings. Ele retorna uma resposta com citações inline #file:line. Uma chamada, sem streaming, sem loop de ferramentas.

A camada de recuperação (ChromaDB + distância L2 + reclassificação lexical) é agnóstica ao modelo. Ambos os modelos receberam contexto idêntico em cada teste de consulta. A única variável era a síntese.

Hardware

• GPU: NVIDIA RTX 3050, 8GB GDDR6 de VRAM dedicada
• CPU: Intel i7-12700
• RAM: 32GB
• OS: Windows 11

8GB de VRAM dedicada é o teto rígido. O Windows oferece memória de sistema compartilhada como transbordo, mas a inferência em RAM compartilhada através do PCIe é lenta o suficiente para ser relevante na prática.

Modelos

mistral:7b (v0.3) -- 4.4GB, 32K de contexto. Chamadas de função via modo bruto do Ollama apenas: você constrói prompts [AVAILABLE_TOOLS] manualmente e analisa as respostas [TOOL_CALLS] você mesmo. Última atualização em maio de 2024.

ornith:9b-dense -- aproximadamente 5.5GB estimados, construído sobre Gemma 4 e Qwen 3.5. Treinado por RL para tarefas de codificação agentivas com chamadas de ferramentas nativas. 69.4 no SWE-Bench Verified, 43.1 no Terminal-Bench 2.1, igualando ou superando modelos com 3x sua contagem de parâmetros.

Teste 1: Script de Benchmark (Latência)

Um script Python autônomo atingiu o Ollama diretamente com amostras de carga útil ChromaDB estáticas construídas a partir de entidades reais do zerikai_memory. 3 consultas, 3 amostras cada por modelo, latência bruta medida na camada HTTP. Este teste mede a velocidade de inferência no hardware, não a qualidade da síntese em relação a uma base de código ao vivo.

A inicialização a frio do ornith na primeira consulta atingiu 25.67s. Ele transbordou para a memória compartilhada antes que o Ollama fixasse o modelo. Amostras aquecidas se estabilizaram em 9-17s. O mistral se encaixa perfeitamente em 8GB e roda a 3-7s quando aquecido.

O script de benchmark está no repositório (no diretório blog/). Execute-o em seu próprio hardware antes de se comprometer com uma troca de modelo.

Teste 2: Consultas MCP Ao Vivo (Qualidade da Síntese)

Ambos os modelos foram testados ao vivo através da camada MCP zerikai_memory universal-brain contra o índice real do zerikai_memory. As mesmas 5 consultas, modelos trocados manualmente entre execuções, Ollama reiniciado entre cada troca. Este teste mede o que um desenvolvedor realmente experimenta no Cursor ou VS Code -- não cargas sintéticas, recuperação real do ChromaDB.

Mesma consulta, mesmo contexto ChromaDB, mesmo prompt do sistema. Aqui está o que voltou.

Consulta 1: Como o roteamento de consultas decide entre Ollama e DeepSeek?

ornith:9b:

Com base na memória de código recuperada, aqui está como o roteamento de consultas funciona:

Lógica de Roteamento:

1. Substituição Explícita: A função `_should_use_cloud` primeiro verifica um parâmetro explícito `use_cloud` que pode forçar o modo nuvem (DeepSeek) independentemente de outras condições #main.py:986-1005.

2. Detecção de Palavras-chave: Se a consulta do usuário contiver palavras-chave como "arquitetura", "explicar", "como faz" ou "visão geral", ela é roteada para o modo nuvem do DeepSeek #config.py:43-44.

3. Limite de Contagem de Palavras: Consultas que excedem 40 palavras são automaticamente roteadas para nuvem/DeepSeek via verificação de contagem de palavras de `_should_use_cloud` #main.py:992-994, com esse limite definido na configuração como `CLOUD_ESCALATION_WORD_COUNT = 40` #config.py:37.

4. Modo Padrão: Retorna ao que está definido como `DEFAULT_MEMORY_MODE`, que por padrão é "hybrid" a menos que explicitamente alterado pela variável de ambiente `MEMORY_MODE` #config.py:31-32, com essa função retornando com base em se esse modo é igual a "cloud" #main.py:996-998.

Nota Importante: O contexto recuperado não contém informações explícitas sobre o papel do Ollama na decisão de roteamento ou como as consultas do modelo local são construídas quando o modo nuvem NÃO é selecionado.

mistral:7b:

O roteamento de consultas no zerikai_memory decide entre usar Ollama ou DeepSeek com base em uma cadeia de prioridade de 4 etapas. As prioridades são as seguintes:

1. Substituição explícita use_cloud.
2. Correspondência de palavras-chave CLOUD_ESCALATION_KEYWORDS.
3. Limite de comprimento CLOUD_ESCALATION_WORD_COUNT.
4. Fallback DEFAULT_MEMORY_MODE (recomendado).

Esse processo de tomada de decisão visa equilibrar privacidade, velocidade e custos de API, ao mesmo tempo em que fornece o máximo de nuance de contexto para o usuário. Para mais informações detalhadas sobre modos, configurações e uso, você pode consultar o arquivo README.md no repositório do projeto.

Fontes: main.py:986, README.md:320, main.py:1495, main.py:1311, README.md:105

Consulta 2: Onde o caminho do diretório .brain é definido e como é resolvido entre sistemas operacionais?

ornith:9b:

O caminho do diretório `.brain` é definido e resolvido através de dois locais principais:

Definição: Em `config.py`, linha 1-2, há uma constante que define o nome base para o diretório brain [config.py:1]:

    DB_PATH = '.brain/'
    BRAIN_DIR = Path(DB_PATH)

Resolução: Em `main.py`, linhas 120-145, dentro da função `init_workspace`, esse caminho é resolvido juntando-o com o caminho absoluto do workspace [main.py:130]:

    path = Path(workspace_path).resolve()
    db_path = path / DB_PATH
    db_path.mkdir(parents=True, exist_ok=True)

O processo de resolução:
1. Toma o parâmetro `workspace_path` fornecido
2. Resolve para um caminho absoluto usando `.resolve()`
3. Junta com o `.brain/`