Десять вопросов ниже проверяют не эрудицию исполнителя, а понимание того, от чего зависит результат. Задавать их следует до подписания договора, и содержательность ответа здесь важнее его конкретности: на часть вопросов правильный ответ звучит как «пока не знаю, нужно посмотреть ваши данные», и именно он говорит о профессионализме больше, чем уверенная цифра. Технических знаний, чтобы оценить ответы, не требуется.
1. Что вы сделаете в первую очередь, до начала разработки?
Зачем спрашивать. Ответ показывает, есть ли у исполнителя этап проверки или он готов сразу писать код.
Хороший ответ: посмотрим реальные данные и проверим на них достижимость нужного качества, посчитаем стоимость эксплуатации, после этого будет ясно, стоит ли делать.
Плохой ответ: сразу приступим к разработке, там по ходу разберёмся. Это не расторопность, а перенос риска на вас: если качества не получится, потрачен будет ваш бюджет. Подробнее — «PoC в ИИ-проекте».
2. Как вы поймёте, что решение отвечает правильно?
Зачем спрашивать. Проверяет наличие измеримого критерия вместо демонстрации.
Хороший ответ: вы составите выборку реальных случаев, ваш эксперт подготовит эталонные ответы, замерим долю совпадений и согласуем порог до начала работ.
Плохой ответ: покажем на демонстрации, сами увидите. Демонстрация всегда проходит на удобных примерах. Что фиксировать вместо перечня функций — «Нужно ли ТЗ для ИИ-проекта».
3. Что вы будете делать, если наши документы противоречат друг другу?
Зачем спрашивать. Противоречия есть почти всегда, и вопрос проверяет, понимает ли исполнитель границу своей ответственности.
Хороший ответ: найдём противоречия и вынесем вам список; решение о том, какая редакция действует, принимаете вы — технически выбрать правильный вариант невозможно.
Плохой ответ: система разберётся сама, современные модели это умеют. Не умеют: модель видит два похожих фрагмента и берёт тот, что ближе к формулировке вопроса. См. «Готовность данных к внедрению ИИ».
4. Сколько будет стоить эксплуатация при нашем объёме?
Зачем спрашивать. Проверяет, учитывает ли исполнитель переменную стоимость решения.
Хороший ответ: точную цифру дадим после прототипа, когда замерим размер контекста и ответа; складывается она из того-то, при вашем объёме порядок такой-то.
Плохой ответ: это копейки, не считали. Классический сценарий провала — решение технически исправно и экономически бессмысленно, потому что счёт сопоставим с зарплатой сотрудника, которого оно разгружало. См. «Сколько стоит эксплуатация ИИ-решения».
5. Что система будет делать, когда не знает ответа?
Зачем спрашивать. Самый показательный вопрос из десяти. Хороший исполнитель поднимает эту тему сам.
Хороший ответ: при недостаточной уверенности откажется отвечать и передаст человеку; порог настраивается, поведение при отказе проектируется отдельно.
Плохой ответ: ответит по смыслу, она же умная. Это описание уверенного вымысла — самой опасной категории ошибок, потому что она не заметна. См. «Почему нейросеть выдумывает ответы».
6. В каком случае вы порекомендуете нам не делать этот проект?
Зачем спрашивать. Проверяет способность отказаться от заказа — самый редкий и самый ценный признак.
Хороший ответ: если на проверке выяснится, что в ваших документах нет однозначных ответов; если стоимость эксплуатации превысит экономию; если цена ошибки высока, а проверять результат некому.
Плохой ответ: мы беремся за любые задачи, всё решаемо. Отсутствие условий отказа означает, что исполнитель возьмётся и за заведомо провальный проект.
7. Кому будут принадлежать база знаний, промпты и настройки?
Зачем спрашивать. Это актив, создаваемый в проекте, и он нередко ценнее кода: собрать корпус заново дороже, чем переписать интеграцию.
Хороший ответ: всё, что создано в проекте, принадлежит вам; передаём с документацией.
Плохой ответ: уклончивый или «это наша методология». Означает, что при смене исполнителя работу придётся начинать заново.
8. Что произойдёт, когда используемая модель будет снята с поддержки?
Зачем спрашивать. Проверяет, думает ли исполнитель дальше момента сдачи работ.
Хороший ответ: архитектура допускает замену модели; при миграции перепроверим качество на той же выборке; условия и стоимость таких работ зафиксируем в договоре.
Плохой ответ: об этом подумаем, когда случится. Случится обязательно, и обсуждать это выгоднее до подписания. См. «Сопровождение ИИ-решений».
9. Что входит в сопровождение и сколько оно стоит?
Зачем спрашивать. Решение без сопровождения деградирует незаметно: продолжает отвечать уверенно, но всё чаще неверно.
Хороший ответ: перечень работ с периодичностью, разграничение того, что делаем мы и что остаётся на вашей стороне, стоимость.
Плохой ответ: сдадим и всё будет работать. Это либо отсутствие опыта эксплуатации, либо умолчание.
10. Что потребуется от нас и сколько времени это займёт?
Зачем спрашивать. Проверяет, понимает ли исполнитель, что часть работы нельзя выполнить за заказчика.
Хороший ответ: нужен владелец процесса для решений по ходу и эксперт для эталонных ответов и разбора спорных случаев; время эксперта — основной дефицитный ресурс, его стоит запланировать заранее.
Плохой ответ: от вас ничего не нужно, мы всё сделаем сами. Ответ, который приятно слышать и который гарантирует проблемы: определить, какой ответ правильный, может только заказчик. См. «Кто ведёт ИИ-проект внутри компании».
Как оценивать ответы в целом
| Признак | О чём говорит |
|---|---|
| Задаёт встречные вопросы о процессе и объёме | Решает вашу задачу, а не продаёт продукт |
| Просит показать реальные данные | Понимает, что качество определяется корпусом |
| Отказывается называть точность до проверки | Профессиональная осторожность |
| Сам поднимает темы расходов и сопровождения | Есть опыт реальной эксплуатации |
| Объясняет без терминов | Понимает механику |
| Называет условия отказа от проекта | Не возьмётся за заведомо провальное |
| Обещает точность на первой встрече | Продаёт ожидание |
| Говорит о технологиях, а не о вашем процессе | Опыта внедрения мало |
Общий принцип: тревожить должна не осторожность в ответах, а уверенность там, где её неоткуда взять. Достижимая точность — свойство ваших данных, и человек, называющий её до знакомства с ними, либо не понимает этого, либо понимает и всё равно называет.
Частые вопросы
Какой вопрос из десяти самый важный?
Шестой — в каком случае исполнитель порекомендует не делать проект. Готовность назвать условия отказа означает, что человек понимает границы применимости технологии и не возьмётся за заведомо провальную задачу ради контракта. Близко к нему пятый вопрос — о поведении системы при неуверенности: хороший исполнитель поднимает эту тему сам, не дожидаясь вопроса.
Что делать, если подрядчик отказывается называть точность заранее?
Считать это хорошим признаком, если отказ сопровождается предложением проверить достижимость на ваших данных отдельным этапом. Точность определяется состоянием ваших материалов, а не квалификацией исполнителя, поэтому названная до проверки цифра ничем не обеспечена. Настораживать должен обратный случай — гарантия конкретного процента на первой встрече.
Нужно ли задавать все десять вопросов?
Полезно все, но если времени мало, достаточно четырёх: что сделаете до разработки, как поймёте, что решение отвечает правильно, сколько будет стоить эксплуатация и в каком случае порекомендуете не делать проект. Ответы на них разделяют исполнителей отчётливее остальных и не требуют технических знаний для оценки.
Как сравнивать предложения, если цены различаются в разы?
Не по итоговой сумме, а по составу работ: что входит в приведение данных в порядок, что является предметом приёмки и что происходит после запуска. Дешёвое предложение обычно исходит из того, что данные готовы и работа сдаётся по факту работоспособности; дорогое включает проверку, подготовку корпуса и сопровождение. Обе цены могут быть честными — они описывают разную работу. См. «Структура затрат на внедрение ИИ».
Что делать, если договор уже подписан, а ответы настораживают?
Не расторгать, а изменить структуру работ: выделить проверку достижимости в отдельный этап с правом не продолжать и зафиксировать критерий приёмки до начала разработки. Это почти ничего не стоит относительно проекта и снимает основной риск — обнаружить неработоспособность после того, как бюджет израсходован. Отказ исполнителя от такой схемы сам по себе информативен.
Что дальше
Как в целом выбирать исполнителя и какие типы подрядчиков бывают — «Как выбрать специалиста по ИИ». Как оформить договорённости, если классическое ТЗ не работает, — «Нужно ли ТЗ для ИИ-проекта». Какие ошибки чаще всего допускают заказчики — «12 ошибок при внедрении ИИ». Полная картина — в опорной статье «Внедрение ИИ в бизнес».
Если предпочитаете исполнителя, который начинает с проверки достижимости, а не с обещаний, — это подход к разработке и внедрению ИИ; первый шаг — аудит процессов.