Контекстна пам'ять для 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

NLP розробка: чому accuracy не підходить для рідкісних класів?

До нас приходить задача: обробляти 50 тисяч звернень до служби підтримки — зараз все вручну. Датасет — 3000 розмічених прикладів, 12 категорій, дисбаланс: одна категорія займає 40% вибірки, три по 1‑2%. Baseline accuracy — 78%. Звучить непогано, поки не дивишся на recall по рідкісних класах: 0.31, 0.44, 0.28. Саме ці класи — скарги та загрози відтоку — найважливіші для бізнесу.

Це типовий проект NLP розробки. Проблема не в алгоритмі, а в тому, що accuracy — не та метрика. Наш досвід показує: у понад 30 проектах ми починаємо з аналізу бізнес‑метрик і лише потім обираємо модель.

Чому accuracy — не та метрика для рідкісних класів?

Accuracy ігнорує дисбаланс. Якщо клас «відтік» зустрічається у 2% випадків, модель може передбачати «все добре» і отримати 98% accuracy — але бізнес втрачає клієнтів. Рішення: F1 macro (усереднення за всіма класами) або weighted F1. Для NER — strict entity F1 (лише точні збіги). Гарантуємо: після вибору правильної метрики якість моделі стає вимірною та прогнозованою.

Класифікація тексту: від BERT до дистиляції

BERT-подібні моделі — стандарт для класифікації. ruBERT-base або ruBERT-large від DeepPavlov для російської мови. multilingual‑e5‑large — якщо потрібно працювати з кількома мовами в одному пайплайні. XLM‑RoBERTa‑large — сильний multilingual backbone.

Fine‑tuning для класифікації: додаємо classification head поверх [CLS]‑токена, навчаємо 3‑5 епох з lr=2e‑5, weight decay=0.01. При дисбалансі — weighted CrossEntropyLoss або focal loss з gamma=2.0. Пишіть — покажемо code snippet.

Кейс з дисбалансом. Датасет — 3000 прикладів, дисбаланс 1:20. Рішення: class_weight через sklearn + CrossEntropyLoss. Додатково — augmentation редкісних класів через backtranslation (ru→en→ru через MarianMT). Recall по рідкісних класах виріс з 0.31 до 0.67 при незначному падінні accuracy (76%→74%). Повна NLP розробка під ключ зайняла 3 тижні.

Дистиляція для production. BERT‑large дає F1 0.89, але inference на CPU — 180ms. Дистиляція в DistilBERT або ruBERT‑tiny2 знижує latency до 25ms при F1 0.84. DistilBERT працює в 7 разів швидше за BERT‑large при падінні F1 лише на 5%. Експорт в ONNX Runtime з int8 quantization дає додатковий 1.5‑2x. Оцінимо проект — розрахуємо економію на інфраструктурі.

Як вибрати модель класифікації під ваш датасет?

Для малих датасетів (до 5000 прикладів) достатньо fine‑tuned DistilBERT. Якщо потрібна багатомовність — XLM‑RoBERTa. При жорстких обмеженнях latency — дистильована модель з ONNX Runtime. Ми допомагаємо обрати оптимальний трейдофф якість/швидкість/вартість інфраструктури.

NER: розпізнавання іменованих сутностей

NER — вилучення персон, організацій, локацій, дат, сум, номерів документів. Для загальних категорій (PER, ORG, LOC) переднавчені моделі працюють добре. Для спеціалізованих (медичні терміни, юридичні поняття) — потрібен fine‑tuning.

Розмітка даних. Основна вартість NER‑проекту. Для якісної моделі — 500‑2000 розмічених речень на кожен тип сутності. Інструменти: Label Studio (open source) або Prodigy (від творців spaCy). Формат IOB2 — стандарт.

Архітектура. Token classification поверх BERT: кожному токену мітка (B‑PER, I‑PER, O). spaCy 3.x з transformer pipeline — зручний production‑вибір.

Вкладені сутності. Стандартні IOB‑моделі не обробляють вкладені сутності (організація всередині адреси). Для таких задач — span‑based NER: SpanBERT або SpERT. Складніше, але правильно.

Постобробка обов’язкова. Модель передбачає токени — потрібні нормалізовані сутності. Дата — dateparser. Суми — regex + валідація. Імена — дедуплікація через rapidfuzz. Входить у нашу стандартну поставку.

Sentiment Analysis та opinion mining

Бінарна класифікація positive/negative працює з BERT з коробки. Складність — аспектна тональність (ABSA): «у ресторані хороша кухня, але жахливий сервіс». Для ABSA: aspect extraction (NER) + sentiment за кожним аспектом. Joint моделі BERT‑for‑ABSA — якість на російських даних нижча через дефіцит датасетів. RuSentiment, SentiRuEval — основні ресурси.

Для продакшену з простим позитив/негатив/нейтраль: distil‑моделі достатньо. Три класи, balanced датасет, 2000+ прикладів — F1 macro 0.82‑0.87 за 1‑2 дні.

Сумарізація тексту

Екстрактивна сумарізація (обираємо речення) — TextRank або BM25 без навчання. Швидко, не галюцинує. Добре для довгих документів.

Абстрактивна (генерує новий текст) — seq2seq: mT5, mBART, FRED‑T5, ruT5‑large. Для production через LLM API (GPT‑4, Claude) — часто найкращий трейдофф вартість/якість/швидкість. Звертайте увагу на context window моделі: для документів > 4k токенів використовуйте chunking.

Ембеддинги: векторні представлення тексту

Ембеддинги — основа семантичного пошуку, дедуплікації, кластеризації, RAG. Якість критично впливає на downstream задачі.

Моделі. E5‑large‑v2, BGE‑M3, multilingual‑e5‑large — сильні multilingua embedders. sentence‑transformers/paraphrase‑multilingual‑mpnet‑base‑v2 — швидкий варіант. Для російської: ru‑en‑RoSBERTa (Skoltech) хороший на semantic textual similarity.

Як оцінити якість ембеддингів? MTEB benchmark — стандарт. Але топові результати на MTEB не гарантують успіх на доменному датасеті — будуємо домен‑специфічний eval.

Fine‑tuning ембеддингів. Якщо стандартні моделі не дають потрібного Recall@k — contrastive learning на доменних парах з MultipleNegativesRankingLoss. 500‑2000 пар, 1‑3 епохи — 5‑15% приріст Recall@k.

Розмірність та зберігання. E5‑large: 1024 dim, float32 — 4KB на вектор. При 10M документів — 40GB. INT8 quantization знижує до 10GB. FAISS IVF_PQ — ще компактніше, але з втратами. Входить у наші рекомендації по деплою.

Вилучення інформації

Структуроване вилучення — одна з частих задач. Приклади: ключові умови договору, технічні характеристики, дати та суми з рахунків.

1. Regex + rule-based. Для ІПН, ЄДРПОУ, сум, дат — надійніше нейромережі. Не потребує даних.
2. NER + постобробка. Для варіативних форматів.
3. LLM з structured output. GPT‑4 / Claude з JSON schema — для складних документів. Вартість: залежить від обсягу документів. Для 10k+ документів/день — рахуємо економіку.

Гарантуємо гібрид: regex/NER для типових полів + LLM для edge cases. Сертифікат довіри: 5 років на ринку, >30 проектів.

Етапи роботи

Прототип на існуючих даних — 1‑3 тижні. Production‑система з CI/CD — 1.5‑2.5 місяця. Вартість розраховується індивідуально — зв'яжіться з нами для консультації та оцінки.

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

• Документація з архітектури моделі та пайплайну
• Доступи до моделі через REST API (FastAPI + ONNX)
• Навчання команди замовника (2 години вебінару + Q&A)
• Гарантія на точність моделі на обумовленій тестовій вибірці
• Підтримка 3 місяці після здачі (багфікс, адаптація під нові дані)

Наш досвід

Понад 5 років у NLP, 30+ проектів від класифікації до RAG‑систем. Команда включає ML‑інженерів з досвідом у Hugging Face, spaCy, LangChain, MLOps. Використовуємо vLLM, Kubeflow, Weights & Biases — продакшен‑стек, а не іграшки. Замовте консультацію — оцінимо проект за 2 дні.