ScyllaDB как backend для LangChain решает ключевую проблему: сохранение контекста диалога в RAG-системах и масштабирование без потери состояния.
Проблема проявляется не сразу — до момента, когда RAG-чатбот выходит за пределы одного процесса. LLM по своей природе stateless: каждый запрос начинается с пустого контекста, если история не воспроизводится вручную. В LangChain это частично скрыто за BaseChatMessageHistory, но стандартная in-memory реализация исчезает при перезапуске. Как только появляются рестарты, горизонтальное масштабирование или несколько реплик, система теряет консистентность диалога. В результате ответы становятся фрагментированными, а поведение — непредсказуемым.
RAG сам по себе не закрывает этот разрыв. Он добавляет внешний контекст через retrieval, но не хранит пользовательские интеракции. Это две разные оси: знания (documents) и состояние (conversation state). Без устойчивого слоя хранения история диалога не переживает сбои и не разделяется между инстансами. Для production-сценариев это ограничение становится критическим.
Решение строится вокруг замены ephemeral-памяти на устойчивое хранилище. В данном случае выбран ScyllaDB — NoSQL база, оптимизированная под высокий throughput и предсказуемую низкую задержку (low latency). Ключевой компромисс здесь — отказ от простоты in-memory в пользу сетевого хранилища. Это добавляет сетевую зависимость и требует схемы данных, но взамен дает устойчивость к сбоям, масштабирование и возможность аудита диалогов. В индустрии такой сдвиг считается прагматичным: состояние выносится в инфраструктурный слой.
Интеграция опирается на существующий Cassandra-коннектор, который ScyllaDB может переиспользовать. Через cassio.init() регистрируется сессия и keyspace, после чего все компоненты LangChain используют одно подключение без дополнительной конфигурации. Важно, что cassio не привязан к конкретной СУБД: он работает с любой совместимой сессией, включая scylla-driver. Это снижает стоимость интеграции и убирает необходимость писать кастомный адаптер.
Архитектура делится на два потока: векторное хранилище и история сообщений. Для RAG используется таблица rag_docs с колонкой vector<float, 384>, соответствующей эмбеддингам модели all-MiniLM-L6-v2. Индексация реализована через HNSW, что позволяет выполнять поиск ближайших соседей при запросе. Документы загружаются через WebBaseLoader, затем режутся на чанки по 500 токенов с overlap в 50 токенов. Это снижает риск потери семантики на границах.
Второй поток — chat history. CassandraChatMessageHistory сохраняет каждое сообщение как строку с ключом session_id. Это простая, но эффективная модель: один session_id — одна логическая сессия. Все реплики, работающие с тем же ключом, видят одинаковую историю. Смена session_id создает новую сессию без дополнительной логики. Таким образом, механизм изоляции и восстановления состояния сводится к управлению ключом.
RunnableWithMessageHistory замыкает цикл. Перед каждым вызовом он подтягивает историю из ScyllaDB, а после — записывает новый turn обратно. Обе операции идут через базу, что делает поведение системы детерминированным относительно состояния. Даже при сбоях или перезапусках цепочка продолжает с того же места.
Отдельный аспект — стоимость вычислений. Эмбеддинги считаются один раз при первичной загрузке данных. Повторные запуски используют уже созданную таблицу, если не вызывается повторная индексация. Это снижает нагрузку и делает систему более предсказуемой по ресурсам.
Результат — устойчивый RAG-чатбот, который сохраняет контекст между вызовами и масштабируется горизонтально. Метрики производительности в исходном материале не приведены, но архитектурно система устраняет ключевые точки отказа: потерю состояния при рестартах и расхождение контекста между репликами. Дополнительно появляется возможность аудита диалогов, что важно для production и compliance.
Такой подход можно рассматривать как эволюционное улучшение LangChain-экосистемы. Он не меняет саму модель взаимодействия с LLM, но стабилизирует ее поведение в реальных условиях. В системах, где диалог — это не одноразовый запрос, а длинная сессия, перенос памяти в ScyllaDB становится не оптимизацией, а необходимостью.