474 712 строк за 35 лет: как мы с LLM и 21 экспертом приводим в порядок справочник автосервиса

Это не битая кодировка и не ошибка миграции. Это настоящее название работы из нашего справочника. За 35 лет в нём накопилось 474 712 строк: сокращения, дубли, опечатки, разные языки и разные варианты одной и той же операции.

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

Мы столкнулись с этим при разработке Dealer Digital Platform «Флора». Проект ещё не завершён, но основную часть нормализации уже прошли: дедуплицировали массив, дважды провели его через экспертную проверку и для 96,13% работ после дедупликации подтвердили корректный узел.

Я решил рассказать об этом сейчас, не дожидаясь финального релиза: основные грабли уже случились. Мы отказались от полнотекстового поиска, несколько раз перестроили работу LLM и экспертов, научились возвращать экспертный фидбек в правила и skills агента и ошиблись больше чем втрое в оценке производительности на одной из задач.

Если вы работаете с историческими справочниками, master data или LLM-классификацией, значительную часть этого опыта можно перенести и за пределы автобизнеса.

Привет, Хабр

Меня зовут Владимир Терехин, я руководитель продуктового портфеля в РОЛЬФтех. В моей зоне ответственности в том числе продукты для Сервиса. Под Сервисом здесь я имею в виду направление послепродажного обслуживания автомобилей в дилерских центрах: запись клиента, приёмку автомобиля, диагностику, ремонт, работы, запчасти и другие процессы вокруг заказ-наряда.

Поэтому эту историю я знаю изнутри: мы начинали с интервью с пользователями и аналитиками, потом несколько раз меняли технический подход, подключали экспертов дилерских центров и сейчас готовим результат к внедрению во «Флору».

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

Золотая жила и её обратная сторона

За 35 лет компания накопила большую оцифрованную историю машинозаездов. Для аналитики и продуктовой разработки это очень ценный актив: можно смотреть реальные заказ-наряды, частотность работ, связки с автомобилями и запчастями, а не строить продукт только на интервью и предположениях.

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

Анатомия хаоса

Под «работой» мы понимаем сервисное или ремонтное действие над автомобилем или его узлом: заменить масло, снять фару, покрасить дверь, провести диагностику.

Сам принцип простой. В голове всё сошлось — пока не открываешь старый справочник.

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

Например:

НАР РУЧКУ ДВЕРЬ РАСПАШ З ПР С/У

РАМА КРЫШИ НАР ПР ОКР НОВ

SETR CRE52

добавить для автомобилей с ГУР

Дополнительная операция

Мастер-консультант, который много лет работает с маркой, часто понимает такие строки по контексту. Он знает внутренние сокращения, устройство автомобиля и то, как его коллеги привыкли заводить работы.

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

Почему это стало проблемой

Первая боль — специалист по записи клиентов (СПЗ) и, следом, сам клиент.

СПЗ принимает звонок или заявку и должен быстро подобрать работу под конкретный автомобиль, оценить нормо-часы и дать клиенту понятную консультацию. При этом он не обязан обладать той же технической насмотренностью, что мастер-консультант (МК). У МК может быть десять или двадцать лет практики по конкретным брендам: он считывает сокращение и понимает, какой узел имелся в виду.

Не понял старое название — приходится идти к более опытному коллеге и уточнять.

Вторая боль — аналитики. Если одна операция записана десятками способов, запрос «покажи динамику замен передних тормозных колодок» сначала превращается в ручную работу по сбору вариантов названий. Причём можно просто не знать, что какая-нибудь странная строка из старой системы означает ту же операцию.

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

Причём к справочнику узлов мы пришли не сразу. До этого обсуждали и проверяли другие гипотезы: например, группировать работы по смыслу или сразу преобразовывать старые названия в понятный для СПЗ вид. Уже позже именно дерево узлов стало отправной точкой всей конструкции.

Шаг 1. Привязать каждую работу к узлу автомобиля

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

Автомобиль → Двигатель → Система смазки → Масляный фильтр

Звучит довольно понятно и вроде несложно — осталось сделать.

Сначала попробовали полнотекстовый поиск

LLM в начале проекта не была базовым решением. Первым техническим подходом стал полнотекстовый поиск.

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

На реальных строках проблема выглядела так. Здесь «правильный» узел — не наше мнение: эксперты Сервиса забраковали результаты полнотекста и подтвердили варианты, которые мы получили в подходе с LLM.

База антенны аудиосистемы — снятие-установка

Полнотекст → Аудиосистема
LLM → Антенна в сборе

Выключатель подогрева сиденья снять и установить

Полнотекст → Подогрев сидений
LLM → Прочее переключатели, кнопки

ХРОМИРОВАННАЯ НАКЛАДКА РЕШЕТКИ РАДИАТОРА

Полнотекст → Решетка радиатора
LLM → Накладки

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

Подход остановили, подключили BE Lead и начали экспериментировать с LLM.

Сначала сократили сам массив

В исходном справочнике было 474 712 строк. Отправлять их все в разметку не имело смысла: в данных было много дублей.

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

Например, Окантовка решетки радиатора — замена встречалась 13 раз. Название одно, но одна запись могла быть связана с BMW, другая с Renault и так далее.

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

Подход №1: цель 40%, факт 40,1%

Заранее понимали, что одним проходом не обойдёмся, но практического опыта и бенчмарков по такой задаче у нас не было. Поэтому цели 40%, 80% и 95% поставили экспертно, отталкиваясь в первую очередь от сроков проекта.

Для первого подхода 40% казались амбициозной целью — пессимистично держали в голове 30%. Гипотеза была такой: если первым проходом подтвердим хотя бы 40% справочника, то на ошибках и развивающей обратной связи во втором сможем сделать как минимум сопоставимый объём. Третий подход закладывали под самый сложный хвост — нераспред и работы, для которых понадобятся отдельные правила.

Проверили несколько моделей и конфигураций Harness на небольших выборках. Результаты показывали стейкхолдеру Сервиса и сравнивали по доле корректных привязок. В основной прогон взяли конфигурацию, которая на этих замерах дала лучший результат и была подтверждена стейкхолдером.

Технически мы работали не только с LLM, а использовали Harness — в нашем случае Claude Code. Кроме самой модели в контуре были инструменты (tools), skills — специализированные навыки агента, правила работы и другие доступные ему возможности. Дальше для простоты я всё же буду использовать термин LLM: акцент статьи скорее на подходе к решению бизнес-задачи, чем на устройстве агентной среды.

На старте экспериментировали локально с gemma-3-12b-it-GGUF, но основной результат получили уже в облаке. По ходу проекта использовали Claude Opus 4.7 и 4.8, Sonnet 4.6 для массовой разметки, Opus для проверки, на одном из этапов GPT-5.5 вместе с Opus, позже — Opus 5.

Для каждой из 247 595 работ модель предложила узел. После этого весь массив проверяли внутренние эксперты — мастера-консультанты и инженеры по гарантии из дилерских центров. На пике в проекте участвовал 21 человек.

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

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

В первом проходе эксперты подтвердили 40,1% привязок — при цели 40%.

В первом подходе эксперт только помечал ошибочную привязку и не назначал новый узел. Поэтому после проверки у нас оставались 59,9% работ с ошибочной связкой, которые нужно было переразметить.

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

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

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

Подход №2: меняем и разметку, и проверку

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

Экспертам дали полный справочник узлов. Если эксперт видел ошибку, он выбирал корректный узел из справочника и добавлял его к работе.

Если работа была вне его профессиональной области — например, эксперт слесарного цеха получал кузовную работу — он ставил отметку «не знаю». Такие строки мы собирали отдельно, искали профильных экспертов и передавали им на разметку.

Полный справочник сделал проверку содержательнее, но скорость просела примерно с 2 000 до 1 200 работ на человека в день.

Тогда рядом с основной привязкой начали показывать несколько релевантных узлов-подсказок. Эксперту уже не нужно было каждый раз начинать поиск с нуля, и темп вернулся примерно к 2 000 работам в день.

Постановка для модели тоже стала жёстче. Например, ранняя версия выглядела примерно так:

Проанализируй 500 автомобильных работ и классифицируй их по узлам.

Для каждой работы:
— проанализируй название;
— выбери узел из списка;
— если компонент непонятен — используй поиск;
— верни результат в JSON.

Позже появились ограничения:

node_dictionary — единственный допустимый справочник узлов.

Запрещено придумывать узлы вне словаря.

Если термин или код неизвестны — сначала проверь значение.
Если узел определить нельзя — верни "Неразмеченные".
Если есть сомнения — верни несколько альтернативных узлов.

В технической версии промпта появились закрытый словарь, обязательная проверка незнакомых терминов, возможность отказаться от назначения и альтернативные узлы.

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

Мы постепенно перестроили сам Harness: добавили специализированные skills для работы со справочником, формализовали правила выполнения и проверки задач, ввели аудиты результатов и отдельно занялись управлением контекстом. В частности, перестали допускать заполнение контекстного окна больше чем примерно на 70%: по нашим наблюдениям, на длинном контексте качество начинало заметно деградировать и росло количество галлюцинаций.

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

Параллельно запретили повторять уже забракованные связки, дали экспертам полный справочник, подсказки и отдельный маршрут для работ с отметкой «не знаю».

В первом проходе эксперты подтвердили 40,1% массива. Во втором провалидировали ещё 56,03 процентного пункта. В результате корректный узел получили 238 017 из 247 595 работ после дедупликации — 96,13%. Оставшиеся 9 578 ушли в архив.

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

Параллельно разбирали нераспред

Пока эксперты проверяли привязки, отдельно работали с тем, чему узел вообще не нашёлся.

На одном из этапов таких записей оставалось 17 356. Вместе со стейкхолдером Сервиса разбирали классы и формулировали отдельные правила.

Тут выяснилось, что не всё нераспределённое — мусор.

Например:

Буксировка автомобиля

Приёмка автомобиля

Оценка стоимости автомобиля

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

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

Итого после дедупликации и чистки получили 238 017 активных работ.

Почему не embeddings + kNN

Embeddings и kNN — метод k ближайших соседей — тоже проверяли.

На небольшом gold-наборе из 141 пары deepvk/USER-bge-m3 дал F1 0,403, BAAI/bge-m3 — 0,369, а TF-IDF на символьных n-граммах — 0,531.

На наших коротких строках с сокращениями и опечатками совпадение фрагментов слов оказалось полезнее чистой семантической близости.

kNN оставили вспомогательным инструментом: правила дали 2 204 автоматических назначения, kNN — ещё 742, а 3 283 работы потребовали ручного ревью.

Хотя на другой задаче, с названиями запчастей, результат был обратным: гибрид TF-IDF и embeddings дал F1 0,619 против 0,531 у одного TF-IDF.

Поэтому от embeddings мы не «отказались». Просто не сделали их главным инструментом там, где наши же замеры этого не подтверждали.

Прямые расходы на доступ к облачным моделям были порядка €150 в месяц в течение семи месяцев.

Работа основной команды и 21 эксперта стоила существенно дороже. По понятным причинам зарплаты коллег здесь не раскрываю.

Шаг 2. В поисках глагола

Одного узла для аналитики недостаточно. Знать, что работа относится к тормозному диску, полезно, но нужно ещё понимать, что с ним делали: меняли, диагностировали, снимали, устанавливали, чистили.

Стейкхолдер Сервиса сначала собрал справочник из 65 воздействий: например, Установка, Замер, Чистка. Мы наложили его на реальные работы и увидели, что часть воздействий фактически не используется или пересекается по смыслу с другими. После анализа и согласования оставили 43 воздействия.

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

Шаг 3. Новый уровень справочника

Следующая задача — собрать из узла и воздействия понятное эталонное наименование:

Масляный фильтр + Замена

Крышка багажника + Снятие и установка

Тормозной диск + Замена

Но старый справочник мы не уничтожаем. Во «Флоре» хотим оставить два уровня: первый — эталонные и понятные названия для поиска и аналитики, второй — связанные с ними исторические работы.

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

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

Для СПЗ это позволит искать понятную «Замена тормозных колодок», а ниже уже подобрать ту историческую работу, которая соответствует BMW X4 нужной конфигурации и содержит необходимые нормо-часы.

Шаг 4. Связать работы с запчастями

Для консультации одной работы и нормо-часов недостаточно — нужны запчасти.

Мы взяли историю заказ-нарядов и для каждой работы начали смотреть, какие запчасти (ЗЧ) чаще всего встречались вместе с ней.

Порог подбирали на данных: пробовали 90%, 70%, 40% и 30%. В итоге вместе со стейкхолдерами и экспертами остановились на 50%.

В нашем случае это означает следующее: если работа встретилась, например, в 100 заказ-нарядах, запчасть должна встретиться вместе с ней минимум в 50 из них, чтобы попасть в кандидаты на связь.

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

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

На наших данных порог 50% дал наиболее приемлемый результат по оценке стейкхолдеров и профильных экспертов.

Precision/recall по каждому порогу отдельно мы не фиксировали: сравнивали результаты на выборках вместе со стейкхолдерами и профильными экспертами.

Но это не автоматическое подтверждение связи. Если запчасть проходит порог, она только попадает в кандидаты. Финальное решение принимает эксперт.

Для этого мы навайбкодили простой интерфейс. Профильный МК видит автомобиль, работу и список кандидатных ЗЧ и убирает лишнее.

И здесь мы ошиблись в оценке производительности.

На валидации связки «работа → узел» эксперт проходил около 2 000 работ в день. Мы взяли эту выработку как бенчмарк и ожидали примерно того же при проверке связок «работа → ЗЧ».

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

К декабрьскому запуску пройти весь справочник таким способом мы уже не успеваем.

Поэтому поменяли стратегию: идём по брендам и по частотности — сначала TOP-1000 работ, затем TOP-2000 и дальше. Проверяют связки профильные мастера-консультанты именно по своим брендам.

Сейчас запчастями покрыто около 15% работ, но на них приходится примерно 80% заказ-нарядов. Поэтому дальше идём по частотности.

Где мы находимся сейчас

Для аналитиков уже появилась структурированная фактура: вместо набора исторических строк можно работать с узлом, а после валидации воздействий — со связкой «узел + воздействие». Сейчас ждём финальную проверку на их реальных сценариях.

По СПЗ цифр эффекта пока нет: новый справочник ещё не внедрён во «Флору». Первые демо дали полезную обратную связь, но выдавать её за изменение времени консультации или качества работы мы не хотим.

Следующий этап — UX-исследование со СПЗ, затем внедрение новых данных во «Флору» и релиз в декабре 2026 года.

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

Мы уже проделали большой объём работы. Пользовательский результат ещё предстоит доказать.

Что бы я сделал иначе

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

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

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

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

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

Поэтому во «Флоре» закладываем репорт прямо из интерфейса МК и СПЗ. Если сотрудник видит подозрительную работу или связь, он в пару кликов отправляет замечание. Задача попадает группе модераторов, которые либо исправляют справочник, либо возвращают объяснение, почему текущая связь корректна.

В итоге справочник будет дочищаться по мере реального использования.

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

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

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

Но это не совсем так.

После первого подхода с 40,1% у меня ещё оставались сомнения, насколько далеко вообще получится зайти с LLM на таких данных. Поэтому результат второго подхода стал, наверное, главным сюрпризом проекта: он оказался выше даже наших самых амбициозных ожиданий.

При этом за 13 месяцев я окончательно убедился, что LLM — хороший помощник на больших массивах данных, но сам по себе он нужный результат не даёт. Чтобы его получить, нам пришлось потратить много времени на экспертную обратную связь, правила, skills, управление контекстом и сам процесс проверки.

Следующий этап — закончить проверки, провести исследование со СПЗ и довести новый справочник до релиза «Флоры» в декабре.

А после этого появится самое интересное — продуктовые цифры из реальной эксплуатации.