🐉 Правила чата WeaveAI
Мы строим AI-движок для настольных игр на глазах у публики. Этот чат — место для фидбека, обмена идеями и отлова багов.
Всё просто:
* Без токсичности и перехода на личности. Уважаем чужой труд и мнение.
* Без спама, рекламы и непрошеного оффтопа, за нарушение — автобан.
* Для багов и логов используйте тег
Спасибо, что вы с нами!
Мы строим AI-движок для настольных игр на глазах у публики. Этот чат — место для фидбека, обмена идеями и отлова багов.
Всё просто:
* Без токсичности и перехода на личности. Уважаем чужой труд и мнение.
* Без спама, рекламы и непрошеного оффтопа, за нарушение — автобан.
* Для багов и логов используйте тег
#bug или пишите в ветку к соответствующему посту разработки.Спасибо, что вы с нами!
Всем привет! 👋 Меня зовут Евгений, и я строю WeaveAI — ИИ-движок для TTRPG (ДНД), работающий в Телеграме.
Для кого этот проект? Для занятых людей, любящих ДНД и желающих погонять с ИИ-мастером 15-20 минут в свободное время. Это не замена живой игры, но достойное соло-приключение, когда нет возможности здесь и сейчас собрать пачку и засесть на 4 часа. А ещё, поскольку это движок, а не заскриптованная игра, в будущем я хочу сделать маркетплейс для авторов приключений — ведь для игроков нужны будут сценарии! Так что мастера — велкам!
Фишки. 1) Память и правила, которые обеспечиваются кодом и базой данных. 2) Заданный лишь текстом креативный мир и интересные "живые" запросы игроков, которые может "переварить" ИИ.
Стек: N8N cloud, комбинирую несколько llm, код на JS, n8n data tables в качестве базы, UI — Telegram, помогает Cursor.
На текущий момент проекту 4+ месяца. Эволюция такая: Chat-bog -> PoC -> multi-agent solution -> alpha test.
По результатам альфы выяснилось, что главный враг - модель-рассказчик Narrator, который жёстко галлюцинирует. На его совести больше 50% багов и 90% обломанного кайфа. Вторая большая проблема - бинарный режим "мир или бой", который не позволяет решать загадку или заговорить зубы врагу прямо во время боя - а это именно то, чего нет у конкурентов. Идея - пайплайн с параллельным запуском узконаправленных "агентов-специлистов" и финальной сборкой результата в конце. Тут есть ряд рисков, так что может не взлететь, но посмотрим.
Ближайший план - отучить Нарратора галлюцинировать, запилить новый пайплайн, добить eval тесты для нормального замера времени ответа моделей и потребления токенов (юнит-экономику никто не отменял), добавить пару механик - и запустить вторую альфу. Если качество будет хорошим, а длительность и стоимость хода приемлемыми, буду двигаться дальше этим путём. Если нет - буду искать другой путь.
Как-то так :)
Для кого этот проект? Для занятых людей, любящих ДНД и желающих погонять с ИИ-мастером 15-20 минут в свободное время. Это не замена живой игры, но достойное соло-приключение, когда нет возможности здесь и сейчас собрать пачку и засесть на 4 часа. А ещё, поскольку это движок, а не заскриптованная игра, в будущем я хочу сделать маркетплейс для авторов приключений — ведь для игроков нужны будут сценарии! Так что мастера — велкам!
Фишки. 1) Память и правила, которые обеспечиваются кодом и базой данных. 2) Заданный лишь текстом креативный мир и интересные "живые" запросы игроков, которые может "переварить" ИИ.
Стек: N8N cloud, комбинирую несколько llm, код на JS, n8n data tables в качестве базы, UI — Telegram, помогает Cursor.
На текущий момент проекту 4+ месяца. Эволюция такая: Chat-bog -> PoC -> multi-agent solution -> alpha test.
По результатам альфы выяснилось, что главный враг - модель-рассказчик Narrator, который жёстко галлюцинирует. На его совести больше 50% багов и 90% обломанного кайфа. Вторая большая проблема - бинарный режим "мир или бой", который не позволяет решать загадку или заговорить зубы врагу прямо во время боя - а это именно то, чего нет у конкурентов. Идея - пайплайн с параллельным запуском узконаправленных "агентов-специлистов" и финальной сборкой результата в конце. Тут есть ряд рисков, так что может не взлететь, но посмотрим.
Ближайший план - отучить Нарратора галлюцинировать, запилить новый пайплайн, добить eval тесты для нормального замера времени ответа моделей и потребления токенов (юнит-экономику никто не отменял), добавить пару механик - и запустить вторую альфу. Если качество будет хорошим, а длительность и стоимость хода приемлемыми, буду двигаться дальше этим путём. Если нет - буду искать другой путь.
Как-то так :)
🔥1
Разбираюсь с одной из самых бесячих проблем - повторения в ответе рассказчика ("груз знаний", "вода по колено", вот это всё). На скрине пример с чашей - второе сообщение начинается с дублирования первого. Похоже, одна из ключевых проблем - "загрязнение контекста". Для плавности нарратива и контекста рассказчику передаётся несколько последних ходов с его же полным ответом. Оказывается, для него (а может конкретно для llama-70b-versatile) такое воспринимается как few shots и часто имеет приоритет над системными инструкциями. Однако :)
🔥2❤1
Пытаюсь протестировать такой кейс, случившийся на альфе. Игрок: "я не хочу совершить действие я бездействую и там самым у меня есть лук который я использую беру стре лу и рукой тыкаю в свитки что бы еще раз их задеть"
Сейчас видно, что llm-боец неплохо справился с интерпретацией, а llm-рассказчик выдал игроку более-менее релевантный ответ вместо бреда. И это хорошо))
На самом деле, у игрока до этого баг был в другом: боец вообще запретил действие, а причина была в том, что ему в истории (для понимания контекста) передавался ответ рассказчика за предыдущий раунд о том, что все действия потрачены! То есть боец получает валидные "used/available_actions" (видно на скрине) и одновременно историю за предыдущий раунд. Эти данные противоречат друг другу, но история описана красочно (даже если это вообще галлюцинация!), и он выбирает верить истории. Вот так загрязнение контекста ломает логику других моделей в самых неожиданных местах :)
Как всё это лечится расскажу отдельно.
Сейчас видно, что llm-боец неплохо справился с интерпретацией, а llm-рассказчик выдал игроку более-менее релевантный ответ вместо бреда. И это хорошо))
На самом деле, у игрока до этого баг был в другом: боец вообще запретил действие, а причина была в том, что ему в истории (для понимания контекста) передавался ответ рассказчика за предыдущий раунд о том, что все действия потрачены! То есть боец получает валидные "used/available_actions" (видно на скрине) и одновременно историю за предыдущий раунд. Эти данные противоречат друг другу, но история описана красочно (даже если это вообще галлюцинация!), и он выбирает верить истории. Вот так загрязнение контекста ломает логику других моделей в самых неожиданных местах :)
Как всё это лечится расскажу отдельно.
🔥2
Ну, что ж, на текущем этапе основные галлюцинации Рассказчика побеждены, и это решило почти половину проблем, обнаруженных игроками, и 90% того, что в целом ломало игру! 🥳
Ключевые проблемы:
* загрязнение истории
* слишком тяжёлый системный промпт
* противоречивые инструкции и отдельные формулировки
* распределение инструкций между системным и основным промптом
История - самый коварный враг, так как передаётся разным llm и сбивает их с толку. История с галлюцинациями опасна вдвойне! Исправление: агентам теперь передаётся не чистый текст Рассказчика из предыдущих ходов, а лог произошедших событий: атаки, спасброски, обнаруженные враги и т.п.
Промпт теперь где возможно формируется динамически. Нет боя - Рассказчику не надо знать, как этот бой описывать. Ход врага - Бойцу не надо знать, как анализировать запрос игрока.
Инструкции и формулировки - отдельное искусство и куча геморроя. Хуже всего, что то, что работает для одной модели, не будет работать для другой. Сейчас ответы мне более-менее нравятся в большинстве случаев, но доработки ещё потребуются.
Распределение инструкций тоже дало сильный результат: в основном промпте требование описать программно сформированный скелет истории (атаки, что видит игрок и т.д.) плюс часть динамических инструкций. В системном - основные инструкции плюс контекст игры. Такой способ отлично фокусирует llm на ключевых вещах, а не на описании локации, и сильно уменьшает галлюцинации.
Неожиданно, Рассказчику нужны причинно-следственные связи. Например, без них, если игрок подбирает
лист и на него вдруг нападет враг, Рассказчик в ответе сделает этот лист особенным: "Лист, который
вы выбрали, кажется обычным пустым пергаментом, без каких-либо заметных знаков или символов. Однако, когда вы берете его, вы замечаете, что он немного тяжелее, чем ожидалось, и на его поверхности есть едва заметный след от какой-то давно стершейся надписи..."
Как мне объяснил чат-бот, такое происходит, потому что модель мыслит паттернами причинно-следственных связей. Если связей нет - надо их придумать. Вот это номер!
А как только передаёшь что-то вроде "это происходит, потому что сработал триггер врага" - вся эта чушь исчезает, у вас в руках обычный лист, и на вас нападает враг.
Если с чем-то подобным сталкивались - пишите)
Ключевые проблемы:
* загрязнение истории
* слишком тяжёлый системный промпт
* противоречивые инструкции и отдельные формулировки
* распределение инструкций между системным и основным промптом
История - самый коварный враг, так как передаётся разным llm и сбивает их с толку. История с галлюцинациями опасна вдвойне! Исправление: агентам теперь передаётся не чистый текст Рассказчика из предыдущих ходов, а лог произошедших событий: атаки, спасброски, обнаруженные враги и т.п.
Промпт теперь где возможно формируется динамически. Нет боя - Рассказчику не надо знать, как этот бой описывать. Ход врага - Бойцу не надо знать, как анализировать запрос игрока.
Инструкции и формулировки - отдельное искусство и куча геморроя. Хуже всего, что то, что работает для одной модели, не будет работать для другой. Сейчас ответы мне более-менее нравятся в большинстве случаев, но доработки ещё потребуются.
Распределение инструкций тоже дало сильный результат: в основном промпте требование описать программно сформированный скелет истории (атаки, что видит игрок и т.д.) плюс часть динамических инструкций. В системном - основные инструкции плюс контекст игры. Такой способ отлично фокусирует llm на ключевых вещах, а не на описании локации, и сильно уменьшает галлюцинации.
Неожиданно, Рассказчику нужны причинно-следственные связи. Например, без них, если игрок подбирает
лист и на него вдруг нападет враг, Рассказчик в ответе сделает этот лист особенным: "Лист, который
вы выбрали, кажется обычным пустым пергаментом, без каких-либо заметных знаков или символов. Однако, когда вы берете его, вы замечаете, что он немного тяжелее, чем ожидалось, и на его поверхности есть едва заметный след от какой-то давно стершейся надписи..."
Как мне объяснил чат-бот, такое происходит, потому что модель мыслит паттернами причинно-следственных связей. Если связей нет - надо их придумать. Вот это номер!
А как только передаёшь что-то вроде "это происходит, потому что сработал триггер врага" - вся эта чушь исчезает, у вас в руках обычный лист, и на вас нападает враг.
Если с чем-то подобным сталкивались - пишите)
👍1
П維чему нейро考ети дел思ют так — это название вот этой статьи: https://habr.com/ru/companies/selectel/articles/1044854/
Актуально, т.к. у меня ровно та же проблема, и те, кто пробовал альфу, наверняка видели и иероглифы, и фразы типа "враг seems готов напасть".
Хз как лечить. Кто сталкивался? Как фиксили?
Судя по статье и комментам, ставить температуру ниже (ок), не использовать штрафы за повторения (не использую), выбирать менее квантованные модели.
Актуально, т.к. у меня ровно та же проблема, и те, кто пробовал альфу, наверняка видели и иероглифы, и фразы типа "враг seems готов напасть".
Хз как лечить. Кто сталкивался? Как фиксили?
Судя по статье и комментам, ставить температуру ниже (ок), не использовать штрафы за повторения (не использую), выбирать менее квантованные модели.
👍1
Наконец-то добрался до ускорения работы одного из агентов. Кто был на альфе наверняка помнят ожидание ответа секунд по 40.
Так вот, проблема в том, что тот же Боец делал слишком много всего: броски придумывал, модификаторы подставлял, формулы урона... А зачем, когда всё это может делать код? А Боец просто говорит: npc1 атакует игрока, оружие такое-то, действие валидно. Всё.
Изменения заняли одну ночь, выигрыш по времени правда всего лишь раза в 2 примерно (а в рамках всего хода не больше 30%)... Я большего ожидал. Но всё же это важный шаг :)
Почему не сделал так сразу? Наверное, потому что шёл от одной модели, которая делала вообще всё, к трём (мир или бой, плюс рассказчик), а сейчас вообще иду к пайплайну "диспетчер -> агенты-специалисты в параллели -> судья-сборщик -> рассказчик". Соответственно, промпты, входные данные и ответственность резал по чуть-чуть по мере необходимости.
И в целом, думаю, это правильный подход. Сперва проверьте вашу идею (PoC) технически и с точки зрения ценности для пользователя. Пусть это будет что-то кривое из говна и палок, это ок, это ведь лишь PoC. И если концепция окажется технически работоспособной и ценной для людей - можно переходить к шагу "сделать по-нормальному".
P.S. Новый пайплайн с кучей вызовов небольших llm - тоже гипотеза. Не знаю взлетит или нет, так как такой подход будет жрать много токенов и может быть ни разу не быстрым. Зато он позволит делать вещи, которые не позволяют делать конкуренты. Например, пытаться решать загадку прямо во время боя, или уговорить врага пойти пить пиво :) Такое сейчас возможно только с живым мастером. Через несколько недель WeaveAI тоже такое сможет.
Вопрос только - будет ли это приемлемо по времени и готовы ли люди будут платить выше среднего за такие навороты. Так что всё это пока что лишь гипотеза. Надеюсь, подтвердится :) Что думаете?
Так вот, проблема в том, что тот же Боец делал слишком много всего: броски придумывал, модификаторы подставлял, формулы урона... А зачем, когда всё это может делать код? А Боец просто говорит: npc1 атакует игрока, оружие такое-то, действие валидно. Всё.
Изменения заняли одну ночь, выигрыш по времени правда всего лишь раза в 2 примерно (а в рамках всего хода не больше 30%)... Я большего ожидал. Но всё же это важный шаг :)
Почему не сделал так сразу? Наверное, потому что шёл от одной модели, которая делала вообще всё, к трём (мир или бой, плюс рассказчик), а сейчас вообще иду к пайплайну "диспетчер -> агенты-специалисты в параллели -> судья-сборщик -> рассказчик". Соответственно, промпты, входные данные и ответственность резал по чуть-чуть по мере необходимости.
И в целом, думаю, это правильный подход. Сперва проверьте вашу идею (PoC) технически и с точки зрения ценности для пользователя. Пусть это будет что-то кривое из говна и палок, это ок, это ведь лишь PoC. И если концепция окажется технически работоспособной и ценной для людей - можно переходить к шагу "сделать по-нормальному".
P.S. Новый пайплайн с кучей вызовов небольших llm - тоже гипотеза. Не знаю взлетит или нет, так как такой подход будет жрать много токенов и может быть ни разу не быстрым. Зато он позволит делать вещи, которые не позволяют делать конкуренты. Например, пытаться решать загадку прямо во время боя, или уговорить врага пойти пить пиво :) Такое сейчас возможно только с живым мастером. Через несколько недель WeaveAI тоже такое сможет.
Вопрос только - будет ли это приемлемо по времени и готовы ли люди будут платить выше среднего за такие навороты. Так что всё это пока что лишь гипотеза. Надеюсь, подтвердится :) Что думаете?
🔥2
Кратенько описал свой опыт игры с чат-ботом на пикабу: https://pikabu.ru/story/virtualnyiy_geym_master_14058317 Коротко, без рекламы, без ничего - следую совету "прогреть аудиторию". У кого есть там аккаунт - лайкните, плз 🙂 С меня +15 к удаче на следующем тесте. А за добрый коммент пропишу вам в базе АК-47 руками))
❤1😁1
Запостил на Пикабу историю создания PoC проекта, глянуть (а также лайкнуть и рассказать друзьям) можно здесь: https://pikabu.ru/story/svoy_dungeon_master_v_telegrame_na_kolenkakh_14064023
Собственно, там я показал схему своего рабочего PoC, который собрал то ли в самом конце февраля, то ли в самом начале мая. На нём же я и прошёл свой иишный сценарий на 10 локаций и понял: оно работает!
Собственно, там я показал схему своего рабочего PoC, который собрал то ли в самом конце февраля, то ли в самом начале мая. На нём же я и прошёл свой иишный сценарий на 10 локаций и понял: оно работает!
🔥3
Если вы думаете, что я взялся покорять пикабу и играться с артами, а про разработку забыл, то вы ошибаетесь :)
Над чем работаю сейчас? Над переходом на новый пайплайн 😎
До этого была дихотомия: либо мирный агент (Арбитр), либо агент-боец (Файтер). Ну ещё первый мог вызывать второго в случае инициации боя, чтобы всё случилось в один ход. Ограничения очевидны: за раз можно обработать что-то одно. Новому пайплайну без разницы, сколько отдельных действий/проверок обрабатывать за раз.
На текущий момент удалось расщипить Арбитра на несколько LLM-специалистов и сделать параллельный запуск, добавить диспетчера (Router / Decomposer на схеме) в начало и... столкнуться с проблемами...
А ещё с лимитом размера сообщений тут в tg, как ни странно... дополню в комменте.
Над чем работаю сейчас? Над переходом на новый пайплайн 😎
До этого была дихотомия: либо мирный агент (Арбитр), либо агент-боец (Файтер). Ну ещё первый мог вызывать второго в случае инициации боя, чтобы всё случилось в один ход. Ограничения очевидны: за раз можно обработать что-то одно. Новому пайплайну без разницы, сколько отдельных действий/проверок обрабатывать за раз.
На текущий момент удалось расщипить Арбитра на несколько LLM-специалистов и сделать параллельный запуск, добавить диспетчера (Router / Decomposer на схеме) в начало и... столкнуться с проблемами...
А ещё с лимитом размера сообщений тут в tg, как ни странно... дополню в комменте.
🔥1🤯1
Вожусь с обработкой свободных действий.
Запрос игрока: "подобрать плавающий лист, сделать из него самолётик, потом запустить так, чтобы он точно приземлился на чашу"
Атомарные действия "подобрать лист" и "сделать самолётик" модель одобрила, а по финальному действию предложила бросок:
Как это обрабатывать, особенно если результат может что-то стриггерить - отдельная инженерная задача, которую предстоит решить. Но в целом мне нравится: теперь у игрока может что-то получиться, а может и не получиться :)
Запрос игрока: "подобрать плавающий лист, сделать из него самолётик, потом запустить так, чтобы он точно приземлился на чашу"
Атомарные действия "подобрать лист" и "сделать самолётик" модель одобрила, а по финальному действию предложила бросок:
{
"action": "запустить самолётик так, чтобы он приземлился на чашу",
"is_valid": true,
"auto_results": [],
"checks": [
{
"skill": "Dexterity",
"dc": 15,
"on_success": "самолётик успешно приземляется на чашу",
"on_fail": "самолётик падает в воду",
"reason": "необходима точность при запуске самолётика"
}
]
}Как это обрабатывать, особенно если результат может что-то стриггерить - отдельная инженерная задача, которую предстоит решить. Но в целом мне нравится: теперь у игрока может что-то получиться, а может и не получиться :)
🔥2
Кто-нибудь писал статьи на Хабре?
Я нет. Но надо. Потому что траффик в этот канал и на будущий лендинг из ниоткуда не возьмётся. Поэтому, собственно, я начал что-то постить на Пикабу, а теперь вот подбираюсь к Хабру.
С Хабром интересно. Оказывается, нельзя просто так взять и запостить статью. Нужно пройти квест:
* регистрация (ну, это само собой);
* статья в песочницу;
* модератор должен заценить творение и одобрить.
Только после этого статья увидит мир, а пользователь сможет уже нормально постить статьи. И чтобы по-нормальному пройти песочницу, вообще надо сделать так:
* оформить статью в google docs;
* лично связаться с модератором;
* получить рекомендации и внести правки;
* профит.
Требования к статьям довольно высокие, вот хаброский гайд по оформлению.
На текущий момент я зарегался, изучил гайды и начал писать нечто под заголовком "LLM для игры в D&D: эволюция подхода". Драфт на 9 вордовских страниц, всего будет 10. Ппц 🤯 И я даже не знаю, много это или мало... Ну, will see.
Я нет. Но надо. Потому что траффик в этот канал и на будущий лендинг из ниоткуда не возьмётся. Поэтому, собственно, я начал что-то постить на Пикабу, а теперь вот подбираюсь к Хабру.
С Хабром интересно. Оказывается, нельзя просто так взять и запостить статью. Нужно пройти квест:
* регистрация (ну, это само собой);
* статья в песочницу;
* модератор должен заценить творение и одобрить.
Только после этого статья увидит мир, а пользователь сможет уже нормально постить статьи. И чтобы по-нормальному пройти песочницу, вообще надо сделать так:
* оформить статью в google docs;
* лично связаться с модератором;
* получить рекомендации и внести правки;
* профит.
Требования к статьям довольно высокие, вот хаброский гайд по оформлению.
На текущий момент я зарегался, изучил гайды и начал писать нечто под заголовком "LLM для игры в D&D: эволюция подхода". Драфт на 9 вордовских страниц, всего будет 10. Ппц 🤯 И я даже не знаю, много это или мало... Ну, will see.
🔥3
Запилил лендинг: https://weaveai.studio. Текст ещё надо выправлять (пока там нейрослоп), но в целом штука рабочая. Буду рад вашему фидбэку — косяки, херовый стиль и т.д.
WeaveAI
WeaveAI — AI-powered Text RPG Engine
Full-fledged DnD in Telegram. An AI Game Master runs deep stories with dice, inventory, and tactics.
🔥2
Уже вторую неделю думаю про обработку каскада событий, даже микро-пост об этом написал.
Пример: плут крадётся, бросает на ловкость, не прошёл; в результате срабатывает ловушка; от шума просыпается стражник; начинается бой.
Одно событие проблем не вызывает. ИИ в движке определяет в самом начале, нужно ли бросать проверку. Затем последующий блок кода делает бросок и считает последствия (урон, например). Затем ИИ-рассказчик выдаёт нарратив: "ай-яй-яй, у вас не получилось, ловушка взорвалась! получите 7 хп урона огнём". Всё.
Сложность в том, что взрыв ловушки сам по себе порождает второе событие. И его, по-хорошему, надо обрабатывать по-новой — точно так же, как ввод игрока. То есть надо проверить все триггеры и решить, что произошло; если что-то произошло — тоже что-то сделать, посчитать и сообщить игроку.
И тут возникает пачка вопросов. Как это делать? Рекурсивно? Ходы затянутся и сильно подорожают. Растянуть на N ходов — но как это сделать в телеге, как это будет выглядеть игромеханически? Или сделать потоковую генерацию, как у современных агентов? Как вообще определять, будет ли каскад? Не вызывать же повторную валидацию на каждый чих!
Вопросы на миллион. Что думаете?
Пример: плут крадётся, бросает на ловкость, не прошёл; в результате срабатывает ловушка; от шума просыпается стражник; начинается бой.
Одно событие проблем не вызывает. ИИ в движке определяет в самом начале, нужно ли бросать проверку. Затем последующий блок кода делает бросок и считает последствия (урон, например). Затем ИИ-рассказчик выдаёт нарратив: "ай-яй-яй, у вас не получилось, ловушка взорвалась! получите 7 хп урона огнём". Всё.
Сложность в том, что взрыв ловушки сам по себе порождает второе событие. И его, по-хорошему, надо обрабатывать по-новой — точно так же, как ввод игрока. То есть надо проверить все триггеры и решить, что произошло; если что-то произошло — тоже что-то сделать, посчитать и сообщить игроку.
И тут возникает пачка вопросов. Как это делать? Рекурсивно? Ходы затянутся и сильно подорожают. Растянуть на N ходов — но как это сделать в телеге, как это будет выглядеть игромеханически? Или сделать потоковую генерацию, как у современных агентов? Как вообще определять, будет ли каскад? Не вызывать же повторную валидацию на каждый чих!
Вопросы на миллион. Что думаете?
Пикабу
Каскад событий в ДнД
Пост пикабушника user8105112
❤1🔥1
Не врубаюсь, как работают соцсети. Написал короткое размышление на тему Живой мастер vs ИИ. (Конечно же не просто так, а потому что надо формировать "правильное" отношение аудитории к ИИ чат-ботам.) Как по мне, размышления здравые. И кто-то даже написал классный развёрнутый коммент, дополняющий мои мысли. Но! За первые полчаса тут же отхватил несколько минусов. Не понимаю почему. Есть идеи что не так? Дайте фидбэк, плз.
Пикабу
Живой мастер vs ИИ
Пост пикабушника user8105112
🤯2
