ИИ-анализ тендеров: требования документации и вопросы специалисту

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

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

Чем разбор тендерного ТЗ отличается от поиска закупок

Поиск закупок отвечает на вопрос «какие процедуры подходят компании». Разбор тендерного ТЗ начинается позже: процедура уже выбрана, а у специалиста есть извещение, основное ТЗ, приложения и опубликованные изменения. Задача — превратить этот комплект в перечень требований с доказательствами и нерешёнными вопросами.

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

Граница процесса выглядит так:

1. Специалист выбирает процедуру и собирает документы.
2. Система извлекает пункты, таблицы и их местоположение.
3. Компания добавляет внутренние подтверждения.
4. Специалист разбирает противоречия и принимает решение.

Смежный этап — сравнение предложений поставщиков. Он решает другую задачу и не заменяет проверку требований выбранной закупки.

Как подготовить документы и версии

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

До смыслового анализа проверьте техническое извлечение. Сопоставьте число страниц с исходником, просмотрите несколько обычных и сложных страниц, проверьте заголовки, единицы измерения, переносы строк и объединённые ячейки. Для сканов отдельно оцените OCR: символы «0» и «О», десятичные разделители, знаки «≥» и «≤» легко меняют смысл требования.

Официальная документация Microsoft указывает, что облачная модель Azure Document Intelligence Layout v4.0 (версия API 2024-11-30 GA) извлекает текст, таблицы, отметки выбора и структуру документа. Это подтверждает возможность технического извлечения для перечисленных в документации форматов, но не доказывает полноту конкретного комплекта и не заменяет смысловую или юридическую проверку. В этой статье не заявляется запуск сервиса на реальных тендерных файлах.

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

Как извлечь требования с подтверждениями

Разделите найденные пункты хотя бы на четыре категории:

• технические характеристики товара или работы;
• сроки исполнения, поставки и отдельных этапов;
• документы, которые должен представить участник или поставщик;
• условия поставки, приёмки, места исполнения и передачи результата.

У каждой записи должны быть идентификатор, категория, нормализованное требование, документ и версия, точное местоположение и исходная цитата. Местоположение — это не имя файла целиком, а проверяемый адрес: например, «ТЗ, п. 2.1, стр. 3» или «Приложение 1, строка 5, стр. 2».

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

Полезный формат записи:

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

Как сопоставить требования с возможностями компании

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

• подтверждено — документ компании прямо подтверждает требование, а специалист сверил ссылку;
• не подтверждено — проверенные материалы не дают нужного подтверждения;
• неизвестно — данных пока недостаточно или ответственный ещё не проверил пункт;
• противоречие — два источника дают несовместимые значения или условия.

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

Такая таблица отделяет найденное требование заказчика от внутреннего доказательства. Она не определяет юридическую допустимость документа и не принимает решение об участии.

Как выявить противоречия и подготовить вопросы

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

Рабочая карточка противоречия содержит:

1. параметр или условие;
2. первую цитату и точное место;
3. вторую цитату и точное место;
4. вид расхождения;
5. вопрос заказчику;
6. ответственного за дальнейшее решение.

Вопрос формулируйте нейтрально. Например: «В основном ТЗ указан минимум 20 л/мин, а в приложении — 18 л/мин. Какое значение и какая редакция применяются при подготовке предложения?» Такая запись показывает проблему, но не утверждает, что участника допустят или отклонят.

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

Учебный пример матрицы требований к насосу

Синтетический пример: все документы, страницы, цитаты и значения вымышлены. Это не файл закупки, не клиентский кейс и не результат внедрения Switch On AI.

Предположим, основное ТЗ требует расход не менее 20 л/мин и питание 220 В. В нём также указан сертификат без пояснения вида. В приложении приведён расход 18 л/мин. Матрица должна сохранить каждый исходный фрагмент и не решать за специалиста, какой документ имеет приоритет.

Конфликт можно описать арифметически. Разница между приложением и минимумом основного текста равна 18 − 20 = −2 л/мин. Относительное отклонение от минимума: (18 − 20) / 20 × 100% = −10%. Значение приложения на 2 л/мин, или на 10%, ниже указанного в основном ТЗ минимума.

Этот расчёт доказывает только наличие документального расхождения в синтетическом примере. Он не доказывает несоответствие реального товара, отклонение заявки или решение о допуске. Питание 220 В проверяется отдельно и в расчёт расхождения по расходу не входит.

После вопроса заказчику специалист обновляет карточку: добавляет ответ, дату, источник ответа и принятое им решение. Старые цитаты сохраняют, чтобы было видно, на каком основании возник вопрос.

Как проверить результат и внедрить помощника

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

Проверяйте не только число найденных пунктов:

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

Для учебной иллюстрации представим ручную разметку из 10 требований. Помощник нашёл 9 и пропустил 1. Полнота равна 9 / 10 × 100% = 90%. Если только 8 из 9 найденных требований имеют точные цитаты и местоположения, точность подтверждений равна 8 / 9 × 100% ≈ 88,9%.

Это синтетический расчёт методики, а не результат теста Switch On AI и не показатель реальной системы. Для проекта размер выборки, категории ошибок и допустимые значения задают до проверки. После изменения OCR, модели, шаблона анализа или состава документов затронутые сценарии проверяют повторно.

Switch On AI может разработать под эту операцию ИИ-помощника, бота или фиксированную интеграцию после проверки документов, данных, доступных API и прав. Если система должна выбирать между разрешёнными источниками и готовить вопросы, может подойти ИИ-помощник. Если шаги всегда одинаковы, достаточно фиксированной автоматизации. Диалоговый интерфейс определяет форму общения с ботом, но сам по себе не доказывает наличие агентных функций.

Для первого разбора подготовьте разрешённый комплект документации, реестр версий и текущий шаблон матрицы. На странице об ИИ-агентах описаны границы помощника и порядок проверки. Совместимость с конкретным сервисом, тариф, права доступа и состав подключения проверяются отдельно; упоминание Azure Document Intelligence не означает партнёрство или выполненный проект с этим продуктом.

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