Как перестать каждый раз объяснять свой контекст ИИ: слой персональной памяти для аналитиков

Я — Денис Шохирев, архитектор AI-решений в Freiburg (DennisCraft AI Studio, стек: Claude, Supabase, n8n, Doppler, self-hosted Postgres). За последние 6 месяцев я внедрил 14 production AI-агентов для DACH B2B — от логистики до финтеха. Каждый раз сталкиваюсь с одной и той же болью: аналитик вынужден по кругу разжёвывать свой доменный контекст ИИ, теряя время и точность.

Почему LLM не запоминает ваш рабочий контекст

Проблема не в “умности” модели, а в архитектуре пайплайна. LLM (Claude, GPT-4) умеет рассуждать, но не хранить длинную личную историю пользователя — максимум, несколько тысяч токенов в prompt. Каждый новый запрос начинается с “чистого листа”, если не реализовать слой памяти.

Типовые костыли: prompt templates и copy-paste

Вижу в командах две схемы:

• “Запихнуть всё в system prompt”. Но уже при 2–3 больших таблицах prompt size уходит за лимиты (у Claude 200К, у GPT-4 — 128К токенов).
• “Аналитик вручную копирует прошлые ответы”. Теряется вся автоматизация, растёт риск ошибок.

В результате LLM часто забывает детали проекта, терминологию, особенности схемы данных.

Паттерн: слой персональной памяти поверх LLM

Реальный production-подход — слой персональной памяти, который автоматически сохраняет, структурирует и подмешивает контекст пользователя в каждый новый запрос. Это не новый продукт, а архитектурный паттерн между клиентом и LLM API.

Техническая схема

Ключевые задачи и решения

• Автоматическое извлечение ключевых facts: парсинг прошлых диалогов, резюмирование, сохранение в structured memory (Postgres JSONB). Пример — пользователь вводит свой внутренний термин, агент ловит и сохраняет его определение для следующих сессий.
• Контекстная фильтрация: при каждом новом запросе, память фильтруется по релевантности (BM25, cosine similarity через встроенные Postgres расширения или Supabase Vector).
• Контроль “загрязнения” памяти: регулярная очистка старых или нерелевантных entries через n8n workflow — иначе prompt начинает “плыть”.

Пример: memory layer на Supabase + Claude

Реальный кейс: аналитик в логистике общается с AI-агентом, который строит запросы к внутренней базе. В первый раз агенту объясняют смысл “zone_group” и структуру shipment_id. Дальше memory layer автоматически подмешивает эти definitions во все последующие prompts.

import openai
import psycopg2
import json

def get_personal_context(user_id):
    conn = psycopg2.connect(database="contextdb", user="ai", password="****")
    cur = conn.cursor()
    cur.execute("SELECT facts FROM memory WHERE user_id=%s", (user_id,))
    rows = cur.fetchall()
    return [json.loads(row[0]) for row in rows]

def build_prompt(user_id, user_input):
    context = get_personal_context(user_id)
    prompt = "User context:\n"
    for fact in context:
        prompt += f"- {fact['term']}: {fact['definition']}\n"
    prompt += f"\nUser query: {user_input}"
    return prompt

def query_llm(prompt):
    response = openai.ChatCompletion.create(
        model="gpt-4",
        messages=[{"role": "system", "content": prompt}]
    )
    return response.choices[0].message.content

Этот паттерн работает и для Anthropic Claude через API, меняется только endpoint.

Ошибки и нюансы production-внедрения

• “Память” забивается мусором: если не фильтровать по релевантности, prompt быстро раздуется и начнутся ошибки “context window overflow”. Используйте vector search или хотя бы ключевые слова.
• Data privacy: персональные facts часто содержат чувствительные данные. Обязательно шифруйте at rest (Postgres + pgcrypto), используйте Supabase Row-Level Security.
• Версионирование: если definitions меняются, храните историю изменений через array of JSON или отдельную таблицу revisions.

На одном из внедрений (финтех, DE), без версионирования definitions LLM начал путать старые и новые значения “risk_tier”, что привело к ошибкам в отчетах. После ввода ревизий — ошибка ушла.

FAQ

Можно ли всё делать через RAG?

RAG (retrieval-augmented generation) хорош для справочников и документов, но персональную память лучше хранить отдельно — иначе она затеряется среди общей базы знаний.

Какой формат памяти выбирать: plain text или структура?

В production лучше structured memory (JSONB), чтобы быстро фильтровать и версионировать facts. Plain text подходит только для MVP.

Как автоматизировать очистку памяти?

n8n отлично справляется: по cron чистит неиспользуемые или устаревшие facts, можно настраивать по активности пользователя.

Можно ли memory layer использовать для команд, не только одного пользователя?

Да, просто добавьте поле group_id и фильтрацию по нему. Тогда контекст можно делить между членами команды.

Есть ли лимиты на размер памяти в Supabase/Postgres?

Технически — десятки мегабайт на запись, но по опыту, более 100 facts на пользователя мешают LLM фокусироваться. Лучше хранить только самое важное.

В вашей практике — на каком этапе LLM чаще всего теряет критический контекст: при смене проекта, при смене терминологии или при длинных сессиях? Мне реально интересно. Я делаю бесплатный 30-мин аудит AI-стека для DACH-компаний в регулируемых отраслях. Пишите в LinkedIn или @ger_dennis_ai.