ДЕНЬ 02 [10 НОЯБРЯ]
Формулирование аналитической задачи для ИИ
Как превратить бизнес-вопрос в ясную и корректную инструкцию для ИИ
О чём поговорим сегодня?
Ответ ИИ во многом зависит от того, как поставлена задача. Сегодня разберём, из чего состоит хорошая постановка аналитической задачи и где в агенте задаются роль, данные, правила и формат ответа.
Эфир [14:00 МСК]
Реальный кейс российской компании: как ставят задачи ИИ и оценивают результат? Практика: как создать агента в Dora и составить шаблон аналитической задачи?
ССЫЛКА НА ЭФИР
Бизнес-кейс
> Артём Шаповал
Руководитель группы Службы Вице-Президента по Финансам, Службы Вице-Президента по Продажам и Маркетингу, АвтоВАЗ
[Как мы переформулируем запросы бизнеса для ИИ]
Задача в действии: от «оцифруйте сканы» к рабочему инструменту
Обычно, бизнес даёт нам вводные: какую задачу он хочет решить. Как правило, он не знаком с технологией и не представляет, как посчитать эффект. Он понимает только, что процесс работает не до конца правильно и его можно попробовать улучшить с помощью ИИ.

Таких запросов набралось много. Браться за всё сразу нельзя, нужно выбирать. Одним из первых критериев отбора задач была быстрая окупаемость: задачи, где ИИ позволяет сократить FTE (эквивалент штатных единиц), затраты, налоги и снизить брак. Сразу оговорюсь: многое ниже — мои наблюдения и ощущения от нашего опыта, а не методика.
Как мы ставим задачу: четыре шага
У нас есть отработанный и, по сути, банальный механизм. Мы собираем вместе технических специалистов и бизнес и очень внимательно выслушиваем задачу.

01 Внимательно выслушать, что именно нужно бизнесу.
02 Перевести задачу на технический язык вместе со специалистами.
03 Проработать оценку эффективности.
04 Запустить внутреннее согласование, чтобы нам акцептовали работу в этом направлении.

Собранные задачи мы пропускаем через самый простой анализ:
01 Можно ли это сделать с помощью ИИ.
02 Сколько денег и какой результат это принесёт. Насколько задача даст именно выгоду.
03 Есть ли вводные. Для любого ИИ очень важна база данных: документация, оцифрованный опыт в любом виде.

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

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

Дальше есть два пути:
>
Дообучить ИИ или отдать результат людям с возможностью исправить и внести изменения.
>
Поднять модели с судьями. Две модели делают вывод, третья решает, какой вывод правильнее.
Абсолютной методики, какой вариант выбрать, нет: в разных ситуациях лучше работают разные. Эффективность мы оцениваем по ряду факторов, начиная с того, сколько ресурсов вариант потребует сейчас и в будущем. Бывает, что модель с ИИ-судьёй работает лучше модели без судьи всего на сотые доли процента. Тогда усложнение не оправдано: этой разницей можно пренебречь.
Задача в действии: от «оцифруйте сканы» к рабочему инструменту
Одна из наших задач — чат-бот по технической документации. Им пользуются сотрудники, которые разрабатывают техническую документацию и приводят её к стандартам, например технический писатель.
>
Что просил бизнес. Перевести отсканированные документы, которые лежат картинками или PDF, в текстовый формат. По оценке бизнеса, вручную это заняло бы два-три года работы людей. Нас попросили найти способ сделать это проще, быстрее и дешевле.
>
Что мы сделали. Условие мы отработали, но пошли немного дальше и спросили: зачем вы это делаете? Среди причин было названо и то, что документацию нужно анализировать, принимая решения о введении и изменении стандартов. Тогда мы предложили экспресс-анализ того, как стандарты отличаются во времени: у бизнеса есть документация 80-х, 90-х, 2000-х годов и так далее. Мы написали простого бота. Он говорил, что в одном стандарте правильнее сделать так, в другом иначе, а в целом в нескольких стандартах допущены ошибки, из-за чего в следующем всё теперь плохо.
>
Когда мы показали результат заказчику, он испугался: инструмент вскрывал недочёты в стандартах, и это вызвало напряжение. Мы предложили другой вариант: сделать функцию сравнения стандартов инструментом только для тех, кто их разрабатывает, чтобы они сами понимали, стоит ли принимать решение об изменениях. А сам бот остаётся помощником, который подсказывает человеку, как писать правильнее, исходя из действующего стандарта. Технический писатель берёт абзац текста, говорит, как он его сформулировал, и бот предлагает исправления.
Исходная просьба описывает способ, а не цель. Вопрос «зачем» помогает найти задачу, которая даст больше.
В итоге, решая задачу «перевести сканы в текст», мы по сути решили задачу технического писателя. Проект окупился примерно за 12 рабочих дней эксплуатации, единственные затраты были на разработчиков.
Развитие: что ждёт в будущем
Сейчас у нас четыре направления: машинное зрение для контроля приборов, чат-бот по документации, разбор чертежей и нормоконтроль, бот поддержки в мессенджере.

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

По моему ощущению, заниматься этим сейчас рано: нужно время, чтобы все попробовали и модели накачались. Пока лучше давать ИИ как можно больше вводных, а уже потом добавлять обработку результатов.
Присоединяйтесь к чату в Telegram
В чате вы можете задавать вопросы по марафону, делиться открытиями и получать поддержку от участников сообщества и экспертов GlowByte
Практика
> Руслан Шарифуллин
Эксперт по GenBI, GlowByte
[Формулирование аналитической задачи для ИИ]
Ответ ИИ во многом зависит от того, как поставлена задача. Запрос «найди причины падения продаж» подталкивает модель назвать причину, даже если в данных ее нет. Сегодня разберем, из чего состоит хорошая постановка, и заглянем внутрь агента: где ему задают роль, данные, правила и формат ответа.
Практика: «Шаблон аналитической задачи для ИИ»
>
Выберите три типовых бизнес вопроса из своей работы. По каждому ответьте: часто ли его задают, есть ли данные, по которым ответ можно проверить, что будет в случае ошибки, есть ли там чувствительные данные, сколько времени вы сэкономите. Оставьте один вопрос, который будет описан максимально подробно.
>
Заполните шаблон:
- ситуация: что случилось и кто спрашивает;
- показатель и как он считается;
- период и срез;
- источник данных;
- что нужно на выходе: таблица, SQL, короткий вывод, гипотезы или список аномалий;
- что считать фактом, а что гипотезой;
- допущения;
- чего модели делать нельзя, например называть причины, которых нет в данных;
- формат ответа и обязательный раздел «Ограничения».
>
Запустите промпт на учебной таблице. Отметьте, где модель вышла за рамки, например объяснила падение без оснований.
>
Поправьте шаблон и сохраните как рабочую версию.
*
Сравните две постановки одного вопроса: «наивную» (как бы вы ее описали без условий) и по шаблону. Какие поля шаблона дали больше всего качества в резульате, а какие оказались лишними?
Александр Ларин
Эксперт BI-направления Glowbyte

Поделитесь своими результатами в чате марафона! Какая строка шаблона была для вас самой удачной? Какой самый неожиданный ответ от модели вы получили?

Вопросы дня
ВЫ:
Агент ходит в данные от имени конкретного пользователя или через общую сервисную учётку?
РУСЛАН:
Агенты Dora отправляют запрос к данным от имени того пользователя, который задал вопрос в чате. Поэтому два сотрудника, задавшие агенту один и тот же вопрос, могут получить разные ответы, если у них разные права на данные. Для аналитика это означает, что при расхождении цифр между коллегами сначала стоит сравнить их права доступа.
ВЫ:
Сохраняются ли ограничения доступа к строкам и столбцам?
РУСЛАН:
Да. Для пользователя, от имени которого работает агент, продолжают действовать ролевые модели и ограничения доступа: RLS (ограничения на уровне строк) и CLS (ограничения на уровне столбцов), а также доступность источников и наборов данных из FineBI. Если менеджер региона видит в дашборде только свой регион, агент в ответе на его вопрос тоже покажет только этот регион. Права не нужно настраивать отдельно для агента, они берутся из уже существующей модели доступа.
ВЫ:
Можно ли разрешить агенту только нужные таблицы и только чтение?
РУСЛАН:
Круг доступных агенту данных определяется теми источниками и наборами данных, которые доступны пользователю в FineBI. Значит, ограничить агента нужными таблицами можно теми же средствами, что и обычного пользователя: через права на наборы данных и источники. Рекомендуется для работы с агентами выдавать пользователям только те наборы данных, которые нужны для их задач, так как агент видит всё, что видит человек.

Ограничения доступа уже встроены в настройки Dora и по умолчанию применяются ко всем пользователям, работающим с агентами. Это принципиальное отличие от подхода, при котором модели просто сказано в тексте инструкции «не показывай данные по другим регионам»: такую инструкцию можно обойти формулировкой вопроса или она может сработать неточно.
Полезные ссылки
Статья GlowByte о том, что проверить в данных, прежде чем подключать ИИ-агента. Помогает понять, какие задачи в организации можно отдавать ИИ.
Открыть
Статья GlowByte о запуске пилота дата-агента. В ней есть шаблон брифа, то есть структура описания задачи для агента. Можно взять за основу при формулировке собственных запросов.
Открыть
СПАСИБО ЗА ВНИМАНИЕ!




И помните...
Нейросеть — не главный герой.
Главный герой — человек, который умеет работать с данными, ИИ и решениями.