Почему LLM не заменит хороший парсер. Кейс с автозапчастями

Ко мне пришёл клиент с задачей, которая на старте выглядит почти наивно простой — настолько, что даже немного подозрительно.

Есть каталог: больше 50 000 позиций, и он не стоит на месте, а постоянно разрастается за счёт поставщиков, которые живут в своём ритме и не особенно переживают о единообразии названий. С другой стороны — поток заказов, где никакой структуры уже нет и в помине: кто-то пишет артикул, кто-то модель автомобиля, кто-то пытается описать проблему человеческим языком, а кто-то ограничивается чем-то вроде “нужны передние колодки на ауди а4 б8 срочно”, как будто система обязана всё это понять по интонации.

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

И на этом фоне неизбежно возникает первое и самое очевидное предложение: давайте подключим LLM, пусть она всё это “понимает”.

Где эта идея ломается

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

Возьмём простые примеры. Oil filter 2.0L diesel Audi A4 и Oil filter 2.0L petrol Audi A4 — с точки зрения языковой близости это почти одно и то же описание, различие выглядит косметическим, уточняющим, таким, которое модель вполне может “усреднить” как малозначимое. Но в реальности это уже две разные физические сущности, и ошибка здесь не превращается в небольшое несоответствие, она превращается в несовместимость.

То же самое с тормозными дисками: Audi A4 B7 brake disc 280x22 и Audi A4 B8 brake disc 280x25 выглядят почти идентично, особенно если смотреть на них как на текст. Разница в три миллиметра толщины в семантическом пространстве почти исчезает, растворяется в общей похожести, но в инженерной реальности именно эта разница и является ключевой, разделяющей “подходит” и “не подходит вообще”.

И вот здесь важно зафиксировать момент: модель не ошибается в привычном смысле. Она просто делает то, что у неё получается лучше всего — находит близкое по смыслу. Проблема в том, что здесь смысл вообще не является главным измерением.

Векторный поиск и аккуратная иллюзия близости

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

На практике всё упирается в ту же фундаментальную вещь: векторное пространство хорошо работает там, где “похожесть” действительно означает полезную близость, но начинает давать сбои в тех местах, где важны жёсткие различия по конкретным параметрам. Оно прекрасно сближает front brake pads и “передние колодки”, потому что там действительно совпадает смысл, но оно же так же уверенно сближает 280x22 и 280x25, потому что для него это просто два очень похожих набора символов, а не два взаимоисключающих инженерных параметра.

И в какой-то момент становится очевидно, что вся эта семантическая близость начинает работать против задачи: система начинает находить “почти правильное”, а в этой предметной области почти правильное обычно означает неправильное.

Попытка “просто обучить свою модель”

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

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

И вот здесь обычно и начинается реальность. Данных либо нет, либо их недостаточно, либо они шумные и неполные, а попытка довести их до нужного качества превращается в отдельный долгий проект, который по сложности начинает конкурировать с самой задачей. Ирония в том, что в этот момент “простое ML-решение” внезапно становится дороже, чем аккуратно написанные правила.

Что на самом деле нужно делать

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

Из строки вроде Brake disc ventilated front R 280x25 Audi A4 B8 нужно извлечь не “смысл”, а структуру: тип детали, исполнение, позицию, размеры, модель и поколение. После этого поиск превращается в обычное сравнение параметров, где либо совпадает, либо нет, либо допускается строго заданный диапазон, если бизнес-логика это разрешает.

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

Где LLM действительно уместен

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

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

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

И это, пожалуй, главный момент во всей этой истории.

Вместо вывода

В подобных задачах почти всегда есть соблазн найти “более умную модель”, которая сама разрулит сложность. Это понятное желание — оно экономит время на неприятной части работы, где приходится разбираться не с технологиями, а с предметной областью.

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

И иногда самый неинтересный инструмент оказывается единственным, который действительно работает.