Генерация технического задания с помощью ИИ: от текстового описания до готового DOCX за 10 минут

Специалист по закупкам тратит на подготовку одного ТЗ от 2 до 5 рабочих дней. AI-генератор делает это за 10 минут — с корректной структурой, нужными разделами и выгрузкой в DOCX. Разбираем, как это работает, где подводные камни и почему полностью доверять генерации пока нельзя.

Проблема: почему ТЗ до сих пор пишут вручную

Техническое задание для закупки по 44-ФЗ или 223-ФЗ — не произвольный документ. Это структурированный текст с обязательными разделами, конкретными формулировками и ссылками на нормативку. Ошибка в ТЗ — это отменённый тендер, жалоба в ФАС или поставка не того, что нужно.

Типичный процесс: специалист берёт старое ТЗ на похожую закупку, копирует структуру, переписывает содержание, сверяется с ГОСТами и классификаторами, согласовывает с юристами и техническими экспертами. На выходе — 10–30 страниц, на которые ушла рабочая неделя.

Основные проблемы ручного подхода:

• Время. 2–5 дней на один документ при загрузке в 15–20 ТЗ в месяц — это один человек, занятый только написанием.
• Разнородность. Каждый специалист структурирует по-своему. Нет единого стандарта внутри организации.
• Ошибки переноса. При копировании из старых ТЗ остаются чужие реквизиты, устаревшие ГОСТы, неактуальные требования.
• Нормативные риски. Пропущенный обязательный раздел — основание для жалобы участника закупки.

Автоматизация ТЗ через AI решает не все эти проблемы, но существенно сокращает рутину. Разберём, как именно.

Архитектура решения: что происходит между вводом текста и DOCX

Генератор технического задания на базе ИИ — это не просто «ChatGPT, напиши ТЗ». Это pipeline из нескольких этапов, каждый из которых решает свою задачу.

Этап 1. Приём и нормализация входных данных

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

На этом этапе система:

• Извлекает ключевые сущности: объект закупки, количество, сроки, бюджет, требования к характеристикам.
• Классифицирует тип закупки: товар, работа, услуга.
• Определяет применимую нормативную базу: 44-ФЗ, 223-ФЗ, корпоративные регламенты.

Технически это задача NER (Named Entity Recognition) и классификации. Хорошо работает связка LLM + структурированный промпт с few-shot примерами. Модель получает входной текст и возвращает JSON с извлечёнными параметрами:

Этап 2. Структурирование по шаблону

Извлечённые данные мапятся на шаблон ТЗ. Для закупок по 44-ФЗ стандартная структура включает 5 ключевых разделов:

1. Общие сведения — наименование объекта закупки, заказчик, основание, нормативные ссылки.
2. Описание объекта закупки — функциональные, технические, качественные характеристики. Здесь же — эквивалентность, товарные знаки, единицы измерения по ОКЕИ.
3. Требования к поставке / выполнению работ — сроки, место, порядок приёмки, гарантийные обязательства.
4. Требования к участникам — квалификационные критерии, лицензии, допуски СРО.
5. Приложения — спецификации, формы заявок, проекты контрактов.

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

Это принципиальный момент: свободная генерация для ТЗ опасна. Модель может выдать формулировку, которая ограничивает конкуренцию или противоречит статье 33 закона 44-ФЗ. Шаблонный подход с контролируемой генерацией снижает этот риск.

Этап 3. Генерация текста разделов

Для каждого раздела LLM получает:

• Структурированные данные из этапа 1.
• Шаблон раздела с инструкциями.
• Примеры корректных формулировок (few-shot).
• Ограничения: список запрещённых конструкций (например, указание конкретного производителя без слов «или эквивалент»).

Промпт для генерации раздела «Описание объекта закупки» выглядит примерно так:

На выходе — текст раздела в markdown или HTML, готовый к вставке в документ.

Этап 4. Валидация

Сгенерированный текст проходит автоматическую проверку:

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

Валидацию можно реализовать как отдельный вызов LLM с ролью «рецензент» или как набор rule-based проверок. На практике лучше работает комбинация: жёсткие правила ловят формальные ошибки, LLM — смысловые.

Этап 5. Генерация DOCX

Финальный этап — сборка документа. Текст из всех разделов собирается в DOCX-файл с корректным форматированием: титульный лист, нумерация, таблицы характеристик, колонтитулы.

Для генерации DOCX в Python используют python-docx, для более сложных шаблонов — docxtpl (Jinja2-шаблоны прямо внутри DOCX). Подход с шаблонами предпочтительнее: дизайн документа готовит человек в Word, а код только подставляет данные.

Workflow целиком: что видит пользователь

Со стороны пользователя процесс выглядит просто:

1. Открывает веб-интерфейс или бот в Telegram.
2. Вводит описание потребности — текстом, файлом или голосом.
3. Система задаёт уточняющие вопросы, если данных недостаточно: «Укажите требуемый срок поставки», «Нужна ли гарантия?», «Есть ли требования к лицензиям участника?».
4. Получает превью ТЗ с разбивкой по разделам. Может отредактировать любой раздел.
5. Нажимает «Скачать DOCX» — получает готовый документ.

Весь цикл занимает 5–15 минут в зависимости от сложности закупки.

Что даёт автоматизация: цифры и эффекты

Скорость

Генерация черновика ТЗ из 5 разделов — 30–60 секунд. С учётом ввода данных и ручной вычитки — 10–15 минут. При объёме в 20 ТЗ в месяц это экономия 30–80 часов рабочего времени. Один специалист освобождается почти полностью.

Стандартизация

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

Соответствие нормативам

Встроенные правила валидации отлавливают типовые нарушения:

• Указание конкретного товарного знака без «или эквивалент» (нарушение п. 1 ч. 1 ст. 33 44-ФЗ).
• Избыточные требования, ограничивающие конкуренцию.
• Отсутствие обязательных разделов.
• Устаревшие ссылки на ГОСТы.

По данным ЕИС, около 12% закупок обжалуются в ФАС, и значительная часть жалоб связана с некорректными ТЗ. Автоматическая валидация не устраняет этот риск полностью, но снижает вероятность формальных ошибок.

Снижение порога входа

Специалисту не нужно помнить структуру ТЗ, актуальные ГОСТы и формулировки. Система подставляет их автоматически. Это критично для организаций, где закупки ведут не профильные специалисты, а сотрудники подразделений-заказчиков.

Подводные камни: где AI пока не справляется

Сложные технические характеристики

Для стандартных закупок (оргтехника, мебель, канцелярия) генерация работает хорошо — характеристики типовые, ГОСТы известные. Но для специализированного оборудования (медтехника, промышленные станки, лабораторное оборудование) LLM может сгенерировать некорректные диапазоны характеристик или пропустить критичные параметры.

Решение: для сложных категорий нужны предобученные справочники характеристик и обязательная экспертная вычитка.

Галлюцинации в нормативных ссылках

LLM может сослаться на несуществующий ГОСТ или указать отменённый стандарт. Это одна из самых опасных ошибок — документ выглядит корректно, но содержит недействительную ссылку.

Решение: RAG (Retrieval-Augmented Generation) с базой актуальных нормативных документов. Модель не придумывает ссылки, а выбирает из проверенного реестра. Тестирование этого подхода показало снижение доли некорректных ссылок с 15–20% до 1–2%, но не до нуля. Финальная проверка человеком обязательна.

Юридические нюансы

ТЗ — юридический документ. Неточная формулировка может привести к спору на этапе исполнения контракта. AI не понимает контекст конкретной закупки так, как его понимает опытный юрист. Генератор создаёт качественный черновик, но не заменяет юридическую экспертизу.

Актуальность данных

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

Стек технологий: из чего собирать

Для тех, кто хочет реализовать подобный генератор, — минимальный стек:

Компонент	Технологии	Назначение
LLM	GPT-4o, Claude, GigaChat	Генерация текста разделов
NER / Extraction	LLM + structured output	Извлечение параметров из описания
Шаблоны DOCX	docxtpl, python-docx	Сборка документа
Нормативная база	PostgreSQL + pgvector	RAG по ГОСТам и нормативам
Валидация	Rule engine + LLM	Проверка на соответствие
Интерфейс	React / Telegram Bot	Ввод данных и превью

Для российских заказчиков важен вопрос размещения данных. Если ТЗ содержит чувствительную информацию, использование зарубежных API (OpenAI, Anthropic) может быть неприемлемо. Альтернативы: GigaChat API от Сбера, YandexGPT, или self-hosted модели на базе LLaMA / Mistral.

При выборе self-hosted варианта нужен GPU-сервер. Модели класса 70B параметров (LLaMA 3.1 70B, Qwen2.5 72B) дают качество, сопоставимое с GPT-4 на задачах генерации структурированного текста на русском, но требуют минимум 2×A100 80GB для inference.

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

Начните с пилота на простых категориях

Не пытайтесь сразу автоматизировать все закупки. Возьмите 3–5 типовых категорий (офисная техника, расходные материалы, мебель) и запустите генератор на них. Оцените качество, соберите обратную связь от специалистов, измерьте реальную экономию времени.

Сохраняйте «человека в петле»

Автоматическая генерация ТЗ — это инструмент помощи, а не замена специалиста. Workflow должен включать этап ручной проверки и правки. Со временем, по мере накопления обратной связи, доля ручных правок будет снижаться.

Собирайте фидбек в структурированном виде

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

Версионируйте шаблоны и промпты

Промпты для генерации — такой же код, как и всё остальное. Храните их в Git, версионируйте, проводите code review. Изменение одного слова в промпте может повлиять на качество генерации всех ТЗ.

Интегрируйте с ЕИС и внутренними системами

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

Что дальше: от генерации ТЗ к полному циклу закупки

Генератор ТЗ — точка входа в автоматизацию закупочного процесса. Логичные следующие шаги:

• Автоматический расчёт НМЦК (начальной максимальной цены контракта) на основе анализа предыдущих закупок и рыночных данных.
• Генерация проекта контракта — шаблонный документ, который на 80% повторяет структуру ТЗ.
• Проверка заявок участников — AI-анализ предложений на соответствие требованиям ТЗ.
• Мониторинг исполнения — автоматическое отслеживание сроков и этапов поставки.

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

---

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

---

Подписывайтесь на наш канал: @vibelogia

Поделимся опытом

hello@vibelab.ru

8 800 201 85 68

Написать в Telegram