Наталья Самсонова
Старший системный аналитик ГК Юзтех
Всем привет! Я — Наталья Самсонова, старший системный аналитик ГК Юзтех. В этой статье расскажу, как, на мой взгляд, ИИ изменит практику аналитика.
Аналитик – главный стейкхолдер логики проекта. Все участники команды — разработчики, тестировщики, дизайнер и даже менеджер — на любой стадии проекта идут с уточняющими вопросами именно к аналитикам. Чем более качественно отрабатывается аналитическая часть разработки, тем, с одной стороны, более спокойной является атмосфера в команде, и, с другой стороны, ниже риск возвратных действий в обеспечении ожиданий заказчика.
Зачастую аналитик раньше всех входит в проект (иногда еще на стадии пресейла) и позже всех выходит из проекта, чтобы обеспечить стабильную эксплуатацию системы на территории заказчика. Только аналитики глубоко погружены в специфику и потребности заказчика, а также способны транслировать бизнес-требования в задачи на разработку.
В наши дни активно набирает обороты искусственный интеллект (ИИ). На рынке заказного ПО преобладающий спрос на решения с ИИ-компонентами становится обычным явлением. В этой ситуации возникает вопрос готовности участников рынка исполнять современные требования заказчиков.
В статье рассмотрим основные изменения, которые ожидают в этой связи любую команду разработки. В частности, с позиции аналитиков, как обязательных участников любой стадии проекта.
Согласно SDLC создание системы ведется последовательно: анализ требований, проектирование, разработка, тестирование, развертывание и поддержка. К какой трансформации работы готовиться участникам на каждом из этапов?
Стадия аналитики традиционно предусматривает активную работу с бизнес-требованиями, их уточнение и обсуждение с заказчиком. Исключительно на этой основе формируется последовательно концепт, дизайн-проект и требования к архитектуре будущей системы. Здесь мы определяем верхнеуровневую модель данных, основную логику их обработки и последующее представление в UI.
Но что делать с данными, которые будет формировать, например, БЯМ (Большая языковая модель)? Как их встраивать в общую логику системы? А самое главное – какие будут данные и какого качества? На все эти вопросы должны быть найдены ответы уже на этом, первом этапе проекта.
Таким образом, границы аналитической стадии разработки расширяются, дополняя пакет бизнес-требований возможностями и ограничениями БЯМ, т.е. системными требованиями нового свойства.
Как правило, в команде ИИ есть «свои» аналитики (дата аналитики) или Data Scientist-ы, которые и обеспечивают аналитическую проработку сценариев будущего поведения модели.
Однако аналитику проекта важно детально знать границы работы модели, чтобы, с одной стороны, нивелировать возможные упущения БЯМ, а, с другой стороны, исключить автоматизацию дублирующих процессов.
Например, проектом предусматривается, что ИИ осуществляет проверку текста на предмет выявления каких-либо сущностей. Допустим, упоминания названий документов.
В этом случае нет необходимости выполнять требуемый поиск «традиционными» функциями, это сделает БЯМ. Однако нужно знать, на каких методах будет работать модель, выполняя такую задачу, какой заявляется уровень качества используемых методов. Это обеспечит аналитика информацией, необходимой для моделирования процессов по передаче данных от БЯМ к постобработке.
Таким образом, необходимо понимать как сильные, так и слабые стороны ИИ-компонента системы, обеспечивая ее целостность при поставке информации пользователям.
Выявленные ИИ-требования переходят на стадию проектирования системы. Уже самим фактом появления, и, соответственно, необходимостью проработки пакета требований нового свойства – возникают изменения в работе команды и на этой стадии.
Когда проектируется модель данных, то определяется их источник (или поставщик). Данные классифицируют на внешние (поступающие из внешних ИС или посредством ввода) и внутренние, которые создаются посредством вычислений самой системой. Иными словами, внутренние данные – это результат работы создаваемых автоматизированных функций. При этом, результат работы БЯМ также следует рассматривать как внутренние данные системы, которые подлежат последующей обработке.
Так, при проектировании функций системы возникают дополнительные условия и кейсы, которые ориентированы на специфику работы модели (с ее плюсами и минусами).
Предполагается, что к стадии разработки мы подходим с полной проектной документацией, которая содержит ответы на все вопросы разработчиков для старта программирования.
Вторым критерием качества проектирования может быть также неизменность архитектуры и логики системы в течение всего периода проекта, т.е. отсутствие противоречий и желания команды структурно переработать или иным образом изменить проект.
Стадия программирования, пожалуй, самая чувствительная к возможным логическим конфликтам. Именно на этом этапе потенциально проявляется несогласованность взаимодействия компонентов системы, особенно – на «специальном» наборе данных.
Поэтому аналитику нужно быть к этому готовым, а именно: хорошо знать и понимать логику работы БЯМ, какие «сюрпризы» она может создавать.
Как правило, используют два основных способа решения:
1. Если данные от модели можно формализовать (например, проверить по шаблону), то последующую обработку целесообразно полностью предусмотреть в описании соответствующих алгоритмов.
2. Если предполагается, что модель выдает данные различного не унифицируемого свойства, то «устранение неприятностей» перейдет на уровень пользователей. Для этого необходимо предусмотреть вывод в интерфейс предельно детализированной информации, на основании которой пользователь однозначно поймет, в какой части он может доверять результатам работы системы.
При этом, будем реалистами, на 100% результат работы LLM предсказать невозможно. Именно поэтому такая зона риска и требует особого внимания, которое может выражаться в подготовке «специальных» данных и учета специфики их обработки в описании постановок задач на разработку.
Постепенно мы подошли к стадии тестирования. Предполагается, что описанные особенности разработки ИИ-системы получат соответствующее продолжение в тест-кейсах. QA-инженеру при поддержке аналитика предстоит проработать «неопределенные» сценарии тестирования системы, т.е. сценарии, оценивающие устойчивость работы системы в целом при непредсказуемом поведении модели.
В представленном выше примере, если искомые названия документов – это последовательность символов, однозначно проверяемая маской, то тестирование будет ограничено перебором возможных комбинаций в заданных границах, с целью оценки качества алгоритмов постобработки. Также, можно «спрятать» допустимое значение во вложенном объекте проверяемого текста (например, в таблице, колонтитулах и т.д.), и проверить успешность поиска.
В ином случае, целесообразно предусмотреть в контрольном тексте цепочку символов, которую модель потенциально может принять за название документа. Затем оценивать полноту и доступность информации в UI. Будет ли пользователю понятно, что модель ошибочно приняла наши данные за целевое значение.
При последовательной организации работы на проекте к стадии тестирования команда уже понимает предельный уровень качества модели, который заведомо будет меньше 100% (независимо от проекта). В случае выхода за границы качества, на ранних этапах нами предусмотрены алгоритмы, которые ориентированы на обработку непрогнозируемых данных модели. В такой вероятностной системе координат предстоит планировать мероприятия по оценке качества разработанной ИИ-системы.
Заключительная стадия проекта – развертывание и обучение пользователей, которая осуществляется на территории заказчика. Здесь возникает значительный спектр новых разноплановых вопросов, ранее не возникавших в повестке обсуждений с заказчиками.
Например, особенности инфраструктуры и ее готовность к обеспечению существенных вычислительных ресурсов для корректной работы модели.
Другой пример: необходимость дообучения модели, потребность в котором объективно наступит после определенного периода эксплуатации системы.
Безусловно, эти и иные смежные вопросы не относятся к непосредственным задачам аналитика. Однако в эксплуатационную документацию на систему целесообразно включить порядок действий пользователей при возникновении подобных ситуаций.
Важным аспектом документации является описание ролей пользователей системы, которые выполняют обеспечивающие функции. Если ранее такие функции возлагались на Администратора системы (подразумеваем все категории администраторов), то для ИИ-систем рекомендуется дополнительно рассмотреть роль Инженера ИИ. В общем виде к его обязанностям относят дообучение модели в части, предусмотренной системой.
Описания операций по работе с промтами могут быть включены как в руководство администратора (если документ ориентирован на две категории пользователей), так и в состав отдельного документа – руководство Инженера ИИ. Все зависит от проекта и планов заказчика по его развитию. Однако и такие вопросы, которые решаются на финальной стадии проекта, целесообразно прорабатывать и обсуждать с заказчиком еще при старте.
Статья не претендует на полноту вопросов, которые диктует искусственный интеллект аналитикам. Но полагаю, что я осветила базовые аспекты и общие принципы необходимых изменений в работе. Ведь, как было отмечено в начале статьи, именно аналитик является для заказчика индикатором экспертности команды в сфере автоматизируемых процедур и регулятором соответствия ожидаемым результатам проекта.