Как я учу ИИ понимать коды ТН ВЭД, а не играть в угадайку по кривому китайскому прайсу
История допиливания проекта GTD Automation для тех, кому надоело жить в режиме «авось пронесёт на таможне».
---
С чего вообще начинается боль
Классическая сцена.
У вас есть список товаров от китайского поставщика:
- Excel-файл,
- описание на английском или ломаном русском,
- иногда микс «Chinglish + гугл-перевод».
Дальше происходит стандартная магия:
1. Переводчик/закупщик делает «как понял».
2. Этот перевод уезжает к таможенному брокеру.
3. Брокер подбирает описание и код ТН ВЭД уже к исходно неверному описанию реального товара.
И вот вы стоите на границе с:
- полуправдой в описании,
- не до конца корректным кодом,
- и повышенным риском «прилипалова» во время таможенных процедур:
- доп.проверки, - доначисления,
- споры и «пройдёмте, поговорим отдельно».
С этого места и родился мой ассистент: система, которая с порога решает стратегические проблемы — ещё до того, как брокер вообще увидит ваш товар.
---
Какие задачи ассистент решает сразу
1. Неверный перевод и описание товара
Первая беда — не таможня и не ИИ, а кривой перевод от вашего поставщика на стороне китая - по имени мистер Чоу (да, тот самый «Китаец» из «Мальчишника в Вегасе»).
Ассистент:
- берёт исходный текст (часто — смесь языков и стилей),
- делает технический перевод с учётом глоссария,
- следит, чтобы «pump», «valve», «housing», «assembly» и т.п. не превратились в поэзию уровня «насосный узел радости».
2. Отсутствие структурированных атрибутов Таможня мыслит не «по-описательному», а по признакам:
- материал,
- функция,
- способ крепления/монтажа,
- комплектность,
- для чего используется и где стоит.
Ассистент превращает текст в структурированную карточку товара, чтобы решение по коду строилось не на ощущениях, а на наборе признаков.
3. Угадайка кода и человеческий фактор
Брокер — человек. Усталость, спешка, «как обычно делали».
Ассистент:
- предлагает основное и альтернативные коды,
- показывает аргументацию,
- подсвечивает риски и зоны неопределённости.
Это не убирает человека, но сильно снижает вероятность «пальцем в небо».
4. Ноль институциональной памяти
Часто опыт по кодам живёт в голове одного-двух людей и в переписках.
Ассистент:
- сохраняет решения,
- собирает примеры,
- привязывает их к нормативным выдержкам.
То, что раньше было «мы как-то так делали», превращается в базу знаний.
---
Почему нельзя просто сказать ИИ: «Назови код ТН ВЭД»
С технической точки зрения так сделать можно: берём большую модель, пишем ей:
> «Вот описание товара, определи код ТН ВЭД, будь добр».
И она уверенно выдаёт вам код. И так же уверенно может оказаться не права.
Проблема в том, что:
- модели не держат в голове актуальные редакции ТН ВЭД ЕАЭС;
- не применяют правила ОПИ так, как это делают специалисты;
- не знают ваши внутренние кейсы и практику;
- легко придумывают правдоподобные, но неверные обоснования.
Поэтому единственный взрослый путь — это гибридный подход:
- своя база нормативных документов и примеров,
- многоступенчатая логика,
- и уже поверх этого — ИИ, который работает не «из космоса», а в рамках поля правил.
---
Что я строю:
Проект называется GTD Automation.
Данный пост про маленькую часть этой туши, которая отвечает за подсказки по части кода ТН ВЭД. Есть параллельный блок про Генерацию самих ГТД XML через XSD парсер (1063 поля), правильные namespaces, порядок элементов - это отдельная адская история)
По сути это ассистент, который помогает:
- перевести и нормализовать описания товаров,
- сформировать структурированные карточки,
- предложить коды ТН ВЭД (основной + альтернативные),
- показать аргументацию и уровень уверенности,
- честно подсветить, когда данных недостаточно.
Технически внутри это не одна промпт-магия, а многослойная система.
---
Пятислойный пайплайн: по-человечески, без лишнего технофетиша
Слой 1. Вход и нормализация
Ассистент принимает:
- списки из Excel,
- текстовые описания,
- иногда очень творческие формулировки.
Дальше:
- вычищает шум,
- нормализует формат,
- определяет язык,
- готовит текст к работе.
Слой 2. Перевод и глоссарий
Здесь включается технический перевод с упором на точность, а не красоту.
- используется глоссарий критичных терминов,
- ИИ подчиняется терминам из словаря,
- минимизируется риск, что «housing» станет «домиком», а не корпусом.
Слой 3. Структурирование
Описание превращается в структурированные данные:
- материал / состав,
- функция,
- как используется,
- часть чего,
- ключевые признаки по логике ТН ВЭД.
Все ответы проходят строгую валидацию по JSON-схемам. Никаких «примерно так» — либо валидно, либо возвращаемся к пользователю за уточнениями.
Слой 4. RAG по нормативке и примерам
Перед тем как назвать код, ассистент:
- лезет в базу собственных примеров классификации,
- поднимает выдержки из нормативных документов,
- подтягивает релевантные фрагменты правил и примечаний.
Это уже не «ИИ думает сам по себе», а ИИ, который работает поверх вашей нормативной базы.
Слой 5. Классификация + QC
Финальный слой:
- предлагает основной код и альтернативы,
- приводит аргументацию,
- выставляет флаги качества: - мало данных,
- конфликт перевода,
- непонятный материал,
- низкая уверенность и т.п.
Ассистент не делает вид, что он всевидящий. Если он сомневается — он об этом пишет.
---
Как это выглядит для пользователя (на языке жизни, а не архитектурных схем)
Поверх всей этой истории есть привычный интерфейс — Telegram-бот. Сейчас это демо-режим в телеге:
Пример пути:
1. Вы скидываете ассистенту позицию из прайса поставщика.
2. Он: - нормализует текст, - делает технический перевод, - строит карточку товара, - поднимает примеры и нормативку, - предлагает коды с аргументацией.
3. Вы: - видите не «загадочный код», а связку: - товар → признаки → нормы → код, - понимаете, где риск, - можете скорректировать описание и повторить прогон.
По мере наполнения базы ассистент всё больше становится коллективной памятью по классификации, а не просто «ботом, который иногда угадал».
---
Что под капотом (общее)
- многослойная архитектура на Python,
- несколько ролей ИИ: - переводчик,
- структурировщик,
- классификатор,
- контролёр качества;
- собственные базы:
- примеры классификации,
- выдержки из нормативных документов,
- структура ТН ВЭД,
- принятые решения и фидбэк;
- гибридный поиск:
- по тексту,
- по векторным представлениям;
- строгая валидация форматов кодов и структур ответа.
Скажем так: это не «один промпт в чатике», а нормальная инженерная система, которую можно развивать в сторону API и веб-интерфейса под задачи компании.
Конкретные модели, провайдеры и нюансы реализации — остаются за кадром.
---
Официальная нормативка и открытые данные ЕАЭС
Отдельная ветка развития — интеграция с официальными открытыми данными ЕАЭС.
Сейчас ассистент уже опирается на локальную нормативную базу, но я прорабатываю:
- использование открытых REST-API ЕАЭС как источника данных;
- синхронизацию:
- структуры ТН ВЭД,
- описаний,
- действующих редакций,
- связанных нормативных документов.
Логика простая:
- не дёргать внешний API на каждом запросе, - а регулярно синхронизировать данные во внутренние базы, - и уже на них: - валидировать коды, - учитывать даты действия, - подмешивать «официальный контекст» в аргументацию.
Идея в том, чтобы ассистент не только предлагал коды, но и проверял их на соответствие официальной картине мира.
---
Статус проекта: живая бета, а не слайд из презентации
Сейчас ассистент:
- уже умеет: - работать с описаниями товаров, - делать технический перевод, - строить структурированные карточки, - предлагать коды с альтернативами и уверенностью, - подсвечивать проблемные места; - имеет под капотом: - несколько SQLite-баз, - глоссарий, - набор тестовых сценариев, - докеризацию и конфиги. База построена на данных из ~100 pdf-документации, -полностью локальная сборка, скорость генерации до 4500 т/с вместо 35-100 у openrouter и пр.
В доработке:
- расширение структуры ТН ВЭД и версионирование; - более тонкая логика применения правил ОПИ (особенно для комплектных товаров); - интеграция открытых данных ЕАЭС; - мониторинг качества и метрики.
Версия условно можно считать где-то в районе 0.2.x (Beta): уже можно трогать и использовать как ассистента, но его поведение я ещё целенаправленно улучшаю.
В планах прикрутить еще лангчейн и бд - тогда он сможет на этапе предобработки "дособирать" у вас больше информации перед подготовкой отчета.
---
Кому это вообще может быть полезно
- импортёрам и отделам ВЭД, - таможенным брокерам, которые хотят меньше рутины и больше аргументов, - юристам и комплаенсу, которым важна трассируемость решений, - разработчикам, которые думают не в категориях «подключим ИИ», а в категориях «встроим ИИ в реальную нормативную среду».
---
Что можно сделать прямо сейчас и как помочь проекту
Если вам откликается тема классификации ТН ВЭД:
- можете пощупать демо-бота в Telegram:,
- прислать сложные кейсы описаний товаров,
- поделиться ссылками на полезную нормативную документацию и открытые источники, которые стоит добавить в базу.
По сути, я сейчас занимаюст обучением базы знаний, которую затем можно встраивать в любую LLM-инфраструктуру — от внутреннего корпоративного решения до кастомных сервисов.
А дальше — как всегда: сначала ты приводишь в порядок описания, потом — базу нормативки, а потом удивляешься, почему на таможне вдруг стало гораздо меньше сюрпризов.