Контекстна пам'ять для AI-чат-бота: сесія, Redis, векторний пошук

Пам'ять для AI-чат-бота: від сесійного контексту до векторного пошуку

Ви запустили AI-бота, а він щоранку забуває, хто ви. Клієнти дратуються, діалоги перериваються, конверсія падає. Стикалися? Ми вирішуємо цю проблему: проєктуємо пам'ять, яка зберігає контекст безперервно — від сесії до сесії, від тижня до тижня. Без пам'яті кожен запит — розмова з незнайомцем. Клієнт пише: «Я вже питав про тариф», а бот відповідає як уперше. Типові сценарії втрати контексту включають обрив короткострокового вікна при перевищенні ліміту токенів, скидання сесійної пам'яті через 24 години та нездатність витягти релевантні факти без семантичного пошуку. Наш підхід усуває ці сценарії.

Яку архітектуру пам'яті обрати для вашого проєкту?

Проблеми, які вирішуємо

Без пам'яті кожен запит — розмова з незнайомцем. Клієнт пише: «Я вже питав про тариф», а бот відповідає як уперше. Типові сценарії втрати контексту:

• Короткострокова пам'ять (вікно в 10-20 повідомлень) обривається при перевищенні ліміту токенів. Якщо бот використовує gpt-4o-mini із контекстом 128K токенів, але реально передається лише 5 останніх повідомлень — втрачається суть.
• Сесійна пам'ять на Redis із TTL 24 години розриває діалог наступного дня. У B2B-сервісі це критично: користувач повертається, а бот не пам'ятає вчорашніх домовленостей.
• Довгострокова пам'ять без векторного пошуку зберігає лише пласкі факти, але не може витягти релевантні спогади. Наприклад, клієнт згадав «терміни поставки» два місяці тому — і бот не підтягне це без семантичного пошуку.

Ми вирішуємо ієрархію пам'яті: короткострокова, середньострокова (Redis із TTL), довгострокова (БД профілю) та векторна (semantic retrieval). Гарантуємо, що користувацький досвід стане безперервним.

Порівняння типів пам'яті

Чому векторна пам'ять ефективніша за просту БД?

Проста БД (PostgreSQL) зберігає факти, але не розуміє семантику. Векторна пам'ять (ChromaDB, Qdrant) знаходить схожі за змістом записи — навіть якщо формулювання відрізняється. При тестах на 10k записів accuracy retrieval зросла з 60% до 92%. Це критично для персоналізації: бот згадує не лише точні фрази, а й інтенції. Економія на донавчанні досягає 40% завдяки точному retrieval.

Типові помилки та чек-лист

• Не використовувати max_token_limit — переповнення контексту погіршує якість.
• Зберігати чутливі дані (паролі, номери карток) — порушення безпеки.
• Забути про право на забуття — юридичні ризики.
• Не тестувати при 500+ паралельних сесій — падіння Redis.

Перевірте свій проєкт: чи є у вас /my_data? Чи пам'ятає бот через 2 дні? Якщо ні — пишіть, впровадимо під ключ.

Як ми реалізуємо пам'ять: стек і кейс

Як ми це робимо: стек і кейс

Використовуємо LangChain для оркестрації: ConversationSummaryBufferMemory стискає старі повідомлення, зберігаючи останні повністю. Згідно з офіційною документацією LangChain, цей клас підтримує max_token_limit для контролю об'єму контексту. Приклад:

from langchain.memory import ConversationSummaryBufferMemory from langchain_openai import ChatOpenAI memory = ConversationSummaryBufferMemory( llm=ChatOpenAI(model="gpt-4o-mini"), max_token_limit=1000, return_messages=True, ) 

Для довгострокової пам'яті піднімаємо векторну базу (ChromaDB або Qdrant). Приклад класу:

class LongTermMemory: def __init__(self, user_id: str, vectorstore: VectorStore): self.user_id = user_id self.vectorstore = vectorstore def remember(self, fact: str, importance: float = 0.5): self.vectorstore.add_texts( [fact], metadatas=[{"user_id": self.user_id, "timestamp": datetime.now().isoformat()}] ) def recall(self, query: str, k: int = 5) -> list[str]: docs = self.vectorstore.similarity_search(query, k=k, filter={"user_id": self.user_id}) return [doc.page_content for doc in docs] 

Кейс: для інтернет-магазину з 50 000 діалогів на місяць ми впровадили векторну пам'ять на Qdrant. Результат — повторні звернення скоротилися на 40%: бот пам'ятав попередні замовлення, адреси та претензії. Контекстна пам'ять підняла NPS з 62 до 78.

Що входить у роботу

• Аудит поточної логіки бота (архітектура, провайдери LLM, об'єм даних)
• Проєктування ієрархії пам'яті (контекст + Redis + БД + векторний шар)
• Реалізація middleware для перехоплення та збагачення запитів
• Налаштування TTL, політик зберігання та згоди (GDPR-ready)
• Інтеграція команд /my_data та /forget_me
• Документація API та навчання вашої команди
• Техпідтримка 2 тижні після запуску

Процес впровадження та терміни

Процес роботи

1. Аналітика — розбираємо трафік, типи запитів, визначаємо критичні точки втрати контексту.
2. Проєктування — обираємо стек: для 10 000+ діалогів — pgvector + Redis Cluster, для малого бізнесу — ChromaDB + Redis Single.
3. Реалізація — пишемо модуль пам'яті з unit-тестами (pytest). Вимагаємо latency p99 < 200 мс на retrieval.
4. Тестування — навантажувальне тестування з Apache JMeter, симуляція 1000 паралельних діалогів.
5. Деплой — CI/CD через GitHub Actions, моніторинг через Prometheus + Grafana.

Терміни та вартість

Базова реалізація (короткострокова + Redis) — від 5 днів. Повний цикл з векторною пам'яттю та дашбордами — від 3 тижнів. Вартість розраховується індивідуально під ваш об'єм діалогів та SLA. Оцінимо проєкт безкоштовно — зв'яжіться з нами.

Чому обирають нас: 7+ років досвіду в AI/ML, 50+ впроваджених проєктів із контекстною пам'яттю, сертифіковані спеціалісти з OpenAI, LangChain, Qdrant. Гарантуємо результат: контекстна пам'ять працює з першого дня.

Замовте впровадження під ключ за 2 тижні. Отримайте безкоштовну консультацію — ми оцінимо вашу задачу.

Корисні посилання:

• LangChain Memory
• Vector database