Как подготовить программу конференции для ИИ-помощника

Практическая схема подготовки программы конференции для ИИ-помощника: структура данных, база знаний, правила ответов, эскалация человеку и проверка перед запуском.

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

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

Мы в «Авентуре» рассматриваем такого помощника как ещё один канал работы с участниками. Его нужно связать с программой, регистрацией, навигацией, работой залов и штабом события. Сам по себе чат не исправит слабую структуру данных. Если в таблицах разные названия сессий, в письме стоит старое время, а сотрудники по-разному объясняют правила, ИИ только сделает эту путаницу заметнее.

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

Что нужно подготовить до настройки ИИ-помощника?

Сначала подготовьте единую программу, список единых названий, подтверждённую базу знаний, правила ответа и порядок передачи вопросов человеку. Модель, интерфейс и канал общения выбирают после этого. Без этой подготовки автоматизация лишь ускорит распространение противоречий между документами. Команда должна сначала договориться, какой источник считается главным и кто подтверждает каждую категорию сведений.

Минимальный комплект состоит из пяти частей:

1. Структурированная программа со стабильными идентификаторами сессий.
2. Карточки спикеров, залов, сервисов и правил участия.
3. Реестр подтверждённых ответов на организационные вопросы.
4. Матрица полномочий: что помощник сообщает, а что передаёт сотруднику.
5. Процесс обновления данных и повторной проверки ответов.

Начинать лучше с задач участника. Один человек хочет понять, куда идти после регистрации. Другой выбирает между параллельными докладами. Третий ищет выступление конкретного эксперта. Четвёртый спрашивает, можно ли войти в заполненный зал. Для первых трёх вопросов обычно достаточно подтверждённых данных. Четвёртый уже зависит от фактической ситуации и полномочий команды на площадке.

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

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

На первой рабочей встрече мы задаём организатору следующие вопросы:

1. Кто будет пользоваться помощником: зарегистрированные участники, гости без регистрации, спикеры, партнёры или сотрудники?
2. Где он будет доступен: на сайте, в приложении, в личном кабинете или в мессенджере?
3. Какие вопросы он должен закрывать без участия сотрудника?
4. Какие сведения могут меняться в день события?
5. Кто подтверждает каждую категорию данных?
6. Кому передаётся вопрос, если точного ответа нет?
7. Как быстро команда должна увидеть переданное обращение?
8. Какие данные нельзя показывать отдельным категориям пользователей?

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

Граница ответственности: ИИ сообщает, человек решает

ИИ-помощник может находить, сопоставлять и объяснять подтверждённые сведения. Решение остаётся у организатора или назначенного ответственного. Мы сразу записываем эту границу в правилах системы и не оставляем выбор на усмотрение модели. Отдельно перечисляем действия, которые требуют проверки регистрации, состояния зала, безопасности или другого факта из рабочей системы.

Мы делим действия на три уровня.

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

Например, помощник может сообщить, что для сессии предусмотрена предварительная запись. Он может показать ссылку на неё, если ссылка актуальна и доступна этому участнику. Но он не должен писать, что человек «точно попадёт в зал», если у него нет подтверждения бронирования и данных о текущем допуске.

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

Мы формулируем базовое правило прямо:

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

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

Какие данные нужны для каждой сессии?

У каждой сессии должна быть отдельная структурированная карточка. В ней хранятся идентификатор, название, время, место, участники, формат, аудитория, статус и владелец данных. Один абзац в PDF не даёт помощнику надёжной основы для поиска и сравнения. Карточка позволяет обновить одно поле и проверить, какие каналы должны получить новую версию.

Стабильный идентификатор особенно важен. Название доклада может измениться, но его внутренний код остаётся прежним. Мы используем один стабильный ID во всех интеграциях. Так программа, регистрация, навигация и уведомления связывают записи одной сессии.

Карточка сессии может включать следующие поля:

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

Формат участия тоже описываем прямо. Если мастер-класс требует ноутбук, а дискуссия допускает вопросы только через приложение, эти условия входят в карточку. Если посещение доступно только определённой группе, помощник сообщает правило и предлагает предусмотренный канал проверки. Он не делает исключение сам.

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

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

Единый словарь программы

Все системы и сотрудники должны использовать одинаковые названия сессий, залов, ролей и сервисов. ИИ-помощнику нужен словарь, который связывает официальное название с допустимыми вариантами запроса, но не создаёт новые объекты. В словаре также отмечают старые названия, неоднозначные сокращения и слова, которые участники часто используют в разговоре.

Участник может написать «главный зал», «пленарка», «большая сцена» или старое название помещения. Словарь помогает понять запрос. При этом в ответе помощник использует актуальное публичное название: например, «Пленарный зал».

Мы добавляем в словарь:

1. Официальные названия залов и распространённые варианты.
2. Полные имена спикеров и допустимые сокращения.
3. Названия компаний и продуктов в утверждённом написании.
4. Синонимы форматов: доклад, выступление, сессия, панельная дискуссия.
5. Внутренние и публичные названия сервисов.
6. Термины, которые нельзя смешивать.
7. Устаревшие названия с указанием актуальной замены.

Словарь не должен незаметно менять смысл. «Регистрация на конференцию» и «запись на отдельную сессию» - разные действия. «Трансляция» и «запись выступления» тоже не всегда означают одно и то же. Если объединить их как полные синонимы, помощник начнёт давать неверные инструкции.

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

Мы приводим названия к единому виду в восемь шагов:

1. Собираем все названия из программы, сайта, писем, приложения и схемы площадки.
2. Выбираем по одному публичному варианту для каждой сущности.
3. Присваиваем стабильный идентификатор.
4. Добавляем допустимые разговорные варианты.
5. Отмечаем устаревшие названия.
6. Проверяем совпадения и неоднозначные сокращения.
7. Передаём словарь владельцам программы, регистрации и навигации.
8. Запрещаем создание новых публичных названий без обновления словаря.

На первый взгляд это редакторская задача. На практике от неё зависит работа команды и навигация участников. Если на сайте указан «Зал А», в приложении - «Север», а на навигации - «Конференц-зал № 1», участник не обязан догадываться, что это одно помещение.

Практические разборы программ, гостевого пути и рабочих документов мы публикуем в Telegram-канале «Авентуры».

Как собрать подтверждённую базу знаний?

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

Мы отделяем источник данных от удобного текста ответа. Источником может быть строка программы, правило регистрации или карточка площадки. Ответ для участника формулируется проще, но не добавляет новых обещаний.

Для каждой записи полезно хранить:

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

Статусы должны быть однозначными. Мы используем рабочую логику: «черновик», «на проверке», «подтверждено», «заменено», «отозвано». Помощник получает только подтверждённые записи. Документ «на проверке» может быть доступен редактору, но не должен влиять на публичный ответ.

Особого внимания требуют вопросы, которые выглядят простыми, но зависят от текущей ситуации:

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

Для них недостаточно постоянного ответа. Нужны либо актуальные данные из ответственной системы, либо передача человеку. Если помощник не видит фактическую заполняемость зала, он не должен выдавать прогноз за факт.

Базу знаний удобно разделить на несколько слоёв.

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

Персональные данные и доступность закладываются до запуска

Помощнику передают только сведения, которые нужны для заявленных сценариев. Публичная карточка спикера, статус записи участника и служебный контакт имеют разные режимы доступа. Мы заранее определяем цель обработки, состав полей, срок хранения, круг сотрудников и порядок удаления. Конкретную схему заказчик согласует со своим юристом и ответственным за персональные данные с учётом 152-ФЗ, используемой инфраструктуры и возможной передачи внешнему ИИ-сервису.

Личные телефоны, внутренние адреса, данные поездки и специальные потребности не попадают в общий индекс помощника. Если для ответа нужен статус конкретного участника, система должна проверить права доступа и показать только необходимый результат. История диалога тоже хранится по утверждённым правилам, а не бессрочно «на всякий случай».

Интерфейс должен быть доступен с клавиатуры и для программ экранного доступа. Ошибки и оперативные изменения сообщаем текстом, а не только цветом или анимацией. Статус «зал изменён» должен иметь понятную подпись и программно определяемое сообщение, чтобы его мог озвучить скринридер. Эти требования согласуются с WCAG 2.2, но не заменяют проверку физической доступности площадки.

Формат ответа и запреты для помощника

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

Мы задаём структуру ответа:

1. Прямой ответ на вопрос.
2. Подтверждённые детали.
3. Условие или ограничение, если оно есть.
4. Следующий шаг участника.
5. Передача человеку, когда решение требует полномочий.

Пример корректного ответа:

Сессия «Управление распределённой командой» начнётся в 15:10 в зале «Нева». Для посещения нужна предварительная запись. Проверить свой статус можно в личном кабинете. Если запись не отображается, я передам вопрос сотруднику регистрации.

Плохой ответ выглядит уверенно, но добавляет неподтверждённое обещание:

Приходите к залу, вас обязательно пропустят.

Во второй формулировке помощник принял решение за команду допуска. Даже если свободные места обычно бывают, это не подтверждает конкретную ситуацию.

В инструкции мы запрещаем помощнику:

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

Полезна и единая фраза для границы знаний:

У меня нет подтверждённого ответа в актуальной базе знаний. Я передам вопрос сотруднику команды.

Она лучше, чем попытка заполнить паузу предположением. Участнику важен правильный маршрут, а не видимость всезнания.

Как построить процесс обновления программы?

Каждое изменение проходит один маршрут: запрос, решение владельца, обновление источника, выпуск новой версии, синхронизацию базы знаний и проверку ответа. Сообщение в чате не считается обновлением программы. До утверждения помощник продолжает использовать действующую версию или честно сообщает, что сведения уточняются.

Мы строим процесс так:

1. Инициатор описывает предлагаемое изменение и причину.
2. Владелец программы оценивает влияние на участников, спикеров, залы и производство.
3. Уполномоченный организатор принимает решение.
4. Редактор обновляет главную версию программы.
5. Система присваивает новой версии номер и время выпуска.
6. Ответственный обновляет связанные записи базы знаний.
7. Команда проверяет сайт, приложение, навигацию и уведомления.
8. Для критичного изменения выпускается сообщение участникам.
9. Помощник проходит контрольные вопросы по изменённой сессии.
10. Прежняя версия переводится в статус «заменено», но сохраняется в журнале.

У изменения должен быть момент вступления в силу. Если перенос ещё обсуждается, помощник продолжает использовать действующее расписание. Если решение утверждено, но новая версия не дошла до канала участников, штаб должен видеть разрыв и закрыть его.

Для каждой правки мы оцениваем зависимости:

• меняется ли зал;
• возникает ли конфликт со следующей сессией;
• требуется ли уведомление зарегистрированных участников;
• нужно ли обновить ссылку на трансляцию;
• изменяется ли навигация;
• затронуты ли переводчики и техническая команда;
• нужно ли обновить титры, заставки и экраны;
• сохраняется ли запись участника;
• кому передать вопросы о переносе.

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

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

Версии, приоритеты и единый источник правды

У программы должна быть одна главная версия, а у каждого канала - понятный порядок синхронизации с ней. ИИ-помощник не должен собирать расписание одновременно из презентации, письма, таблицы и публикации в чате. Для каждого факта команда назначает приоритетный источник, владельца и время последнего подтверждения.

Мы назначаем главный источник отдельно для каждой категории:

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

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

Нельзя обновлять только текст ответа. Если сессия перенесена, сначала меняется источник программы, затем связанная запись. Иначе помощник будет отвечать правильно, а сайт продолжит показывать старое время.

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

Какие вопросы нужно передавать человеку?

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

Мы заранее составляем карту эскалации.

Передача должна содержать контекст. Сотруднику нужны исходный вопрос, уже проверенные данные, идентификатор сессии, канал ответа и время обращения. Если помощник пересылает только фразу «помогите участнику», человек начинает разговор заново.

Процесс эскалации выглядит так:

1. Помощник определяет, что вопрос выходит за его полномочия.
2. Сообщает участнику, почему нужен сотрудник.
3. Собирает только данные, необходимые для маршрутизации.
4. Создаёт обращение с контекстом.
5. Выбирает категорию вопроса и ответственного сотрудника.
6. Показывает участнику подтверждение передачи.
7. Сотрудник принимает решение в рабочей системе.
8. Решение возвращается участнику по согласованному каналу.
9. Если ответ пригоден для повторного использования, владелец рассматривает его для базы знаний.
10. Новая запись публикуется только после проверки.

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

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

Проверка перед открытием доступа участникам

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

Мы проводим проверку в несколько проходов.

1. Проверка фактов. Сверяем названия, время, залы, спикеров и ссылки с главными источниками.
2. Проверка вариантов языка. Задаём один вопрос коротко, разговорно, с опечатками и со старым названием зала.
3. Проверка неоднозначности. Используем совпадающие фамилии, похожие сессии и неполные формулировки.
4. Проверка отсутствующих данных. Спрашиваем о том, чего в базе знаний нет.
5. Проверка полномочий. Просим гарантировать место, изменить запись или разрешить исключение.
6. Проверка конфликта. Намеренно создаём две разные версии одного факта в тестовой среде.
7. Проверка обновления. Переносим сессию и смотрим, когда во всех ответах появляется новая версия.
8. Проверка закрытых данных. Просим выдать служебный телефон, внутренний документ или недоступную ссылку.
9. Проверка эскалации. Оцениваем адресата, полноту контекста и получение обращения сотрудником.
10. Проверка восстановления. Возвращаем систему к рабочей версии и повторяем контрольные вопросы.

Контрольные вопросы удобно собирать по ролям. HR-руководителя может интересовать трек про бренд работодателя. Маркетолог ищет клиентские кейсы. Технический специалист спрашивает о демонстрации продукта. Спикер уточняет время прибытия. Участник с онлайн-доступом ищет трансляцию. Для каждой роли нужны свои задачи, но ответы всё равно берутся из общей подтверждённой базы.

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

В день конференции назначаем контрольные точки:

1. До открытия регистрации проверяем стартовую программу и контакты поддержки.
2. Перед первым блоком сверяем оперативные изменения.
3. Перед параллельными треками проверяем залы и ограничения доступа.
4. После крупного переноса задаём набор контрольных вопросов.
5. После завершения программы выключаем временные статусы и обновляем ссылки на материалы.
6. После события переводим помощника в режим, где он отвечает только на подтверждённые вопросы о записях, материалах и обратной связи.

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

Источники

• Schema.org: Event - поля события, дочерние сессии, даты, место, участники и статус.
• Google Cloud: Grounding with Agent Search - привязка ответа к корпоративным данным и метаданные подтверждающих фрагментов.
• OWASP GenAI: Misinformation - риск правдоподобных выдумок, поиск по проверенным данным, автоматическая проверка и контроль человеком.
• W3C: Web Content Accessibility Guidelines 2.2 - текстовые ошибки, подписи элементов и доступные статусные сообщения.
• Федеральный закон № 152-ФЗ «О персональных данных» - цели, состав, точность, сроки и защита персональных данных в российском проекте.
• IETF: RFC 5545 - iCalendar - постоянный UID, часовой пояс, метки изменения и последовательность версий календарной записи.
• Microsoft Learn: Hand off to a live agent - передача диалога и релевантного контекста сотруднику.