ИИ-проверка ТЗ: как сохранять доказательства по каждой строке

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

Сохраняйте цепочку решения, а не только результат

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

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

Не называйте такую запись юридическим доказательством надлежащего исполнения сама по себе. Это внутренний контроль качества подготовки заявки. Состав документов участника определяется применимыми правилами; для 44-ФЗ ориентиром служит статья 43. Внутренний журнал не заменяет требуемые сведения и не обязывает заказчика принимать дополнительную таблицу.

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

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

Зафиксируйте версии источников до сравнения

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

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

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

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

Контрольная сумма файла может помочь установить, что проверенная копия не изменилась, но не подтверждает истинность её содержания. Это дополнительный технический идентификатор. Не превращайте его наличие в основание доверять неподходящему паспорту или устаревшей версии задания.

Условный пример записи по размеру изделия

Предположим, в задании установлена ширина не более 600 мм. Нейросеть нашла в паспорте значение 580 и поставила положительный статус. При ручной проверке выяснилось, что 580 мм относится к корпусу, а габарит с установленными ручками составляет 620 мм. Все числа условные.

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

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

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

Отделяйте отсутствие данных от найденного противоречия

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

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

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

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

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

Подготовьте проверяемую передачу внутри команды

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

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

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

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

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

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

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

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

FAQ

Достаточно ли скриншота положительного вывода?

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

Нужно ли хранить все ответы модели?

Определите внутренний порядок хранения с учётом задачи и допустимости данных. Для спорного решения полезно сохранить исходный вывод и исправление, чтобы восстановить причину. Лишние чувствительные сведения не следует дублировать без необходимости.

Контрольная сумма доказывает правильность паспорта?

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