Сравнивайте подрядчиков на одной операции
Допустим, вы получили два предложения по внедрению ИИ для вашей компании. В одном обещают помощника для всех сотрудников, в другом предлагают поиск по документам и черновик ответа менеджеру. Итоговые суммы рядом, но состав работ различается. Для заказчика это риск дополнительных расходов: после договора может понадобиться отдельно оплатить подключение документов, проверку ответов и поддержку, которую вы считали включённой.
Чтобы выбрать подрядчика по внедрению ИИ, дайте кандидатам одинаковую задачу, обезличенные входные примеры и описание ожидаемого результата. Сравните их план проверки, границы первой версии, работу с данными, передачу исходников и расходы после запуска. Ниже мы покажем, какие доказательства запросить и как превратить ответы в условия приёмки. Такая проверка поможет собственнику и руководителю закупки выбрать команду под свой процесс.
Короткий критерий выбора: кандидат может объяснить, как получит результат на ваших данных, как вы его проверите и как ваша команда продолжит работу после передачи. Для каждого пункта запросите конкретный документ, демонстрацию или контрольную операцию.
Авторская иллюстрация сравнения предложений: один набор исходных примеров, проверка результатов и комплект передачи. Изображение создано генеративной моделью.
Проверяйте кейс от входа до результата
Попросите подрядчика разобрать один проект: что поступает на вход, где лежит правильный ответ, что получает человек и что происходит при ошибке. Если вам нужен разработчик корпоративного RAG, особенно полезен проект с поиском по документам и правами сотрудников. RAG означает, что система сначала находит подходящие фрагменты базы знаний и использует их для подготовки ответа.
Для AI-агента, который создаёт задачи или меняет данные, смотрите также опыт интеграций и ограничения действий. Уточните личный вклад кандидата: он мог разрабатывать весь продукт, подключать отдельную функцию или только консультировать. Эти виды работы требуют разной команды.
В нашем приложении Epicure AI мы связали подбор рецептов, планирование меню и список покупок. Отдельный сценарий распознаёт блюдо по фотографии. Пользователь получает рецепт и действия для приготовления; состав блюда всё равно требует проверки. При выборе подрядчика такой разбор показывает, умеет ли команда довести AI-функцию до понятного пользовательского результата.
Epicure AI: входные продукты и результат подбора
В Epicure AI мы соединили выбор сценария и подбор рецепта по доступным ингредиентам.
Выбор операции. Пользователь выбирает подбор по продуктам или сканирование блюда.
Результат подбора. На экране рядом видны входные ингредиенты и предложенное блюдо.
Экраны Epicure AI показывают путь к рецепту. Для корпоративного поиска по документам отдельно проверяют качество источников, права доступа и ответы на вопросы сотрудников. Посмотреть кейс Epicure AI.
Связь рабочих систем тоже можно разобрать предметно. В «Бакаеве» мы настроили сервер синхронизации приложения, админ-панели и 1С: замена фотографии в админке отражается в 1С, заказ в приложении меняет остатки в админ-панели и 1С. Этот опыт помогает сформулировать вопросы к интеграционной части будущего AI-проекта: куда попадёт результат, кто его подтвердит и как сотрудник увидит ошибку. Подробности смотрите в кейсе «Бакаев».
Отправьте кандидатам одинаковый запрос
Выберите одну операцию с понятным началом и концом. Например, сотрудник получает вопрос о доставке, находит действующее правило и готовит ответ. Мы предлагаем начать с черновика, который человек проверяет и отправляет сам. Такая граница позволяет оценить полезность помощника до подключения автоматической отправки.
В запросе укажите источник истины: утверждённый регламент, карточку товара или запись в учётной системе. Назначьте сотрудника, который решает спорные случаи. Если в документах разные сроки доставки, подрядчик должен показать, как обнаружит противоречие и передаст вопрос ответственному.
- Вход: обезличенные примеры обращений, документов или операций, включая неудобные случаи.
- Результат: что сотрудник должен получить, в каком виде и с каким подтверждением источника.
- Границы: системы, доступные поля, разрешённые действия и операции, требующие согласования.
- Проверка: кто принимает результат, какие ошибки критичны, какие исправления допустимы.
- Расходы и передача: какие работы входят в предложение, что оплачивается регулярно и что остаётся у заказчика.
Попросите ответить по этим пунктам и перечислить допущения. Например, смета может предполагать готовые тексты документов, а у вас половина материалов хранится в сканах. Подготовка такого массива станет отдельной работой. Её лучше увидеть до сравнения итоговых сумм.
Пилот должен оставить проверяемый отчёт
Согласуйте набор для настройки и отдельные контрольные случаи для итоговой приёмки. Для каждого контрольного случая запишите вход, допустимое поведение и основание для оценки. На вопрос без достаточных данных правильным результатом может быть уточнение. При отсутствии правила нужен переход к сотруднику.
В корпоративном RAG разделите две проверки: нашла ли система нужный документ и верно ли ответила по нему. В документации Microsoft по оценке RAG качество поиска, опора ответа на контекст и полнота ответа рассматриваются отдельно. Это помогает понять причину ошибки: потерянный документ требует другой доработки, чем неверное изложение найденного правила.
После этапов выбора у заказчика остаются общий запрос, протокол проверки и комплект для запуска решения по инструкции.
Допустим, помощник нашёл старую редакцию правил и уверенно указал прежний срок доставки. В отчёте должны сохраниться вопрос, найденный фрагмент, редакция документа, ответ и решение проверяющего. По ним видно, где возникла ошибка. Запись только об общем проценте правильных ответов оставит эту причину скрытой.
Отдельно проверьте отсутствие доступа к чужим документам, попытку выполнить запрещённое действие, недоступный источник и повтор после сбоя. Внешний файл может содержать инструкцию, которая пытается изменить поведение модели. OWASP описывает этот риск и рекомендует ограничивать права приложения, подтверждать опасные действия человеком и проводить специальные проверки.
В примере с ответами о доставке отправка клиенту остаётся у сотрудника. Если позже добавляется автоматическая отправка или запись в CRM, для неё нужны отдельные проверки. Критическую ошибку нельзя скрывать в среднем показателе: согласуйте остановку затронутой операции, исправление и повторную приёмку. Подробный порядок оценки разобран в статье об AI-пилоте для бизнеса.
Таблица сравнения предложений
Заполняйте таблицу словами и ссылками на доказательства. Сначала отметьте обязательные условия вашей компании. Если кандидат пока не подтверждает работу с нужными данными или передачу результата, верните этот пункт на уточнение. Сумма баллов не должна скрыть невыполненное обязательное условие.
| Критерий | Что запросить | Как проверить |
|---|---|---|
| Схожий опыт | Разбор проекта и личный вклад команды | Пройти от входных данных до результата и исключения; сопоставить со своей операцией |
| Качество пилота | Тестовый набор, критерии, образец отчёта | Повторить контрольные случаи; увидеть ошибки, отказы, правки и версии настроек |
| Данные и действия | Схему передачи данных, права, сроки хранения копий и журналов | Проследить путь одного документа; испытать запрет доступа и записи |
| Состав команды | Ответственных за разработку, интеграции, проверку и поддержку; участие субподрядчиков | Разобрать техническое ограничение с исполнителем и согласовать порядок замены специалиста |
| Полные расходы | Разовые работы и регулярные расходы при согласованной нагрузке | Учесть подготовку данных, поиск, модель, повторы, ручную проверку, инфраструктуру и поддержку |
| Права и передача | Перечень исходников, настроек, доступов, лицензий и документации | Развернуть согласованную версию по инструкции в среде заказчика и повторить контрольный набор |
| Эксплуатация | Порядок реакции, восстановления, обновления и завершения поддержки | Разобрать сбой API, смену модели и восстановление из копии; назначить ответственного |
Пример развилки: один кандидат предлагает готовую платформу по подписке, второй — разработку отдельного модуля. У платформы проверяйте ограничения настройки, выгрузку данных и возможность переноса. У заказной разработки проверяйте комплект передачи и способность вашей команды его запустить. Сравнивайте стоимость полного рабочего маршрута за один период и при одинаковой нагрузке.
Исходники, права и запуск без автора
Фразу «передадим исходный код» раскройте в перечень поставки. Код приложения может зависеть от внешнего API, платной платформы, библиотеки или модели с отдельной лицензией. Запросите список таких зависимостей, условия использования, владельцев аккаунтов и возможность заменить поставщика. Получение архива само по себе ещё не показывает, что команда сможет продолжить работу.
Мы предлагаем включать в передачу хранилище исходного кода с согласованной версией (репозиторий), инструкции сборки и запуска, настройки поиска, шаблоны запросов к модели, описание интеграций и контрольный набор. Для RAG также нужны правила обновления документов и поискового индекса, если он используется. Пароли и ключи передают защищённым способом; в открытом репозитории им места нет.
Контроль передачи: сотрудник заказчика или новый исполнитель разворачивает версию по документации, подключает согласованные сервисы и повторяет тестовые операции. Результат сверяют с протоколом приёмки. Найденные пробелы в инструкции исправляют до закрытия этого этапа.
В договоре и приложениях согласуйте права на созданные части, ограничения сторонних компонентов, состав поставки и момент передачи. Уточните, какие ранее разработанные модули подрядчика входят в решение и на каких условиях ими можно пользоваться. Эти пункты лучше проверить с ответственным за договор до подписания, когда выбор поставщика ещё открыт.
Для эксплуатации разделите реакцию на обращение и восстановление работы. Запишите часы поддержки, способ связи, кто может остановить опасную операцию и какой ручной маршрут доступен сотруднику. Если меняется модель, документ или интеграция, согласуйте повторный прогон контрольных случаев и порядок возврата к предыдущей версии.
Как принять решение в России, Москве и Петербурге
Город влияет на встречи, доступ к закрытому контуру и организацию поддержки. Если компания в Москве или Санкт-Петербурге работает удалённо, запросите рабочие часы команды, формат демонстраций и порядок передачи материалов. Если нужны очные работы, проверьте, кто приедет, что входит в смету и как оформляется доступ на площадку. Для распределённой компании по России закрепите ответственных на стороне подразделений.
При обработке корпоративных данных попросите показать, куда уходит документ, какие внешние сервисы участвуют и какие копии сохраняются. Доступность API, возможность оплаты, место обработки и условия хранения проверяйте для выбранного поставщика до пилота. Для персональных и иных регулируемых данных согласуйте допустимый контур с ответственными за данные и безопасность до их передачи.
Название в рейтинге пригодится для поиска кандидатов. Финальное решение принимайте по доказательствам из таблицы: совпадает ли опыт с задачей, воспроизводится ли проверка, понятны ли расходы и передача. Если подрядчик обещает точность и экономию до знакомства с данными, попросите раскрыть основание расчёта и условия, при которых он действует.
После сравнения выберите команду для ограниченного пилота и оформите его как самостоятельный этап. На выходе должны быть результаты проверки, найденные ограничения, расходы и решение о продолжении. Мы в 13FOX предлагаем начать с такого разбора одной операции; состав работы описан на странице разработки ИИ-решений.
Что уточнить перед договором
Как выбрать студию AI-агентов по кейсам?
Попросите показать входные данные, разрешённые действия, результат сотруднику и поведение при сбое. Уточните личный вклад команды. Для агента с записью в рабочую систему отдельно проверяйте подтверждение действий, права и повтор после ошибки.
Как сравнить интеграторов, если сметы устроены по-разному?
Отправьте одинаковое описание одной операции и попросите разложить работы по данным, интеграциям, проверкам, передаче и поддержке. Сравнивайте разовые и регулярные расходы при одинаковой нагрузке и одинаковом результате.
Что требовать от разработчика корпоративного RAG?
Проверку поиска нужного документа и ответа по нему, соблюдение прав доступа, работу с редакциями и передачу вопроса человеку при отсутствии основания. В комплект передачи включите настройки поиска, обновление индекса и контрольные вопросы.
Достаточно ли передачи исходного кода?
Для продолжения работы также нужны инструкции запуска, настройки, доступы, перечень зависимостей и условия их использования. Проверьте передачу развёртыванием согласованной версии и повторением контрольных операций в среде заказчика.
Составим запрос на пилот вашей операции
Оставьте контакт для обсуждения. Подготовьте обезличенные входные примеры и ожидаемый результат одной операции; передать их можно после согласования способа обмена. Мы разберём источники, права и исключения, предложим план пилота, критерии проверки и состав расходов.
Результат первого разбора: понятные границы проверки и список данных, которые нужны для оценки работ.