Локальный агент с устойчивой памятью: стек Ollama + Qdrant + Postgres — 5 июля 2026 г. в 20:00:43.486
Локальный агент с устойчивой памятью: стек Ollama + Qdrant + Postgres Стандартные чат-интерфейсы локальных LLM страдают от амнезии: контекстное окно переполняется, модель начинает галлюцинировать или терять нить сложных многошаговых задач. Для продакшен-агентов (DevOps-боты, корпоративные ассистенты, парсеры) этого недостаточно. Нужна архитектура с разделением памяти: short-term (текущий контекст диалога) и long-term (векторное хранилище фактов + структурированная БД событий). В этом посте разбираем рабочий стек для самостоятельной сборки агента, который помнит историю, извлекает релевантные данные и не съедает всё GPU-память в первые же минуты работы. Основная проблема наивных реализаций RAG — потеря семантики при хранении и «загрязнение» промпта нерелевантными чанками. Мы используем гибридный подход: векторный поиск для смыслового соответствия + мета-фильтрация для точечного доступа (по дате, источнику, типу события). В качестве ядра берём Ollama для инференса, так как он даёт стабильную работу с квантованными моделями и удобный REST API. Для векторной базы — Qdrant, который отлично держит нагрузку и поддерживает сложное фильтрационное дерево без деградации скорости поиска. В качестве модели инференса рекомендуем использовать Qwen2.5-7B-Instruct или Hermes 3 — они показывают высокую точность в следовании инструкциям и работе с инструментами. Ключевой момент архитектуры — цикл обновления памяти. Агент не просто «читает» документы, он должен уметь записывать новые знания. После каждого шага инструмента (tool call) результат парсится: если это факт или ошибка, требующая запоминания, он преобразуется в embedding и сохраняется в коллекцию с метаданными. Важно настроить threshold для сохранения: не каждая фразы пользователя заслуживает места в векторной базе. Используйте embeddings модели nomic-embed-text — она бесплатная, локальная и даёт отличное качество сопоставления для технических текстов. При настройке Qdrant критично правильно подобрать метрику расстояния. Для большинства embedding-моделей оптимальна Cosine Similarity (расстояние = 1 - cosine). Настройте параметры HNSW индексации: m=16, ef_construction=100 обеспечивают баланс между скоростью поиска и качеством аппроксимации ближайших соседей. Не забываем про metadata indexing — включите фильтрацию по полям session_id, timestamp, doc_type. Это позволяет агенту искать не просто «похожие тексты», а именно «ошибки развертывания за последние 24 часа в проекте Alpha». Интеграция с LLM требует строгого контроля бюджета токенов. Вытянутые из памяти чанки нужно ре ранжировать (re-ranking) или отсекать по релевантности, прежде чем шить их в System Prompt. Используйте шаблонизатор, который динамически строит контекст: если retrieved docs превышают 40% от максимального окна, отсекайте наименее релевантные по score-оценке. Это предотвращает «потерю иголки в стоге сена», когда модель игнорирует критичную информацию из-за шума. Для стабильной работы агента внедрите механизм retry с экспоненциальной задержкой на уровне вызовов API Ollama. Локальные модели иногда могут выбрасывать 503 при перегрузке GPU. Также добавьте валидатор вывода: перед тем как агент передаст результат пользователю или следующему инструменту, прогоните ответ через легковесную модель-верификатор (например, то же Qwen2.5 с temperature=0), которая проверит синтаксис JSON или соответствие формату ответа. Это резко снижает количество «висящих» агентов из-за парсинговых ошибок. #AI #LLM #OpenSource #RAG