Ещё одна система памяти? Зачем?

Каждый второй проект на LLM упирается в одно: память. Контекстное окно модели сжирает всё, диалоги забываются, а RAG-системы разваливаются под нагрузкой. В 2026 году решений — десятки. LangChain, LlamaIndex, Mem0. Но почти все они — на Python.

Pali v0.1 — это попытка переломить ситуацию. Инфраструктура памяти, написанная на Go. Заявленные фичи: мультитенантность из коробки, гибридный поиск через qdrant и neo4j, встроенный MCP-сервер и детальные бенчмарки. Звучит как очередной over-engineering? Возможно. Но цифры из README заставляют присмотреться.

На момент 13 марта 2026 года Pali находится в ранней альфе (v0.1). Авторы честно предупреждают: API может ломаться. Но для продакшена это уже интересный кандидат.

Что внутри чёрного ящика

Архитектура Pali построена вокруг трёх столпов:

Qdrant 2.4+ — для векторного поиска. Последняя стабильная ветка на 2026 год, с поддержкой sparse векторов и квантования.
Neo4j 6.2+ — для графовых связей. Хранит отношения между сущностями, сессиями, пользователями. Именно это даёт мультитенантность.
Ollama 0.6+ — как локальный движок для эмбеддингов и, опционально, для инференса. Работает с моделями Llama 3.2, Command R+ и другими актуальными на 2026 год.

Всё это обёрнуто в Go-библиотеку с чистым API. Есть клиент для MCP (Model Context Protocol) — можно подключить к Claude Desktop или Cursor. И главное — в репозитории лежит полный бенчмарк с воспроизводимыми результатами. Не просто "быстро", а конкретные цифры: 1.2 мс на запрос при 10k вставках.

Go против Python: битва за перформанс

Сравнивать Pali пришлось с двумя категориями: тяжёлыми фреймворками (LangChain) и лёгкими библиотеками (llama-index).

Инструмент	Язык	Мультитенантность	Латентность (средняя)
Pali v0.1	Go	Да, из коробки	~1.5 мс
LangChain 0.3+	Python	Через костыли	~15 мс
llama-index 0.11+	Python	Нет	~5 мс

Цифры взяты из тестов Pali на идентичном железе (AMD Ryzen 9, 64 ГБ ОЗУ). Разница в 10 раз — не магия Go, а следствие отказа от динамической типизации и глобальной блокировки интерпретатора. Для высоконагруженных сервисов это критично. Хотя, если ваш RAG-агент работает раз в день, можно обойтись и Python.

💡

Мультитенантность в Pali реализована через изоляцию пространств имён в qdrant и отдельные субграфы в neo4j. Это значит, что данные одного клиента физически не пересекаются с данными другого. Для корпоративных развертываний — must-have.

Быстрый старт: от нуля до памяти за 5 минут

Теория — это хорошо, но как запустить? Допустим, у вас уже стоит Ollama с моделью nomic-embed-text (актуальный выбор для эмбеддингов в 2026).

1 Поднимаем инфраструктуру

Проще всего через docker-compose. В репозитории Pali лежит готовый файл, но вот его суть:

version: '3.8'
services:
  qdrant:
    image: qdrant/qdrant:latest
    ports:
      - "6333:6333"
  neo4j:
    image: neo4j:6.2-enterprise
    environment:
      - NEO4J_AUTH=neo4j/password
    ports:
      - "7474:7474"
      - "7687:7687"
  ollama:
    image: ollama/ollama:0.6
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama

Запускаем, ждём минуту. Базы готовы.

2 Инициализируем Pali

Установка библиотеки стандартна:

go get github.com/your-org/pali@v0.1.0

Базовый пример работы с памятью:

package main

import (
    "context"
    "fmt"
    "github.com/your-org/pali/core"
    "github.com/your-org/pali/adapters/qdrant"
    "github.com/your-org/pali/adapters/neo4j"
)

func main() {
    ctx := context.Background()
    
    // Создаём клиентов
    qdrantClient, _ := qdrant.NewClient("localhost:6333")
    neo4jClient, _ := neo4j.NewClient("bolt://localhost:7687", "neo4j", "password")
    
    // Инициализируем память с пространством имён "tenant-1"
    memory := core.NewMemory(qdrantClient, neo4jClient, "tenant-1")
    
    // Сохраняем факт
    memory.Store(ctx, "user123", "Мой кот сегодня съел паука.", nil)
    
    // Ищем по смыслу
    results, _ := memory.Search(ctx, "насекомые и домашние животные", 5)
    for _, r := range results {
        fmt.Printf("Сходство: %.2f | Текст: %s\n", r.Score, r.Text)
    }
}

Это основа. Дальше можно настраивать гибридный поиск (векторный + графовый), цепочки размышлений, приоритеты. Если вы когда-либо бились с ошибками при локальном запуске LLM, то оцените простоту API.

Кому и зачем это впихивать в проект

Pali — не для всех. Это инструмент с чёткой специализацией.

Команды на Go-стеке, которые устали тащить Python-зависимости ради одной библиотеки. Сборка в один бинарник — это красиво.
Стартапы, строящие multi-tenant SaaS с RAG. Изоляция данных и масштабируемость заложены с первого дня.
Инженеры, одержимые перформансом. Когда каждый миллисекунд на счету, а железо ограничено.
Исследователи, которым нужна воспроизводимость. Бенчмарки в репозитории — это редкая щедрость.

А вот если вам нужен быстрый прототип на коленке, или вы только знакомитесь с локальными LLM, Pali будет излишним. Там, где Python-экосистема предлагает тысячи готовых рецептов, Go-мир всё ещё строит фундамент.

Стоит ли изучать Go ради Pali? Если вы планируете серьёзный проект — да. В долгосрочной перспективе контроль над памятью и параллелизмом окупит время на обучение. Если нет — используйте проверенный Python, но не жалуйтесь на латентность.

Что будет дальше?

Pali v0.1 — только начало. Дорожная карта на 2026 год включает поддержку других векторных БД (например, Weaviate), кэширование эмбеддингов и агентские циклы. Сообщество пока маленькое, но активное.

Главный вопрос: сможет ли этот проект переманить разработчиков из уютного Python-мира? Шансы есть. Особенно когда облачный Qdrant и Neo4j Aura предлагают managed-решения, а Pali идеально ложится в такую инфраструктуру.

Мой прогноз: к концу 2026 года Pali займёт свою нишу — высокопроизводительные LLM-системы на Go. Не заменит Python-стек, но станет валидным выбором для тех, кто считает ресурсы. А там, глядишь, и сообщество начнёт писать плагины.

Подписаться на канал

Pali v0.1: как настроить инфраструктуру памяти для LLM на Go с qdrant, neo4j и ollama