Парсинг тендеров 44-ФЗ и 223-ФЗ для строительной компании: что получилось за полгода

Полгода назад ко мне пришёл собственник строительной компании на 60 человек. Профиль - подрядка по социальным объектам в Москве и области: школы, детские сады, поликлиники, пристройки. Заказ был простой по формулировке и взрослый по содержанию: "у меня тендерный отдел из двух человек, они не успевают физически. Половину подходящих лотов мы тупо не видим. Сделай так, чтобы видели всё, а смотрели только то, что нам реально подходит".

Расскажу, что получилось за эти полгода. Какие площадки реально парсятся, где спотыкались, как фильтрация на ИИ-моделях изменила экономику отдела, и почему клиент в итоге закрыл в 2.3 раза больше тендеров при том же штате. Цифры реальные, кейс собирательный по нескольким клиентам, чтобы не светить конкретику.

С чего начиналась боль

Контекст у клиента типичный для среднего строительного бизнеса в России. Есть допуск СРО, есть портфолио на 40-50 объектов за последние пять лет, есть юристы, сметчики, прорабы. И есть тендерный отдел: руководитель и два специалиста. Их задача - найти подходящий лот, оценить, подготовить заявку, подать, проконтролировать торги.

Стек у отдела был такой. Контур.Закупки на одном рабочем месте, ручной мониторинг сайта zakupki.gov.ru, регулярные обходы трёх-четырёх электронных площадок типа Сбербанк-АСТ и РТС-тендер. Часть лотов прилетала через знакомых и рассыльные базы, часть тендерные специалисты выискивали по поисковым запросам. На обработку одного лота уходило 25-40 минут: открыть, скачать ТЗ, прочитать, прикинуть смету по бюджету, сверить с допусками компании, решить - идём или нет.

Считаем простую математику. Восьмичасовой день, минус совещания и переписка - чистого времени на лоты в среднем 5 часов. На двоих это 10 часов в день, то есть от 15 до 24 лотов в день, которые они физически могут просмотреть. В Москве и области в их сегменте (бюджет от 50 до 200 миллионов, объекты социальной инфраструктуры) ежедневно появляется 80-130 новых лотов, не считая 223-ФЗ и коммерческих закупок. Считай, что 70-80% мимо. И самое обидное - там, среди пропущенных, регулярно были лоты под их профиль.

Руководитель отдела как-то прислал статистику за полугодие: они подали заявки на 41 тендер, выиграли 7. Конверсия по подачам нормальная, около 17%. А вот сколько подходящих контрактов они в принципе не увидели - этого никто посчитать не мог. Цифра ушла на дно.

Почему готовые сервисы не закрыли задачу

Логичный вопрос: зачем вообще что-то парсить, если есть Контур.Закупки, SberCRM Тендеры, Tenderplan, ТендерИнтеллект? Это нормальные продукты, я их клиентам регулярно рекомендую. Они умеют искать по федеральным площадкам, складывать в один список, рассылать уведомления, экспортировать в Excel.

В чём затык. Контур.Закупки на тарифе "Стандарт" стоит около 23 600 рублей в год, "Эксперт" - 67 000 рублей в год, плюс по 6 000 рублей за каждое дополнительное рабочее место. Это сам по себе посильный бюджет. Но фильтрация в этих сервисах работает по ключевым словам и категориям ОКПД. Это всегда либо "слишком широко" (приходят все лоты по ОКПД 41.20.20, в том числе пристройки гаражей и капремонт хозблоков, которые им не нужны), либо "слишком узко" (отсечёшь по слову "школа" - пропустишь "общеобразовательное учреждение №..." и "учебный корпус", где школа подразумевается, но не названа).

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

Готовые тендерные сервисы такой семантический поиск тоже подтягивают, но качество там разное. У клиента было ощущение "что-то находят, но многое мимо". В итоге сошлись на гибридной схеме: оставить Контур.Закупки как страховку и для отслеживания истории по конкретным заказчикам, плюс сделать свой парсер с ИИ-фильтрацией поверх ЕИС и площадок.

Что такое ЕИС и почему её можно парсить

Единая информационная система в сфере закупок (zakupki.gov.ru, она же ЕИС) - это государственный портал, на котором по закону публикуются все закупки по 44-ФЗ (государственные и муниципальные заказчики) и большинство закупок по 223-ФЗ (госкомпании, естественные монополии и так далее). Это публичные данные. Российское законодательство прямо требует, чтобы они были общедоступны, иначе сами закупки нелегальны. Парсинг открытых данных ЕИС юридически чистый. Заказчик не может на тебя пожаловаться за то, что ты прочитал то, что он по закону обязан публиковать.

Технически ЕИС отдаёт данные тремя способами. Первый - официальная FTP-выгрузка XML-файлов с реестром закупок. Туда попадают извещения, документация, протоколы. Второй - публичные HTML-страницы на самом сайте. Третий - якобы есть API, но как подробно описал автор на Хабре в свежей статье, по факту с этим API ходишь по кругу: кнопка ведёт на ЕИС, оттуда снова к описанию API, и так бесконечно. Реально работают первые два способа.

В нашем случае основу взяли с FTP. Это самый чистый канал: данные приходят пакетами, структурированно, без капчей и блокировок. На FTP лежат архивы по регионам и датам. Парсер забирает за сутки 50-200 мегабайт XML, в них извещения, документы, тенденции изменений. Из извещения вытягивается всё: номер закупки, заказчик, бюджет, сроки подачи, ОКПД, ссылки на документы ТЗ.

HTML-страницы используются как дополнение в двух случаях. Когда нужно проверить статус лота (отменён, изменён, идут торги) и когда из выгрузки не подтянулся какой-то документ. Парсер на HTML простой: сервер ЕИС отдаёт всё через серверный рендеринг, JavaScript не требуется, можно работать обычным запросом и разбирать HTML. Капчи на просмотре извещений нет.

Что с электронными площадками

ЕИС - это витрина. Сами торги идут на восьми федеральных электронных площадках, отобранных правительством. Большинство строительных контрактов по 44-ФЗ крутятся на четырёх: Сбербанк-АСТ, РТС-тендер, Roseltorg, ТЭК-Торг. По 223-ФЗ и коммерческим закупкам подключаются ещё B2B-Center и Tender.Pro.

Парсить нужно ли? Зависит от задачи. Для поиска лотов - не нужно, потому что извещение всегда сначала публикуется в ЕИС, а уже потом дублируется на конкретной площадке. То есть ЕИС - первый и самый полный источник. Электронные площадки нужны, если вы хотите видеть динамику торгов (кто подал заявки, какая цена сейчас на аукционе, какие были снижения). Это совсем другая задача - тендерная аналитика конкурентов, а не поиск входящих лотов.

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

Ещё один нюанс. РТС-тендер вместе с B2B-Center и ОТС - это общая группа компаний с оборотом около 10 трлн рублей в год, и B2B-Center пишут, что каждая вторая закупка коммерческих компаний идёт через них. Для строительной компании, которая в перспективе планирует выйти на коммерческие тендеры (а не только на бюджетные стройки), B2B-Center нужно держать в радаре. Мы планировали подключение на втором этапе, но пока клиент решил сосредоточиться на государственном сегменте.

Как ИИ читает ТЗ и решает, подходит ли лот

Главная фишка проекта - не парсинг сам по себе, а фильтрация через языковую модель. Парсер собирает все лоты Москвы и Московской области с бюджетом от 30 до 250 миллионов рублей. Это широкая сетка - в неё попадает 200-300 лотов в неделю. Дальше работает ИИ-фильтр.

Что он делает. На вход модель получает: краткое описание профиля клиента (что строит, где, на какие бюджеты, какие СРО, какие референсные объекты есть в портфолио), ТЗ конкретного лота (или его выжимка, если ТЗ на 80 страниц), плюс несколько метаданных вроде типа объекта, сроков, обеспечения заявки. На выходе - решение из трёх вариантов: "подходит", "под вопросом", "не подходит" и короткое объяснение почему.

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

Что значит "явный мусор" в фильтрации. Например, в Москве заказчик объявил тендер на капитальный ремонт школы на 80 миллионов. Звучит идеально под профиль клиента. Но в ТЗ внутри написано: требуется выполнение работ по реконструкции бассейна с заменой системы водоподготовки, монтажом 25-метровых дорожек и установкой профессионального оборудования для соревнований. Бассейн - не их компетенция. Они умеют делать общестрой школ, но не профильные спортивные сооружения. Лот отсекается. Тендерный специалист его даже не открывает.

Другой случай. Лот на ремонт детского сада на 45 миллионов, явный кандидат. ИИ читает ТЗ и помечает "под вопросом, требуется техническое заключение по фасадным работам с применением вентилируемых систем определённого производителя". Это уже флаг для менеджера: компания умеет делать вентфасады, но не работала с этим конкретным производителем. Лот не отбрасывается, а уходит в очередь "посмотреть глазами". На это специалист тратит уже не 30 минут, а 5: пробежать ТЗ, решить, готовы ли влезать.

На старой статье на Хабре по парсингу ЕИС автор отмечал: главная сложность не в парсинге сайта, а в осмысленной обработке документов после. Через четыре года это всё ещё актуально, только теперь у нас есть нормальные языковые модели, которые это делают.

Где спотыкались в процессе разработки

Не всё было гладко. Поделюсь, чтобы вы знали реальные грабли.

ТЗ в PDF и сканированных DOC. Часть заказчиков выкладывает техническое задание просто как сканированный документ или PDF на 100 страниц с таблицами. Чтобы модель могла это прочитать, нужен слой OCR. Использовали комбинацию: для нормальных текстовых PDF - прямое извлечение, для сканов - распознавание с предобработкой картинки. Сборка этого пайплайна добавила нам почти месяц работы. На больших ТЗ (где-то 5% всех лотов) точность распознавания всё равно не идеальная, и тендерному специалисту приходится открывать оригинал. Но 95% случаев модель видит ТЗ нормально.

Изменения извещений. Заказчик имеет право вносить изменения в извещение после его публикации: меняется бюджет, сдвигаются сроки, корректируется ТЗ. Это не редкость. В первой версии парсера мы по ошибке не отслеживали изменения, и пару раз клиент готовил заявку под устаревший ТЗ. С тех пор отдельная подсистема каждые 4 часа проверяет статус активных лотов и реагирует на изменения. Если в ТЗ внесены содержательные правки (не косметика, а смена объёма работ или сроков) - повторный прогон через ИИ-фильтр.

Дубли и пересмотры. Заказчик отменил закупку, через две недели опубликовал её снова с минимальными правками. Технически это новые извещения с новыми номерами. Без логики дедупликации лот падает в ленту дважды, и тендерный специалист тратит время на повторную оценку. Сделали склейку: если 70%+ ТЗ совпадает с уже виденным лотом того же заказчика за последние 60 дней, помечается как "повтор", модель уже не запускается, тендерный спец сразу видит, что они с этим заказчиком уже работали или отказывались.

Не все лоты на ЕИС закрытые. Часть закупок (особенно по 223-ФЗ) проводится в режиме закрытых процедур: видны только избранным участникам. В таких случаях извещение либо вообще не публикуется, либо публикуется в усечённом виде. Это не лечится парсингом, это про другие каналы поиска. Для строительства по 44-ФЗ это не критично - там почти всё в открытом доступе.

Соотношение скорости и нагрузки. ЕИС в часы пик и в дни массовых публикаций (последние числа квартала) тормозит. Если парсер ходит слишком агрессивно, его не блокируют, но и не отвечают. Балансировали нагрузку: основная выгрузка ночью через FTP, дополнительные точечные запросы в течение дня с разумным таймаутом и ретраями. Это техничка, не интересно, но без неё проект бы шатался.

Что в итоге изменилось у клиента

Спустя четыре месяца после запуска (полтора месяца на разработку плюс время на отладку) посчитали результаты. Сравнивали полугодие до проекта и полугодие после.

Лотов посмотрено: было 1 800, стало 4 700. То есть в покрытии прибавили в 2.6 раза. Это и за счёт того, что теперь видны все лоты Москвы и области, попадающие в широкие фильтры, и за счёт того, что специалист уже не тратит 30 минут на каждый - модель отсекла очевидный мусор.

Лотов, переданных на детальную проработку: было примерно 240, стало 380. Рост 58%. Это лоты, которые ИИ-фильтр пометил как "подходит" или "под вопросом" и которые после этого посмотрел руководитель отдела или специалист с пристрастием.

Подано заявок: было 41, стало 86. Это плюс 110% при том же штате.

Выиграно тендеров: было 7, стало 16. Это плюс 130% или, грубо, в 2.3 раза больше выигранных контрактов. Если усреднить по бюджету (около 80 миллионов на тендер), это разница между 560 миллионами и 1 миллиардом 280 миллионами портфеля заказов в год.

Стоимость проекта со всеми этапами, включая интеграцию с их Битрикс24 и обучение отдела работе с новым интерфейсом - 870 тысяч рублей в один платёж плюс 35 тысяч в месяц на поддержку и токены моделей. Окупилось на третьем выигранном тендере. Дальше - чистый плюс.

Что не получилось и где есть потолок

Чтобы не выглядело рекламно, скажу про границы.

Конверсия по выигранным заявкам выросла с 17% до 18.6%. Это в пределах статистической погрешности. То есть сама по себе автоматизация не учит выигрывать. Если ваше коммерческое предложение и подготовка документов слабые, ИИ-фильтр их не подтянет. Он только помогает увидеть больше подходящих лотов и не тратить время на мусор.

Качество фильтрации - не 100%. По нашим оценкам, около 6-8% лотов, которые модель пометила как "не подходит", при ручной перепроверке оказывались подходящими. Это допустимая ошибка, но она есть. Боремся с ней постоянной донастройкой описания профиля клиента и периодическим аудитом отклонённых лотов. Полностью обнулить не получится: язык русских ТЗ многоплановый, и краевые случаи всегда будут.

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

И ещё. Перед тем как запускать такой проект, я честно прошу клиента ответить на вопрос: "У вас есть избыточная мощность по подготовке заявок? Если завтра вы увидите вдвое больше подходящих лотов, сможете ли вы их обработать?" Если ответ "нет, мы и так не успеваем", то задача меняется. Парсер тогда нужен не для расширения воронки, а для уменьшения работы по уже видимым лотам. Это другая постановка, и метрики там другие.

Юридика и риски

Парсить открытые данные ЕИС - законно. Это вытекает из самой природы 44-ФЗ: закупки должны быть прозрачны, иначе они нелегальны. Никаких пользовательских соглашений и условий, запрещающих автоматизированный доступ, на ЕИС нет. Минфин в мониторингах функционирования контрактной системы сам публикует агрегированную аналитику и поощряет внешний анализ.

С коммерческими площадками сложнее. У B2B-Center, Tender.Pro и других есть пользовательские соглашения. Часть площадок предлагает официальное API для интеграции (платное), часть не возражает против парсинга витрины (но не позволяет автоматизированно подавать заявки за пользователя). Если вы хотите парсить коммерческие тендеры - читать пользовательское соглашение конкретной площадки обязательно. У нас в этом проекте до коммерческих площадок не дошли, всё работало на государственном сегменте.

Ещё момент - персональные данные. В извещениях ЕИС они в норме не публикуются (заказчик - юрлицо, контактное лицо - служебное), но в редких случаях бывают почты и ФИО ответственных. В нашей системе эти поля проходят дополнительную обработку: не складываются в общую базу, не используются для рассылок. Это не юридическая необходимость, а гигиена. У клиента нет цели обзванивать заказчиков до момента подачи заявки, поэтому контактов и не нужно.

Кому это вообще нужно

Под нашу задачу подходят строительные компании со штатом примерно от 25-30 человек, у которых есть выделенный тендерный отдел (хотя бы один специалист) и стабильный поток подачи заявок (не меньше 10 в месяц). Если вы подаёте 3 тендера в квартал, никакой парсер вам не нужен - живой человек справится. Если вы делаете 50+ подач в месяц - вам тоже скорее всего нужно что-то более сложное, чем разовый парсер: вероятно, целая платформа с конкурентной аналитикой и автоматическим расчётом сметы.

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

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

Что в итоге

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

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

Близкие темы

Парсинг тендеров под ключ - страница с деталями того, что я делаю и сколько это стоит. ИИ для строительной отрасли - смежные сценарии: смета, ОТР, прорабы. Парсинг и мониторинг цен - близкая инфраструктурная задача для тех, кто закупает материалы. CRM для строительной компании 2026 - история про то, как раскопать порядок в воронке. 7 процессов в стройке, где ИИ окупается - где ещё в стройке имеет смысл смотреть на автоматизацию.

Источники

Думаете про парсинг тендеров для своей компании?

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

Обсудить задачу