Мальчик способный, но ленивый: история создания AI-агента для пресейл-оценки

На связи Георгий, аналитик SoftMediaLab. В этот раз хочу поделиться опытом создания ИИ-агента для оценки на пресейле. Оценка кастомных IT-проектов — процесс долгий, дорогой и трудозатратный. Он требует участия технических специалистов, но при этом сам пресейл — этап некоммерческий. Для компаний, где каждый проект уникален, точная и быстрая оценка особенно важна. Но здесь возникает парадокс: самые компетентные эксперты — разработчики и технические специалисты — далеко не лучшие участники пресейла. Во-первых, они перегружены проектной работой. Во-вторых, это все-таки разработчики. Многим из них просто не комфортно, это не их среда. Боли разработчиков В итоге компании сталкиваются с ситуацией, когда качественная оценка жизненно необходима, но процесс построен так, что участие нужных людей стоит слишком дорого, а заводить пресейл инженера только под эти цели еще дороже. Именно из этой проблемы родилась идея создать AI-инструмент, который облегчит командную работу на этапе пресейла и позволит делать оценки проще и предсказуемее. Инструмент вырос из желания упростить участие разработчиков и ускорить процесс. Это настоящая боль — выдернуть разраба из проекта, чтобы тот отключился от боевой задачи и посмотрел на какой-то запрос, сформулировал как может свои вопросы, эти вопросы потом могут быть не согласованы с командой, и что самое больное — всё это бесплатно! Вторая настоящая боль — это сами формулировки вопросов. Многие компании проводят отдельные мастер классы и тренинги для сотрудников на тему того, как общаться с клиентами. Далеко не всем дано иметь талант ловко выуживать из клиента всю необходимую информацию. А еще клиент может и сам не знать, чего он хочет. Поэтому вопросы к заказчику на этапе пресейла оказались главным фокусом будущего инструмента. В системной инструкции (промпте агента) этому уделен целый блок правил. И это не только «Задавай вопросы вежливо и на Вы». Но обо всем по порядку. Забегая вперед, скажу, что итоговый инструмент благодаря принципу human-in-loop эволюционировал из «задавателя вежливых вопросов» в агента-оценщика, который на выходе формирует уточненную оценку, с разбивкой по ролям и этапам. В основу агента был положен встроенный в AI принцип вероятности. «Прежде чем ответить, оцени неопределённость своего ответа. Если она больше 0.1, задай мне уточняющие вопросы, пока она не станет 0.1 или ниже». Этот инсерт я подцепил на реддите и пользуюсь ей в качестве приписки почти ко всем запросам. Такой подход позволяет сделать ответы более осмысленными и контекстными, а не «Я ему про Фому, а он мне про Ерёму». Если неопределённость ответа выше 0.1, ИИ задает вполне годные уточняющие вопросы о задаче, которые ему непонятны. Создание ИИ-агента: что было на старте Требования, которые были сформулированы к вопросам еще до начала разработки ИИ-ассистента: Каждый вопрос содержит наиболее предпочтительный вариант ответа (а лучше три возможных варианта, как в викторине); Имеет прямое влияние на будущую оценку; Одинаково понимается: Всеми участниками внутри команды разработки т.е. вопрос без подтекста; Всеми участниками команды заказчика, т.е. понятен, прост и ответ на него желательно дать односложный (да/нет)). Нельзя задавать вопросы до бесконечности: количество вопросов ограничено, количество итераций - тоже. Сначала мы создали прототип, пригодный к применению, и в дальнейшем улучшали его. Что было на первой стадии эволюции: Самое простое и понятное: работа в цикле «Вопрос – Ответ – Оценка»; К оценке можно приступать после снижения внутренней неопределенности ниже 0.1 (для удобства лучше заменить ее на уверенность выше 90%); Если после трех итераций оценка не достигла уверенности в 90%, выдавать оценку с той уверенностью, как есть, и выписывать все наиболее влияющие на оценку факторы; Каждая итерация вопросов должна повышать уверенность и сужать диапазон оценки. Данные для ассистента Материалы от заказчика, подаваемые на вход, должны представлять из себя минимально структурированные требования (лучше всего, конечно, ТЗ). Существует минимальный набор данных, из которых можно оценить хотя бы что-то. Так, например, транскрибация и саммари первичного разговора с заказчиком, находится ниже этого самого минимального порога. Потому что относительно разговора между людьми контекст теряется дважды, оставляя пространство для фантазии и неопределенности: на этапе саммари и на этапе АI-анализа. Поэтому лучше смотреть запись встречи целиком живому человеку. TL: DR Прежде, чем проскочить все неинтересные эпизоды, важно дать их краткое содержание. То есть, прежде чем получить готовый инструмент, AI-тренер сидит и долго гоняет агента относительно эталонных вопросов и оценки. Ему нужно понимать, какой результат ожидается в конце. Просто отлично, когда есть анти-пример, из которого можно понять, как делать не надо (какие вопросы заданы плохо и как они привели к ошибочной оценке), но в нашем случае это информация только для тренера, а не для агента. Итак, что агент умеет в его текущем состоянии. Практически о каждой из способностей более подробно будет написано в блоке «Принципы»: после анализа первичных данных формируется три варианта оценки различающихся по степени покрытия требований, оценке и соответственно рискам: а) агрессивный – вариант наиболее смелый, в нем агент выделяет только главный функционал, отбрасывая бантики. Такой подход наиболее пригоден для создания МВП. б) сбалансированный – полное покрытие требований. в) консервативный – для растущих проектов, вариант превосходит ожидания. после анализа первичных данных агент умеет строить набросок CJM и уточнять бизнес-модель; делать допущения (исходя из эвристик) для составления первичной оценки и предлагать оптимизацию; формулировать вопросы к заказчику по требуемым принципам, с вариантами оценки и вилкой влияния каждого ответа на оценку в часах; выделять факторы, наиболее критично влияющие на оценку (в том числе сопоставлять сроки и оценку, если первая указана в первичных данных); определять риски и предлагать действия по их минимизации (задавать вопросы заказчику для их минимизации); формулировать вопросы для команды по тем же принципам что и к заказчику; формировать ресурсный план по ролям проекта, с основными эпиками по каждой роли. Принципы В этом блоке речь пойдет о принципах, которыми руководствуется ИИ-агент при составлении оценки и о принципах, которые использовал я, когда его готовил. А его без вводимых ограничений скорее можно назвать беспринципным. Принципы работы 1) Принцип human-in-the-loop Мы взяли за эталон уже реализованный проект с точной оценкой и старались попасть в него. Так же и оценивали вопросы, сравнивания их с вопросами, которые задавали аналитики на этапе пресейла 2) Использование эталонов Словарь, справочник со сводом типовых рисков и коэффициентов – один из наиболее важных и, соответственно наиболее сложных документов. В нем для каждого типа проектов указаны возможные риски, их влияние на проект и действия по минимизации. В случае отсутствия таких знаний у агента может случиться примерно следующее: В проекте по CV аналитике чего угодно никто не оценит риск того, что данные с камеры будут иметь низкое разрешение и работы относительно оценки не то, чтобы вырастут вдвое, а просто будут невозможны. Справочник стандартных инструментов компании и шаблон оценки – второй из наиболее важных и сложных документов в котором содержатся стандартные оценки и типовые инструменты. Документ, в котором содержится ваш стандартный, принятый в компании пайплан оценки (через экраны, интеграции и прочее), обязательно с цифрами. В случае отсутствия таких данных у агента он будет давать оценки относительно…относительно себя, пожалуй. А какой у него скилл? Запомните, дети, он беспринципный, может все. Там, где здравомыслящий человек, например, решил бы задачу интеграцией CRM из коробки, беспринципный агент предложит написать CRM с нуля. И он оценивает это так, что он может это сделать. И, скорее всего, правда может. 3) Принцип определенности В своих вопросах и оценках агенту запрещено использовать такую неизмеримую категорию, как «легко, сложно, просто, трудно». Этот принцип напрямую связан с предыдущим, так как, то, что кажется ИИ-агенту простым, на самом деле может таким не оказаться. Принципы агента Ему плевать на бизнес-контекст. Поэтому в системной инструкции появился блок 0 с уточнением бизнес-контекста. Прежде чем вообще куда-то идти, нужно понять, в какой стороне оно находится. Вам может показаться это странным, но в реальной жизни весь бизнес-контекст менеджер держит в голове и редко перекладывает это на бумагу. То есть, понимание того, какова стратегическая цель, модель распространения, монетизации, полный спектр применения, не фигурирует в техническом задании на разработку. Или под другим углом: сейчас мы проектируем MVP, но если MVP будет успешным, то продукт будет коммерческим, а это значит, что на этапе прототипа важно заложить применение инструментов, которые будет легко масштабировать. В противном случае, продуктовый подход покинул чат, потому что вы построили, выкинули и стали строить заново. Ему плевать на все промежуточные результаты. Строго говоря, все это буквы в определенном порядке. Если конечной целью проекта, например, является формирование документа с коммерческим предложением, то, по мнению агента, мы в конце будем формировать какой-то документ с названием «Коммерческое предложение». Его вообще не парит, что будет в документе, откуда там будут данные, насколько сложным будет этот документ. Поэтому в системной инструкции появился блок с CJM. Для корректной оценки агент должен понимать (равно как и разработчик в будущем), какие шаги и промежуточные результаты должны появится и каков результат итоговый. Но если смотреть карту слева направо, то человек этот самый контекст собирает на всех этапах: таков принцип CJM. Например: мы получили данные по цене, по клиенту, еще что то, и эти данные легли в основу КП. В случае с агентом чтение CJM, по нашему мнению, должно происходить справа налево. Например: в проекте необходимо сформировать КП. Что для этого нужно? Данные клиента, цена, еще что-то. А где я это возьму? И так до источника. В случае же, если агент будет читать построенную карту как человек, то есть слева направо, то ему плевать, что в КП нет данных о цене. Ему плевать, какой ответ он вам даст в итоге. Агент не несет ответственности за выданную оценку. Мы все сталкивались с этими галлюцинациями, типа «рецепт свиных крылышек». Это потому, что ИИ важно дать вам ответ. Он будет лепить эту фантазию с полной уверенностью до последнего момента. Разве что сейчас, с приходом размышляющих моделей, ИИ научились признавать свою вину. Но ведь пользователю от этого не легче. И здесь очень сильно помогает принцип оценки неопределенности. Именно он заставляет агента размышлять самокритично. Сквозь тот же принцип получилось заставить агента говорить честно: если в шаблоне оценки (справочнике) такой тип проектов и решений отсутствует, то агент как бы не знает, что делать и предупреждает: эту оценку я сделал сам, а не по шаблону. Самое интересное — про сроки Один из самых интересных моментов: уточнение сроков. Для людей это не комфортный вопрос. Не комфортный как для команды исполнителей, так и для команды заказчика. Первые бояться спугнуть заказчика долгим сроком. Вторым нужно было еще вчера. Агент умеет уже на этапе первичной оценки, заявить: «Ваши сроки маловаты, товарищ заказчик, вот наш расклад (три варианта) и туда не влезет никакая реализация». Вызовы и выводы Мальчик, способный, но ленивый. То есть, текущий уровень эффективности инструмента показывает, что его потенциал не реализован полностью. Например, одинаково оценивается значимость по админке и пользовательскому интерфейсу. Не может допустить то, что легко узнается по открытым источникам, например потенциальное количество пользователей. Такой ИИ-агент еще не является полноценной заменой человеку на этапе пресейла: для тяжеловесных проектов, требующих точной оценки “копеечка в копеечку”, такой инструмент пока не подходит. Но как платформа для быстрого старта - вполне себе годится. Как минимум, снимает "страх белого листа" и вопросы “с чего начать”. Несмотря на необходимость дополнительной валидации и дополнения генерируемых вопросов, процесс работы с инструментом значительно быстрее, чем создание оценки с нуля. Уровень доверия к инструменту требует осторожного подхода, так как полного доверия к генерируемым результатам пока быть не может. Впрочем, это соответствует общей практике работы с ИИ-системами. Этим примером я хотел показать опыт использования LLM для этой задачи и ее потенциал создания аналогичного решения на базе материалов других компаний и бизнес-направлений.