ИИ для тендеров: как собрать проверочную выборку ТЗ

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

Определите единицу проверки и цену ошибки

Фраза «проверить качество ИИ» слишком широка. Разделите задачи: извлечь требование, найти характеристику товара, сопоставить их и привести подтверждение. Если объединить все в один балл, правильное извлечение нескольких простых чисел может скрыть опасный вывод о соответствии.

Для первого пилота задайте единицу: одна позиция ТЗ и одна конкретная конфигурация товара. Ответ должен содержать требование, значение товара, источник и вердикт по решающим параметрам. Общий вывод о закупке оценивают отдельно. Подходящий товар в одной строке не означает готовность исполнить весь контракт.

Определите допустимые ответы до запуска. Удобно различать «соответствует», «не соответствует» и «недостаточно данных». Последний ответ обязателен там, где подтверждение отсутствует. Нельзя считать его ошибкой лишь потому, что руководитель хочет от модели односложное решение.

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

Общий подход согласуется с рекомендациями NIST: документировать тестовые наборы, метрики, условия проверки и ограничения переноса результата на другие условия. Это добровольная методическая основа, а не российское требование к закупкам. Раздел Measure в AI RMF.

Соберите двадцать случаев с разными затруднениями

Сначала возьмите реальные задачи, которые отдел вправе использовать, и уберите лишние персональные данные и закрытую коммерческую информацию. Не удаляйте существенные единицы, примечания и связи таблиц. После обезличивания эксперт должен еще раз проверить, что ответ не изменился.

Предлагаемая структура набора условная. Шесть случаев содержат явное соответствие, четыре явное несоответствие. Еще четыре проверяют границы диапазонов, три отсутствие необходимых сведений и три сложное извлечение из таблиц либо сканов. Категории могут пересекаться; для учета назначьте каждому случаю основной тип сложности.

Не набирайте двадцать почти одинаковых строк из одного документа. Такой тест проверит знакомую верстку, но мало скажет о рабочем потоке. Добавьте разные типы документов, производителей и товарных характеристик. При этом не расширяйте пилот сразу на незнакомые отрасли, в которых никто не может подготовить эталон.

Сохраните пакет случая: идентификатор, исходное ТЗ, документы товара, полное обозначение конфигурации и версии файлов. Укажите, что именно разрешено использовать при ответе. Если одна система получает весь комплект, а другая только распознанный текст, вы сравниваете разные условия.

Сделайте отдельные учебные примеры для настройки инструкции. Контрольные двадцать после фиксации не используйте для многократной подгонки запроса. Иначе результат покажет запоминание ваших проверок. Нейтральное тестирование на скрытых данных и защита от смешивания обучающих и тестовых материалов также лежат в основе программы AITE NIST.

Подготовьте эталон до просмотра ответов

По каждому случаю эксперт заполняет карточку независимо от модели. В ней нужны решающее требование, допустимая интерпретация, характеристика конкретного товара, страницы подтверждения и правильный вердикт. Если сама документация неоднозначна, эталоном может быть «нужны разъяснения», а не произвольно выбранный вариант.

Привлеките второго специалиста для независимой разметки хотя бы спорных и критичных случаев. Ему не показывают первый ответ до собственного решения. Затем расхождения разбирают по первоисточникам и оформляют согласованную версию с причиной изменения.

Если специалисты не договорились, вынесите случай в отдельный список спорных. Не используйте его как однозначный экзаменационный вопрос. Такой результат полезен: он показывает, где бизнесу нужен регламент трактовки или запрос заказчику. Наказывать систему за несовпадение с неустойчивым человеческим мнением бессмысленно.

Эталон зафиксируйте до запуска. Добавьте дату и ответственного. Править его после просмотра можно только при обнаружении подтвержденной ошибки, сохраняя прежнюю версию и основание. Незаметная смена правильного ответа под понравившуюся модель разрушает проверку.

Проведите слепую оценку по одинаковому протоколу

Для каждого инструмента запишите версию, настройки, дату, инструкцию и доступный комплект документов. Если версия модели скрыта сервисом, так и укажите. Не придумывайте техническое описание, которого у вас нет. Для повторяемости важнее честно зафиксировать доступные условия.

Запускайте каждый случай отдельно, без подсказки правильного ответа. Не добавляйте уточнения только одному участнику сравнения. Если допускается диалог, заранее установите число и тип уточнений либо оценивайте диалог как отдельный сценарий. Ручная помощь сотрудника должна быть видна в протоколе.

Организатор присваивает ответам нейтральные обозначения А и Б и перемешивает порядок. Проверяющий видит документы, эталон и обезличенные ответы, но не название продукта. Полностью скрыть стиль системы удается не всегда, поэтому ограничение слепой оценки фиксируют отдельно.

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

В TenderScan исходный анализ запускает пользователь вручную. Для пилота сохраняйте результаты конкретных запусков и версии загруженного каталога. Не предполагайте, что сервис сам повторит проверку после замены файла. Повторный запуск должен быть частью зафиксированного протокола.

Разберите ошибки и примите ограниченное решение

Условный результат: из двадцати случаев в шестнадцати вердикт совпал с эталоном, в двух неверен, в двух система ответила «недостаточно данных». Простое число 80% еще не объясняет полезность инструмента. Нужно проверить, были ли эти два отказа правильными, насколько опасны два неверных решения и подтверждены ли шестнадцать совпадений источниками.

Если среди совпадений обнаружен выдуманный аргумент, отметьте его отдельно. Угаданное решение не означает надежного анализа. Если модель нашла нарушение, но сослалась на другую модификацию, сотрудник не сможет проверить и использовать такой результат без повторной работы.

Разложите причины: потеря текста при распознавании; неверное извлечение единицы; смешение моделей; ошибочная трактовка границы; отсутствующий источник; необоснованный итог. По одной ошибке может быть несколько признаков, но для исправления назначьте основную причину. Тогда следующий запуск покажет, что именно улучшилось.

Замерьте время человека: чтение ответа, открытие источников, исправление и решение. Быстрая генерация длинного текста иногда увеличивает проверку. Сравните с ручной работой на сопоставимых заданиях, учитывая опыт сотрудника. Не переносите экономию на весь отдел из одного удачного примера.

Полезный итог пилота формулируют по задачам: разрешить черновое извлечение; ограничить сопоставление определенными товарными группами; сохранить обязательную проверку критических требований; повторить оценку на новых документах. Рекомендации по ежедневной верификации дополняет статья о проверке ответов нейросети. Здесь же решается вопрос, насколько воспроизводим именно ваш испытательный набор.

Перед следующим этапом создайте новые контрольные случаи с теми же типами сложности. Старые оставьте для проверки исправленных ошибок. Отдельно сохраните случаи, на которых оба эксперта сначала расходились: они пригодятся для обучения сотрудников, но их нельзя выдавать за изначально однозначные задания. Двадцать задач помогают обнаружить проблемы и сформировать рабочую гипотезу, но не дают статистического доказательства безошибочной работы на всех закупках.

До сравнения результатов проверьте, что в комплект случайно не попали экспертные комментарии. Правильный ответ может сохраниться в имени файла, скрытом листе таблицы или примечании редактора. Организатор делает отдельную проверочную копию материалов и сверяет ее с исходником. Полезно поручить эту проверку коллеге, который не готовил задания: ему проще заметить незаметную автору подсказку.

FAQ

Обязательно ли брать ровно двадцать примеров?

Нет. Это удобный размер стартового учебного пилота. Для решения о внедрении учитывают разнообразие задач и последствия ошибок. Если значимые типы документов не представлены, увеличьте набор либо сузьте область вывода.

Считать ли ответ «недостаточно данных» провалом?

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

Можно ли после каждого прогона менять инструкцию?

На учебных примерах да. Если вы меняете инструкцию после просмотра контрольных ответов, этот набор уже участвует в настройке. Для независимой оценки подготовьте новые случаи и сохраните историю изменений.