Список того, что продукт умеет, проверить трудно: обещание можно переформулировать под любой ответ, а демо всегда собирают из документов, которые точно сработают. Список того, что продукт делать отказался, устроен иначе — его можно свериться буквально: открыл систему, попробовал то самое действие, увидел, что его там нет. Именно поэтому отказ — самый проверяемый жанр из всех, что можно написать про автоматизацию, и именно поэтому его стоит публиковать честно, а не прятать за общими словами про «постоянное развитие продукта».
Ниже — три вещи, которые мы рассматривали, строили или обсуждали, и сознательно не довели до продакшена как автоматику, и один провал демонстрации, который многому нас научил и который мы не стали приукрашивать задним числом. Три из этих четырёх историй читатель может проверить сам: попробовать действие, о котором идёт речь, и увидеть на своём экране ровно то поведение, которое здесь описано. А четвёртая проверяется иначе — тем, что мы публикуем её без приукрашивания.
Коротко. Мы не ставим подписи в документах — это делают тендерные площадки при подаче. Мы построили автопривязку найденных документов к чек-листу и намеренно держим её выключенной: система предлагает совпадение, а подтверждает его специалист. Мы не берём на себя PPTX, ODT, RTF и архивы — каждый формат добавляет свой режим отказа, а обещание «любой формат» означает тихую деградацию где-то в хвосте. И один честный провал: на демо система нашла 2 совпадения из 43 пунктов чек-листа — потому что в хранилище на тот момент лежало 4 документа из 41.
Отказ 1: подписи
Первый вопрос, который задаёт почти каждый, кто впервые видит систему подготовки тендерного пакета: а подписывает ли она документы сама? Ответ — нет, и это не технический недочёт, а осознанный отказ.
Руководитель, которая ведёт подготовку заявок изнутри процесса, объясняет короче любой маркетинговой страницы: подача почти всегда идёт через тендерную площадку, а там, по её словам, «не ставится никаких подписей». Заявка подаётся не как набор отдельно подписанных файлов, а через площадку, которая сама обеспечивает подписание в момент отправки — это её зона ответственности, а не зона ответственности системы подготовки документов.
Из этого следует конкретное инженерное решение: там, где в форме есть место для подписи, система относится к нему как к позиции в форме — координатам, которые нужно оставить пустыми и корректно оформленными, а не как к подписи, которую кому-то нужно поставить. Слот подписи существует в разметке документа наравне с полем даты или полем ИНН, но заполняется он не значением, а пустотой определённой формы.
Более глубокая причина этого отказа — не только в том, что площадки уже решают задачу подписания технически. Система, которая ставила бы подпись сама, брала бы на себя ответственность, которую мы на конвейер обработки текста класть не хотим. Мы не строим механизм электронной подписи и не планируем его строить как часть этого контура: подготовка документа и его подписание — разные зоны ответственности, и вторая остаётся вне нашего контура целиком. Эта же граница — предмет отдельного разбора в материале про автоматическое заполнение документов, где слот подписи разобран как один из типов полей формы: место в документе, а не механизм подписания.
Отказ 2: автопривязка найденных документов
Вторая вещь устроена ровно наоборот, чем можно подумать по названию отказа: мы её построили. Система, которая сопоставляет документы из хранилища компании с пунктами чек-листа заявки, работает — находит устав, лицензию, банковскую справку и предлагает, к какому пункту какой документ подходит. Проблема не в том, что автопривязка не получилась технически. Проблема в том, что мы решили: найденное совпадение не должно превращаться в готовую строку заявки без участия человека.
Разница здесь не формальная. Каждый вендор в этой категории продуктов охотно демонстрирует момент, когда система сама, без единого клика, собирает пакет документов и подставляет их в нужные места — это эффектная часть демо. Мы сознательно не строим этот момент как автоматику, потому что цена одной ошибки здесь несимметрична экономии от избавления от клика. Если устав компании окажется неверно привязан к пункту чек-листа и это уйдёт в поданный пакет незамеченным, стоимость такой ошибки — не потерянная минута, а риск для всей заявки на конкретной закупке. Экономия от того, что подтверждение не нужно нажимать руками, этот риск не окупает.
Поэтому найденное совпадение в системе — это гипотеза, которую специалист видит и подтверждает сам, а не запись, которая ложится в заявку молча. Результаты сопоставления не привязываются автоматически — по устройству системы, а не по настройке; это тот же принцип, который уже описан в материале про нейросеть для документов: система подсвечивает вероятный вариант внутри допустимого кластера совместимости, а последнее слово остаётся за специалистом, знающим детали именно этой закупки — детали, которых формальная проверка не видит.
Отказ 3: форматы вне контракта
Третий отказ касается не одной функции, а границы того, какие файлы система вообще берётся обрабатывать. Внутри контура действует негласный, но строгий контракт по уровням: документы первого уровня система обязана извлекать хорошо, документы второго уровня — не имеет права ронять с жёсткой ошибкой, даже если результат окажется неполным. А PPTX, ODT, RTF и архивы находятся вне этого контракта целиком — не потому что мы не успели до них добраться, а потому что мы сознательно не стали их туда включать.
Причина простая и честная: каждый формат — это отдельный парсер со своим собственным набором режимов отказа, и у каждого он свой, не сводимый к общему. PPTX хранит текст в слоях и группах фигур, которые не читаются как последовательный документ, а порядок фигур на слайде не совпадает с порядком, в котором их стоило бы читать, — парсер, написанный для линейного текста, либо смешает фрагменты местами, либо пропустит часть слайда молча. ODT и RTF несут собственные наследственные особенности разметки, унаследованные от разных поколений офисных пакетов и от того, каким редактором файл в итоге пересохраняли последний раз, — одна и та же на вид таблица в двух файлах этих форматов может быть закодирована двумя разными способами, и парсер, рассчитанный на один из них, на втором либо ошибётся, либо остановится. Архив — это вообще не документ, а контейнер, внутри которого может быть что угодно, включая вложенные архивы и файлы форматов, которые сами по себе тоже не входят в контракт, — гарантия по архиву на деле означала бы гарантию по всему, что может в нём оказаться.
Стоимость такого гарантирования измеряется не часами разработки одного парсера, а тем, что происходит после: обещание «мы работаем с любым форматом» вынуждает либо держать под контролем бесконечно растущий список частных случаев, либо тихо снижать планку качества там, где реального покрытия нет, — и второе всегда незаметнее для вендора, чем для пользователя, который получает документ с потерянной строкой и не подозревает об этом. Обещание в такой ситуации означает одно из двух: либо вендор ещё не встречал по-настоящему пёстрый поток тендерных пакетов, либо он готов мириться с тихой деградацией результата на форматах, для которых парсер написан наспех и не протестирован на живом потоке. Мы предпочитаем назвать границу вслух — Tier 1 и Tier 2 поддерживаются по контракту, Tier 3 честно вне него — чем позволить пользователю обнаружить эту границу самому, уже на важной закупке, когда переделывать поздно.
Честный провал: 2 из 43
Три предыдущих истории — про отказ строить что-то намеренно. Эта — про то, как демонстрация системы выглядела провалом, хотя провалом на самом деле не была.
На одном из показов работы системы парсер сопоставил найденные документы всего с двумя пунктами чек-листа заявки из сорока трёх. С места специалиста, который в тот момент смотрел на экран, это читалось однозначно: он открыл чек-лист конкретной закупки, ожидая увидеть заполненные строки, а увидел почти сплошную пустоту — десятки непокрытых пунктов и ни одного намёка на то, что где-то рядом идёт полезная работа. Реакция в такой момент предсказуема: не «хранилище ещё не наполнено», а «инструмент не работает». Реальная причина оказалась в другом месте — в хранилище компании на момент показа было загружено 4 документа из 41 нужного. Система нашла ровно то, что могла найти при таком состоянии хранилища, — и не больше.
Само по себе пустое хранилище в этой точке маршрута — не сбой внедрения, а его предсказуемый первый этап. Карточка компании и портфолио кейсов не наполняются сами в момент подключения системы: кто-то должен собрать уставные документы, лицензии, банковские справки и примеры прошлых контрактов и загрузить их — а это занимает время и обычно происходит не за один присест, а порциями, по мере того как находится нужный файл. Показ, устроенный до того, как это наполнение завершено, застаёт систему ровно в той точке, где ей физически нечем закрывать чек-лист, — и это ожидаемое состояние на раннем этапе внедрения, а не случайность конкретного показа.
Урок здесь не про то, что демо прошло неудачно, а про саму природу задачи, которую решает сопоставление документов. Система, которая находит документы под пункты чек-листа, не может найти то, чего физически нет в хранилище, — сколько бы совпадений она ни умела распознавать в теории. И демо на почти пустом хранилище честно выглядит провалом — и в этой точке честнее не спорить с этим впечатлением, а назвать его причину: данных для работы системы пока недостаточно. Разница между «система не работает» и «данных пока недостаточно» кажется тонкой, пока не увидишь её на собственном экране: 2 из 43 — это не оценка качества сопоставления, это оценка полноты хранилища на момент показа.
Мы не будем дописывать к этой истории красивое продолжение о том, что после показа документы загрузили и чек-лист закрылся полностью, — такого измерения у нас нет, и придумывать его задним числом означало бы нарушить ровно тот принцип честности, ради которого эта статья вообще написана. Урок остаётся таким, каким он был в момент показа: результат сопоставления настолько хорош, насколько полно хранилище, из которого оно собирает совпадения, и это стоит проверять до демонстрации, а не объяснять после неё.
Есть и второй слой этого урока, менее очевидный на первый взгляд: пустое хранилище и сломанный парсер выглядят на экране совершенно одинаково — оба дают почти пустой чек-лист. Различить их можно только одним способом — заглянуть в хранилище и посчитать, сколько документов там реально лежит, прежде чем делать вывод о качестве самого сопоставления. Число «2 из 43» без этого контекста рассказывает про хранилище, а не про систему — и именно подмена одного другим превращает честный пробел в данных в мнимый провал технологии.
Практический вывод из этого показа простой: собрать и загрузить стартовый комплект документов — это отдельный шаг подготовки, а не что-то, что происходит само собой параллельно с настройкой остального. Пока этот комплект не собран, любая проверка сопоставления будет показывать не качество системы, а неполноту хранилища, — и планировать первый показ стоит уже после того, как эта работа сделана, а не до.
Что общего у четырёх историй
Автоматизация — это не про то, чтобы автоматизировать как можно больше. Это про выбор, где остановиться, и про готовность объяснить этот выбор словами, а не молчанием. Подписи мы оставляем площадкам, потому что подписание — не наша зона ответственности. Автопривязку мы построили и держим выключенной, потому что цена одной неверной строки выше экономии от одного ненажатого клика. Tier-3 форматы мы не берём в контракт, потому что честная граница лучше тихой деградации. А провал 2 из 43 мы публикуем как есть, потому что он показывает настоящий предел системы честнее, чем любой отполированный кейс с идеальными числами.
Каждый из этих четырёх пунктов — это строка в контракте с человеком, который будет пользоваться системой на реальной закупке. Строку можно проверить за минуту: попробовать поставить подпись и увидеть, что система этого не делает; посмотреть, привязался ли найденный документ сам, и увидеть, что нет, он ждёт подтверждения; попробовать PPTX или архив и увидеть, что этот формат в контракт не входит — граница названа заранее, а не обнаруживается на важной закупке. Список того, чего система не делает, проверяется читателем, который уже обжигался на чужих обещаниях, за девяносто секунд — и именно поэтому публиковать такой список безопаснее, чем публиковать список того, что система якобы делает всё.
Более широкий контекст того, откуда вообще берутся эти решения и в какой момент маршрута подготовки пакета они применяются, — в материале «Подготовка тендерной документации». А общая анатомия пакета, внутри которой живут все три отказа и провал, разобрана в «Тендерной документации».
