Дело в том, что мы собрали обратную связь от всех кандидатов, которые проходили наше тестовое AI-интервью, поэтому нам хотелось бы разобраться в вашем кейсе подробнее.
Если речь действительно о прохождении нашего тестового процесса, пожалуйста, напишите нам на hr@just-ai.com с почты, с которой откликались. Мы обязательно поднимем историю, разберемся в ситуации и пригласим вас протестировать решение, когда оно выйдет в прод. Не хочется вас оставлять с таким впечатлением!
Очень жаль, что у вас получился такой опыт — это как раз тот кейс, где сбой в передаче контекста между ботом и рекрутером сильно портит впечатление от всей системы. Это действительно неприятно
В нашей агентной системе мы такие моменты закрываем: чтобы данные, которые кандидат уже оставил в AI-скрининге, нормально доходили до HR и не приходилось повторно спрашивать одно и то же.
Как только мы выкатим боевую версию на сайт — будем рады, если зайдете потестировать!
К счастью, или к сожалению, этот сценарий уже не выглядит фантастикой. И мы это прекрасно понимаем.
Именно поэтому мы с самого начала отказались от теоретических вопросов в скрининге — любая LLM за пару секунд сгенерирует идеальный ответ.
Поэтому наш агент спрашивает не про теорию, а про реальный опыт: конкретные ситуации, инструменты, решения и последствия. Например: «Расскажите про инцидент, который вы разбирали. Что стало причиной, как нашли проблему, что изменили после, чтобы это не повторилось». Такие ответы гораздо сложнее качественно сымитировать без настоящего опыта — там важны детали, последовательность действий и понимание контекста.
Гонка между LLM кандидатов и LLM работодателей действительно, скорее всего, станет новой нормой. Но финальное решение все равно остается за живым человеком. Поэтому мы и смотрим на AI как на первый этап отбора, а не как на полную замену интервью.
Этот аргумент мы понимаем 🙂. И сами много спорили внутри команды на эту тему, когда начинали проект.
Но здесь важно разделять первичный скрининг и полноценную оценку специалиста. Агент не принимает решение о найме и не пытается оценить человека. Его задача гораздо более приземленная: собрать базовую информацию, задать стандартные вопросы и помочь рекрутеру быстрее сориентироваться в потоке откликов.
До автоматизации на этом этапе обычно происходил примерно такой же формальный процесс — только через короткий звонок с рекрутером, где за ограниченное время уточнялись стек, опыт, ожидания и базовое соответствие вакансии. Этот процесс был просто медленнее и с большим количеством ошибок из-за усталости и человеческого фактора. Мы скорее автоматизировали именно эту рутинную часть.
А уже дальше остаются живые этапы: общение с рекрутером, техническое интервью, знакомство с командой, обсуждение опыта и подхода к работе — больше времени на полноценный разговор. И вот там никакой AI человека не заменяет.
Конечно, резюме мы тоже смотрим — автоматизация не заменяет этот этап, а помогает снять рутину с первичного скрининга.
Резюме — это вход, но не финал. Оно почти никогда не отвечает на вопросы, которые реально нужны рекрутеру на первом контакте:
Актуален ли стек сейчас, а не пять лет назад
Есть ли интерес именно к этой вакансии — или это массовая рассылка
Какой формат работы предпочтителен
Какие ожидания по компенсации
Когда готов выйти
Детали реального опыта в конкретных технологиях
Даже после внимательного прочтения CV рекрутер обычно проводит ровно тот же первичный диалог. Просто потому, что резюме — это рекламный документ, а не интервью. Плюс CV — это очень неструктурированный источник. Кто-то пишет подробно, кто-то одной строкой, кто-то не обновлял его год. Агент помогает привести первичный сбор информации к единому формату и сразу подготовить рекрутеру краткую сводку.
И еще раз подчеркнем: AI-скрининг — это не замена человеку и не полноценная оценка кандидата. Задача агента гораздо проще — разобрать поток откликов, выделить релевантные профили и убрать рутину повторяющихся вопросов.
Если компания уже собирает отклики через карьерный сайт, hh.ru, email или HR-системы, то она уже работает с персональными данными кандидатов и является оператором ПДн.
AI-скрининг тут не создает какую-то новую сущность, а скорее добавляет еще один слой обработки — автоматизированный первичный отбор и подготовку сводки для HR. При внедрении таких сценариев важно, чтобы процессы обработки ПДн соответствовали требованиям законодательства: проверялись цели обработки, состав данных, используемые системы, вопросы хранения и трансграничной передачи.
Мы рады, что статья понравилась! Спасибо за вопрос про безопасность — он действительно важный.
Если собирать такого агента на Agent Platform, для работы с персональными данными можно подключить Jay Guard — AI Security-шлюз. Он встраивается между приложением и LLM и позволяет маскировать чувствительные данные перед отправкой в модель: ФИО, телефоны, паспортные данные и другие типы PII. В модель уходят уже псевдонимизированные значения, а на выходе данные автоматически восстанавливаются.
По моделям тоже нет жесткой привязки: в платформе поддерживаются и GigaChat, и YandexGPT. Для задач скрининга они тоже подходят, модель можно переключать без перестройки всей архитектуры.
Здравствуйте! Справедливые наблюдения, спасибо что расписали подробно. Вы правы в главном: рынок найма терпит изменения, и кандидатам реально тяжело.
По поводу «поотвечает 15 раз и получит игнор» — эта боль даже не про агента, а про культуру найма в целом. Агент как раз убирает одну из самых раздражающих частей: молчание после отклика. Результат скрининга кандидат получает сразу, а не ждет пять рабочих дней.
«Пилил фичи и фиксил баги» — мы понимаем, что за этим стоит реальная работа. Просто такая формулировка не дает рекрутеру ничего, за что зацепиться. Скорее всего живой человек на звонке спросил бы то же самое: «а можете конкретнее?»
Про коммерческую тайну — тут есть нюанс. Никто не просит называть клиентов или раскрывать детали реализации. «Оптимизировал запросы к БД, сократил время ответа с 2 секунд до 300 мс» — это не тайна, это описание своей работы. Разница между «пилил» и «сделал вот это» обычно не в секретности, а в том, как это сформулировать.
Про новичков — верно, если у кандидата только учебные проекты, порог будет ниже. Но и здесь есть выход: в статье мы описали, что кандидаты, не набравшие нужный балл, все равно могут написать сопроводительное письмо и попасть в базу. Никто не пропадает бесследно — просто приоритет другой :)
К тому же под каждую вакансию можно регулировать критерии грин и редфлагов — в этом и преимущество шаблона
Да, вы правильно поняли общий принцип, статья как раз про такой подход. Также к задаче LLM относится генерация и расследование инцидента. Внутри компании мы сейчас смотрим в сторону более агентного подхода. Если будет что показать стабильно и безопасно — принесём продолжение. Stay in touch!
Привет! Спасибо за вопросы.
1) Мы считали стоимость владения процессом. У нас в расчёт входят: инженерные часы на старт (первичный набор правил), инженерные часы на MTTR (разбор алертов/инцидентов) и стоимость шума (неactionable алерты). По внутренним результатам мы видим сокращение времени разбора инцидентов и снижение доли ручных проверок. Это окупается, потому что 30–60 минут ручного расследования инженером обычно дороже одного или нескольких LLM-вызовов.
2) Согласны, многие проверки можно реализовать и без LLM и именно так они у нас частично и исполняются. LLM нам особенно помогает там, где утекают часы: быстро собрать черновик стартового набора правил для новой/изменившейся схемы и превратить алерт в понятное мини-расследование с гипотезами и следующим шагом. Когда таблиц сотни, схемы меняются, а хочется расширять библиотеку правил, детерминированный подход часто превращается в рост кодовой базы и числа исключений. LLM здесь автоматизирует часть ручного интеллектуального труда.
У нас немного другой опыт: когда уже хорошо продумана логика работы агента и сценарии, сами промпты писать обычно не так сложно — они скорее становятся способом аккуратно «упаковать» эту логику для модели. Поэтому в статье мы больше фокусировались именно на архитектуре и процессе проектирования.
Промпты мы действительно частично замылили, потому что в них есть части, связанные с конкретным функционалом и работой продукта. Но базовой частью промпта можем поделиться — она как раз отражает общий подход.
Пример основной структуры промпта:
Ты — внутренний QA-Agent компании, специализирующийся на автоматизации создания тестовой документации (чек-листов, тест-кейсов) и ответах на вопросы пользователя. У тебя есть доступ к базе данных vs doc и возможность использовать полученные ссылки/данные из confluence по bearer token. У тебя есть следующие инструменты: - База знаний vs doc — используй для доступа к документации и материалам, ты можешь находить нужные ссылки, читать статьи полностью и анализировать полученную информацию. - Промт для составления чек-листа — используй, когда пользователь просит сгенерировать чек-лист по заданной теме. - Промт для составления тест-кейсов — используй, когда пользователь просит сгенерировать тест-кейсы по заданной теме. - Промт для ревью документации — используй для проверки сгенерированной тестовой документации. - connectConfluence — используй api для доступа в Confluence и поиска и чтения статей. - LLM — объединяй полученные данные и автоматически генерируй чек-листы и тест-кейсы по задаче.
Алгоритм: На входе ты получаешь задание сгенерировать чек-лист или тест-кейсы по заданной теме или получаешь вопрос от пользователя.
Если получаешь вопрос от пользователя, то используй базу знаний vs doc чтобы дать короткий ответ на заданный вопрос.
Если получаешь задание сгенерировать чек-лист или тест кейсы по теме, то найди всю, связанную с темой, информацию в базе знаний. Извлекай информацию не только из кратких текстовых фрагментов, найденных vs_doc, но и напрямую из исходных документов по ссылкам, содержащимся в этих фрагментах.
Для создания и анализа тестовой документации используй всю найденную релевантную информацию по теме запроса, а не одну ссылку. Используй промты для составления чек-листов и тест-кейсов. Сгенерируй структурированную тестовую документацию: чек-листы, тест-кейсы, а также — при необходимости — общие подходы/замечания к тестированию.
После генерации тестовой документации, используй промт для ревью документации, с помощью которого проверь сгенерированные чек-листы или тест-кейсы и соотнеси их с найденной документацией по теме запроса в базе знаний и в confluence.
В итоге предоставь пользователю сгенерированную тестовую документацию, результаты ревью и итоговую тестовую документацию, доработанную по результатам ревью. Итоговая документация должна содержать не только доработанные кейсы, а всю документацию полностью по всем кейсам/чек-листу в соответствии с промтом.
Тестовая документация всегда формируется на основе реальных артефактов задачи. Если какие-либо материалы/ссылки недоступны — сообщи об этом в итоговом ответе. Никогда не выдумывай информацию. Всегда опирайся на достоверные источники через инструменты.
Если запрос не ясен или нужны уточнения - перед генерацией задай пользователю уточняющие вопросы.
Все твои ответы должны быть только на русском языке.
Здравствуйте! Спасибо за такой конструктивный комментарий! Любим, когда так. Про оркестратора согласны. Ваша формулировка понятнее и человечнее. Взяли на заметку! :)
Что касается других архитектур: мы сознательно начали с основ т.к. эти архитектуры уже прошли проверку боем на нашей платформе и стабильно работают, а как только соберем больше наработок по другим архитектурам, вроде Critic-Generator, Market-based или Blackboard — дополним эту статью или соберем еще один материал! Спасибо за вашу идею)
Спасибо за обратную связь! Скорее всего ваш браузер блокирует всплывающие окна – из-за этого кнопки могут не срабатывать. Попробуйте отключить блокировку в настройках браузера или открыть сайт в другом браузере.
Пока наш продукт действительно предназначен для работы в десктопной версии, и будем рады, если вы попробуете его там. А мобильная версия, конечно, тоже будет, но чуть позже!
Мы воспроизводили у себя при прямом подключении через api, без системного промпта. Ключевое здесь, что подключиться надо к версии доступной именно в Azure, версия GPT 3,5 Turbo 0125. И мы не обвиняем компании в использовании данных через api, эту гипотезу мы как раз отбрасываем. Сейчас кажется, что модель просто из-за своей архитектуры научившись на большом российском датасете узнала про существование Just AI, и т. к. названия схожие, стала путать нас иногда с Open AI. При этом, видимо, дополнительного alignment по ответу на этот вопрос на русском не было.
Разработчик бота подключал модель GPT 3,5 Turbo последней версии, не нашу модель. А дальше мы уже сами воспроизводили ситуацию, напрямую работая также с GPT 3,5 Turbo
Мы работаем через API, память моделей не используем. К тому же, как видите, модель отвечает и про других создателей. В наших диалогах с ней точно про них ничего не было.
Дело в том, что мы собрали обратную связь от всех кандидатов, которые проходили наше тестовое AI-интервью, поэтому нам хотелось бы разобраться в вашем кейсе подробнее.
Если речь действительно о прохождении нашего тестового процесса, пожалуйста, напишите нам на hr@just-ai.com с почты, с которой откликались. Мы обязательно поднимем историю, разберемся в ситуации и пригласим вас протестировать решение, когда оно выйдет в прод. Не хочется вас оставлять с таким впечатлением!
Очень жаль, что у вас получился такой опыт — это как раз тот кейс, где сбой в передаче контекста между ботом и рекрутером сильно портит впечатление от всей системы. Это действительно неприятно
В нашей агентной системе мы такие моменты закрываем: чтобы данные, которые кандидат уже оставил в AI-скрининге, нормально доходили до HR и не приходилось повторно спрашивать одно и то же.
Как только мы выкатим боевую версию на сайт — будем рады, если зайдете потестировать!
К счастью, или к сожалению, этот сценарий уже не выглядит фантастикой. И мы это прекрасно понимаем.
Именно поэтому мы с самого начала отказались от теоретических вопросов в скрининге — любая LLM за пару секунд сгенерирует идеальный ответ.
Поэтому наш агент спрашивает не про теорию, а про реальный опыт: конкретные ситуации, инструменты, решения и последствия. Например: «Расскажите про инцидент, который вы разбирали. Что стало причиной, как нашли проблему, что изменили после, чтобы это не повторилось». Такие ответы гораздо сложнее качественно сымитировать без настоящего опыта — там важны детали, последовательность действий и понимание контекста.
Гонка между LLM кандидатов и LLM работодателей действительно, скорее всего, станет новой нормой. Но финальное решение все равно остается за живым человеком. Поэтому мы и смотрим на AI как на первый этап отбора, а не как на полную замену интервью.
Этот аргумент мы понимаем 🙂. И сами много спорили внутри команды на эту тему, когда начинали проект.
Но здесь важно разделять первичный скрининг и полноценную оценку специалиста. Агент не принимает решение о найме и не пытается оценить человека. Его задача гораздо более приземленная: собрать базовую информацию, задать стандартные вопросы и помочь рекрутеру быстрее сориентироваться в потоке откликов.
До автоматизации на этом этапе обычно происходил примерно такой же формальный процесс — только через короткий звонок с рекрутером, где за ограниченное время уточнялись стек, опыт, ожидания и базовое соответствие вакансии. Этот процесс был просто медленнее и с большим количеством ошибок из-за усталости и человеческого фактора. Мы скорее автоматизировали именно эту рутинную часть.
А уже дальше остаются живые этапы: общение с рекрутером, техническое интервью, знакомство с командой, обсуждение опыта и подхода к работе — больше времени на полноценный разговор. И вот там никакой AI человека не заменяет.
Конечно, резюме мы тоже смотрим — автоматизация не заменяет этот этап, а помогает снять рутину с первичного скрининга.
Резюме — это вход, но не финал. Оно почти никогда не отвечает на вопросы, которые реально нужны рекрутеру на первом контакте:
Актуален ли стек сейчас, а не пять лет назад
Есть ли интерес именно к этой вакансии — или это массовая рассылка
Какой формат работы предпочтителен
Какие ожидания по компенсации
Когда готов выйти
Детали реального опыта в конкретных технологиях
Даже после внимательного прочтения CV рекрутер обычно проводит ровно тот же первичный диалог. Просто потому, что резюме — это рекламный документ, а не интервью. Плюс CV — это очень неструктурированный источник. Кто-то пишет подробно, кто-то одной строкой, кто-то не обновлял его год. Агент помогает привести первичный сбор информации к единому формату и сразу подготовить рекрутеру краткую сводку.
И еще раз подчеркнем: AI-скрининг — это не замена человеку и не полноценная оценка кандидата. Задача агента гораздо проще — разобрать поток откликов, выделить релевантные профили и убрать рутину повторяющихся вопросов.
Если компания уже собирает отклики через карьерный сайт, hh.ru, email или HR-системы, то она уже работает с персональными данными кандидатов и является оператором ПДн.
AI-скрининг тут не создает какую-то новую сущность, а скорее добавляет еще один слой обработки — автоматизированный первичный отбор и подготовку сводки для HR. При внедрении таких сценариев важно, чтобы процессы обработки ПДн соответствовали требованиям законодательства: проверялись цели обработки, состав данных, используемые системы, вопросы хранения и трансграничной передачи.
Со своей стороны мы эти требования учитываем.
Мы рады, что статья понравилась! Спасибо за вопрос про безопасность — он действительно важный.
Если собирать такого агента на Agent Platform, для работы с персональными данными можно подключить Jay Guard — AI Security-шлюз. Он встраивается между приложением и LLM и позволяет маскировать чувствительные данные перед отправкой в модель: ФИО, телефоны, паспортные данные и другие типы PII. В модель уходят уже псевдонимизированные значения, а на выходе данные автоматически восстанавливаются.
По моделям тоже нет жесткой привязки: в платформе поддерживаются и GigaChat, и YandexGPT. Для задач скрининга они тоже подходят, модель можно переключать без перестройки всей архитектуры.
Здравствуйте! Справедливые наблюдения, спасибо что расписали подробно. Вы правы в главном: рынок найма терпит изменения, и кандидатам реально тяжело.
По поводу «поотвечает 15 раз и получит игнор» — эта боль даже не про агента, а про культуру найма в целом. Агент как раз убирает одну из самых раздражающих частей: молчание после отклика. Результат скрининга кандидат получает сразу, а не ждет пять рабочих дней.
«Пилил фичи и фиксил баги» — мы понимаем, что за этим стоит реальная работа. Просто такая формулировка не дает рекрутеру ничего, за что зацепиться. Скорее всего живой человек на звонке спросил бы то же самое: «а можете конкретнее?»
Про коммерческую тайну — тут есть нюанс. Никто не просит называть клиентов или раскрывать детали реализации. «Оптимизировал запросы к БД, сократил время ответа с 2 секунд до 300 мс» — это не тайна, это описание своей работы. Разница между «пилил» и «сделал вот это» обычно не в секретности, а в том, как это сформулировать.
Про новичков — верно, если у кандидата только учебные проекты, порог будет ниже. Но и здесь есть выход: в статье мы описали, что кандидаты, не набравшие нужный балл, все равно могут написать сопроводительное письмо и попасть в базу. Никто не пропадает бесследно — просто приоритет другой :)
К тому же под каждую вакансию можно регулировать критерии грин и редфлагов — в этом и преимущество шаблона
Да, вы правильно поняли общий принцип, статья как раз про такой подход. Также к задаче LLM относится генерация и расследование инцидента. Внутри компании мы сейчас смотрим в сторону более агентного подхода. Если будет что показать стабильно и безопасно — принесём продолжение. Stay in touch!
Привет! Спасибо за вопросы. 1) Мы считали стоимость владения процессом. У нас в расчёт входят: инженерные часы на старт (первичный набор правил), инженерные часы на MTTR (разбор алертов/инцидентов) и стоимость шума (неactionable алерты). По внутренним результатам мы видим сокращение времени разбора инцидентов и снижение доли ручных проверок. Это окупается, потому что 30–60 минут ручного расследования инженером обычно дороже одного или нескольких LLM-вызовов. 2) Согласны, многие проверки можно реализовать и без LLM и именно так они у нас частично и исполняются. LLM нам особенно помогает там, где утекают часы: быстро собрать черновик стартового набора правил для новой/изменившейся схемы и превратить алерт в понятное мини-расследование с гипотезами и следующим шагом. Когда таблиц сотни, схемы меняются, а хочется расширять библиотеку правил, детерминированный подход часто превращается в рост кодовой базы и числа исключений. LLM здесь автоматизирует часть ручного интеллектуального труда.
Интересное замечание, спасибо!
У нас немного другой опыт: когда уже хорошо продумана логика работы агента и сценарии, сами промпты писать обычно не так сложно — они скорее становятся способом аккуратно «упаковать» эту логику для модели. Поэтому в статье мы больше фокусировались именно на архитектуре и процессе проектирования.
Промпты мы действительно частично замылили, потому что в них есть части, связанные с конкретным функционалом и работой продукта. Но базовой частью промпта можем поделиться — она как раз отражает общий подход.
Пример основной структуры промпта:
Ты — внутренний QA-Agent компании, специализирующийся на автоматизации создания тестовой документации (чек-листов, тест-кейсов) и ответах на вопросы пользователя. У тебя есть доступ к базе данных vs doc и возможность использовать полученные ссылки/данные из confluence по bearer token.У тебя есть следующие инструменты:- База знаний vs doc — используй для доступа к документации и материалам, ты можешь находить нужные ссылки, читать статьи полностью и анализировать полученную информацию.
- Промт для составления чек-листа — используй, когда пользователь просит сгенерировать чек-лист по заданной теме.
- Промт для составления тест-кейсов — используй, когда пользователь просит сгенерировать тест-кейсы по заданной теме.
- Промт для ревью документации — используй для проверки сгенерированной тестовой документации.
- connectConfluence — используй api для доступа в Confluence и поиска и чтения статей.
- LLM — объединяй полученные данные и автоматически генерируй чек-листы и тест-кейсы по задаче.
Алгоритм:На входе ты получаешь задание сгенерировать чек-лист или тест-кейсы по заданной теме или получаешь вопрос от пользователя.
Если получаешь вопрос от пользователя, то используй базу знаний vs doc чтобы дать короткий ответ на заданный вопрос.
Если получаешь задание сгенерировать чек-лист или тест кейсы по теме, то найди всю, связанную с темой, информацию в базе знаний. Извлекай информацию не только из кратких текстовых фрагментов, найденных vs_doc, но и напрямую из исходных документов по ссылкам, содержащимся в этих фрагментах.
Для создания и анализа тестовой документации используй всю найденную релевантную информацию по теме запроса, а не одну ссылку.
Используй промты для составления чек-листов и тест-кейсов.
Сгенерируй структурированную тестовую документацию: чек-листы, тест-кейсы, а также — при необходимости — общие подходы/замечания к тестированию.
После генерации тестовой документации, используй промт для ревью документации, с помощью которого проверь сгенерированные чек-листы или тест-кейсы и соотнеси их с найденной документацией по теме запроса в базе знаний и в confluence.
В итоге предоставь пользователю сгенерированную тестовую документацию, результаты ревью и итоговую тестовую документацию, доработанную по результатам ревью. Итоговая документация должна содержать не только доработанные кейсы, а всю документацию полностью по всем кейсам/чек-листу в соответствии с промтом.
Тестовая документация всегда формируется на основе реальных артефактов задачи.
Если какие-либо материалы/ссылки недоступны — сообщи об этом в итоговом ответе.
Никогда не выдумывай информацию. Всегда опирайся на достоверные источники через инструменты.
Если запрос не ясен или нужны уточнения - перед генерацией задай пользователю уточняющие вопросы.
Все твои ответы должны быть только на русском языке.
Здравствуйте! Спасибо за такой конструктивный комментарий! Любим, когда так.
Про оркестратора согласны. Ваша формулировка понятнее и человечнее. Взяли на заметку! :)
Что касается других архитектур: мы сознательно начали с основ т.к. эти архитектуры уже прошли проверку боем на нашей платформе и стабильно работают, а как только соберем больше наработок по другим архитектурам, вроде Critic-Generator, Market-based или Blackboard — дополним эту статью или соберем еще один материал! Спасибо за вашу идею)
100%! Если у кого-то есть вижен на этот счет, с удовольствием подискутируем на эту тему!
У Артема же пойнт не про опыт клиентов, а про внутреннюю оценку эффективности AI-помощника. Но спасибо за ссылку с выдержкой из свежего отчета!
Спасибо, что подсветили этот момент. Мы активно думаем, как это улучшить .
Спасибо за обратную связь! Скорее всего ваш браузер блокирует всплывающие окна – из-за этого кнопки могут не срабатывать. Попробуйте отключить блокировку в настройках браузера или открыть сайт в другом браузере.
Пока наш продукт действительно предназначен для работы в десктопной версии, и будем рады, если вы попробуете его там. А мобильная версия, конечно, тоже будет, но чуть позже!
Спасибо! Желаем успехов в разработке :)
Мы воспроизводили у себя при прямом подключении через api, без системного промпта. Ключевое здесь, что подключиться надо к версии доступной именно в Azure, версия GPT 3,5 Turbo 0125. И мы не обвиняем компании в использовании данных через api, эту гипотезу мы как раз отбрасываем. Сейчас кажется, что модель просто из-за своей архитектуры научившись на большом российском датасете узнала про существование Just AI, и т. к. названия схожие, стала путать нас иногда с Open AI. При этом, видимо, дополнительного alignment по ответу на этот вопрос на русском не было.
Разработчик бота подключал модель GPT 3,5 Turbo последней версии, не нашу модель. А дальше мы уже сами воспроизводили ситуацию, напрямую работая также с GPT 3,5 Turbo
Мы работаем через API, память моделей не используем. К тому же, как видите, модель отвечает и про других создателей. В наших диалогах с ней точно про них ничего не было.