Переносимый скилл вместо RAG-стека — кейс генерации регламентов в поддержке
Саммари
В статье описан реальный деплой в customer support, где вместо типового многослойного RAG-конвейера использовали «переносимый скилл»: инструкция на естественном языке плюс лёгкие инструменты (retrieval API и скрипты проверки формата) плюс корпус, обогащённый сгенерированной LLM «навигационной» структурой в стиле Wikipedia. Такой подход занял 1–2 инженеро-дня и дал 99,2% процедурной эквивалентности человеческому эталону и 83,3% достаточности доказательной базы при генерации регламентных шагов решения. Главный честный минус — latency: ~90 с на случай против ~8–9 с у production-ассистента, поэтому claim сознательно ограничен неторопливыми процессами с human review.
Из этого следует, что главный барьер в работе с корпоративными регламентами — не качество embedding-модели, а навигация по корпусу: один сгенерированный индекс поверх документов даёт модели «карту», и сложный retrieval-стек перестаёт быть обязательным.
На практике для поддержки, закупок, кадров и любых процессов, где ответ «в инструкции на 47-й странице»: скилл-подход переносится почти один в один — описать правила поиска, дать ретривал и проверяющие скрипты, оставить человеку финальный review.
Важный нюанс: 99,2% процедурной эквивалентности достижимы только при наличии зрелого корпуса — метод не избавляет от работы по наведению порядка в документах, а делает её единоразовой инвестицией вместо perpetual tuning'а.
Ограничение: задержка ~90 с на случай и обязательный human review делают подход непригодным для реального чата «в момент диалога» — это инструмент подготовки решения, а не автономный бот.