Как хранить схемы диалогов для чат-бота?

Question

[prochanev]

Добрый день!
Подскажите, пожалуйста, как и в какой бд (РСУБД или NoSQL) хранить схемы для множества чат-ботов. Под схемой я подразумеваю граф диалога, взаимосвязи между опциями и следующими/предыдущими сообщениями. Ну т.е. заранее сконструировали диалог для бота и запустили, таких ботов/диалогов может быть много.

В первом приближении, я подумал, что нормальным вариантом будет поле типа JSON в Postgreql с примерно таким содержимым:

{
   1:{
      "answer1":{
         "text":"blah blah",
         "photo":"picture.jpg",
         "to":2
      },
      "answer1":{
         "text":"blah blah",
         "photo":"picture.jpg",
         "to":3
      },
      "answer1":{
         "text":"blah blah",
         "photo":"picture.jpg",
         "to":4
      }
   },
   2:{
      "answer1":{
         "text":"blah blah",
         "photo":"picture.jpg",
         "to":5
      }
   }
}

А таблица с ботом примерно такая

bot_id | description | token_hash | schema(вот про это поле я и говорю)

Т.е. много разных ботов с разными диалогами.

Но напрягает, что при взаимодействии с таким ботом придется раскручивать всю эту структуру, как будто контроль теряется. + я не уверен, как ORM работает с полем JSON.

Подскажите, пожалуйста, кукую бд и схему хранения данных лучше выбрать?
Приму любые мысли, критику, да что угодно :)

Answer 1

[Сергей П]

Нормально ORM работает с JSON, но не понятно зачем вам именно реляционная БД, если вы фактически отказались от нормализации и джойнов.
Для вашего этого варианта подойдёт и NoSQL.

таких ботов/диалогов может быть много.

Много - это понятие растяжимое. Вы уже столкнулись с каким-то бутылочным горлышком и хотите уже что-то оптимизировать? Если нет, то делайте как проще и понятнее в рамках функциональных требовний.

Отрефакторить преждевременно оптимизированное решение будет гораздо сложнее, чем простое.
Практика показывает, что в ходе реализации MVP часто вылезают новые требования, которые заставят вас усложнять модель. Простое мнималистичное решение позволит более гибко добавлять функциональность и не потерять бестолку время на написание сложного кода. который всё ранво переписывать.

В вашем случае можно сделать всё на ORM и реляционной базе. Включая отдельные модели для вариантов ответов и прочего.
Можно отказаться от ORM и размещать одного бота в одном документе. Тогда можно использовать монгу и десериализацию документа в собственную структуру классов. Тут писать получится больше, но и гибкость будет выше, можно будет пользовтаельские плагины какие-то прикручивать... вопрос - надо ли это и понадобится ли в будущем?

Фактически диалог - это конечный автомат. Его можно представить в виде графа. Человечество уже давно придумало много способов сохранять и оперировать графом в любой БД, в том числе реляционной.

Comments

[prochanev]

Я немного подумал над этим, действительно древовидная структура достаточно гибкая для редактирования.
Например каждый узел - это пункт диалога со своими свойствами. Выглядит неплохо.
В монгу не очень хотелось залезать т.к. для остальных данных приложения хотелось бы иметь реляционную схему. Есть над чем подумать.

Насчет "Много ботов", конечно я имел ввиду n > 1. Пока не сталкивался с бутылочным горлышком, я на этапе проектирования.

Спасибо, что потратили свое время и написали такой подробный ответ!

[Сергей П]

prochanev, Только вот диалог в общем случае - это не дерево. а, всё же, граф. В дереве не бывает циклов, а в диалогах иногда полезно перепрыгнуть в какое-то конкретное состояние прямым переходом.
Это значит, что, скорее всего, у вас будут следующие сущности:

Бот(токен, название, ...)
УзелДиалога(
    бот, 
    название, 
    обработчик_входа, 
    обработчик_выхода, 
    признак_стартового, 
    признак_терминального, 
    дефолт_контекста, 
    оверрайд_контекста_при_входе,
)
Переход(
    исходный_узел, 
    условия_перехода, 
    целевой_узел, 
    сообщение, 
    [кнопки], 
    оверрайд_контекста,
)
Состояние(чат, бот, текущий_узел, текущий_контекст)

К этому всему можно прикрутить ещё суб-диалоги. Тогда у узла появится флаг, который делает узел субдиалогом и появится необязательная ссылка на родительский субдиалог. У такого субдиалога обязательно должен быть только один вход и два выхода: штатный и аварийный. Хотя в общем случае выходов может быть и больше, просто труднее будет за ними следить. Также можно сделать стек состояний для рекуррентных субдиалогов. Это усложнение тоже за пределами MVP и потребует аккурантности воизбежание бесконечной рекурсии.

Ещё можно предусмотреть переходы с автономными условиями, то есть условиями. не требующими реакции пользователя. Тогда в диалогах могут быть формальные узлы и переходы, которые не показывают пользователю сообщений и кнопок, но меняют его состояние в соответствии с внутренними или внешними факторами: временем суток, рандомом (для вариативных синонимичных ответов, для игр), текущего контекста пользователя.

Такую же схему можно предусмотреть для навыков голосовых помощников, для диалоговых меню в телефонии, для системы квестов в играх.
В частности похожая струткура использовалась мной в одной ММОРПГ, которая почила уже в бозе.
Только там это хранилось не в реляционной базе, а в специальном реестре, реализованном поверх Монги.

UPD:
Кстати! Забыл уомянуть. Рассмотрите вариант хранения диалогового графа в yaml-файлах. Это очень удобно, поскольку граф можно будет мнемонично хранить в системе контроля версий, отслежиать изменения, версионировать. Отдельные ветки диалогов (Узлы и Переходы) можно хранить в отдельных файлах, названия узлов должны быть уникальны в пределах файла, ссылки на узлы по пути к файлу и имени узла. Переходы можно описывать прямо внутри узла, там же или в отдельных файлах можно размещать функции-обработчики состояний и переходов. Именно так были реализоаны квесты у нас в ММОРПГ и эти квесты можно было достаточно прозрачно и быстро править и создавать новые.
Так диалог (или субдиалог) у вас будет обычным каталогом или файлом по аналогии с питоновским пакетом или модулем. Внутри помимо yaml-файлов описания графа можно размещать картинки, разный статический медиаконтент бота и текстовые файлы с фрагментами сообщений на разных языках или шаблонами ообщений под Jinja.
При такой организации большие куски графов диалогов вполне можно публиковать как подключаемые библиотеки.
Например, универсальный диалоговый модуль продажи билетов можно подключить к готовому боту концертной площадки. При необходимости какие-то Узлы можно перекрыть сверху своими модифицированными.

Answer 2

[alternativshik]

Мы в Монге хранили весь JSON со сценарием диалога. Сначала начинали на Постргресе делать, но потом это оказалось дольше и не так удобно на этапе MVP, потому засунули в монгу + фронт для создания этого сценария создавал весь этот JSON, который можно было просто и быстро провалидировать и дальше пользоваться.

Comments

[prochanev]

Спасибо, что поделились опытом, примерно такой ответ и хотелось, именно опыт того, кто уже делал.

В монге хранили только структуру диалогов, а остальные данные в РСУБД? Или все - все на монге? Как написал в комментарии ниже все таки хотелось бы для некоторых данных иметь схему.