Привет! Я Александр Жариков, архитектор сервисов анализа информации СКАН, Группа «Интерфакс». Последние 15 лет я занимаюсь алгоритмами, которые читают тексты и извлекают из них смысл. Вопрос, который дал название этой статье, не так давно задал мне студент после моего доклада. И он далеко не такой наивный, как кажется на первый взгляд. Если у вас есть собственное NLP-ядро, которое вы развивали полтора десятка лет, – это актив или уже балласт в эпоху LLM? В этой статье я разбираю, почему специализированные алгоритмы все еще выигрывают на промышленных объемах у универсальных языковых моделей и где LLM действительно усиливают наше ядро, а не заменяют его. Я не буду писать о конкретных алгоритмах и используемых нейросетях – я опишу лишь общие подходы в стиле популяризации компьютерной лингвистики и порассуждаю об алгоритмическом NLP.
В период бурного развития искусственного интеллекта большинство людей ассоциирует ИИ прежде всего с продуктами компаний OpenAI, Anthropic и Google или с другими нейросетями, появившимися на рынке за последние несколько лет. Массовый интерес к таким технологиям действительно возник сравнительно недавно – после выхода ChatGPT в ноябре 2022 года.
Однако алгоритмы искусственного интеллекта начали приносить практическую пользу задолго до этого. Сегодня большинство компаний внедряют ИИ для оптимизации процессов, повышения качества сервиса и снижения операционных затрат. Но есть и системы, в которых подобные технологии изначально были заложены в архитектуру продукта. К таким относится и СКАН-Интерфакс, система для мониторинга СМИ и соцмедиа. Алгоритмы анализа данных используются в ней с 2008 года.
Само понятие ИИ значительно шире представления о нем как о нейросетях. Любая автоматизированная обработка текстов и структурирование текстовой информации – это ИИ, а способ решения может быть любым: правила, классическое ML, нейросети, LLM – это инструмент, один из способов решения задачи.
В этой статье я ставлю вопрос с неочевидным ответом: где мы в эпоху ИИ и как вообще такие системы должны развиваться, чтобы иметь будущее?
Я думаю, среди читателей будут и те, кто знает историю ABBYY с их огромным лингвистическим ядром, в итоге проигравшим ИИ. Уже в далеком 2016 году наш проект участвовал в конкурсе по решению одной из классических задач компьютерной лингвистики – Named Entity Recognition – и показал результат, сопоставимый с лидерами – специалистами ABBYY. Наши алгоритмы и подходы были похожи: огромные семантические словари, правила, синтаксический анализатор, но их команда – в 20 раз больше, а задачи шире. В 2024-м ABBYY распустила команду лингвистов и перестала решать задачи NLP самостоятельно. А мы – нет, и пока процветаем. Мы правы или нет, развивая собственное NLP-ядро? На что мы рассчитываем? На что рассчитываю лично я как архитектор NLP-системы, которую придумывал в течение 15 лет?
Вопрос, с которого все началось
Недавно я выступал перед студентами-философами с рассказом про свой проект. После доклада один из них спросил: «Зачем вообще нужна ваша система, если я могу задать все вопросы ChatGPT?».
Действительно, если набрать в диалоге с ChatGPT: «Проанализируй репутационные риски компании X» или «Дай оценку PR-активности компании Y», вы получите грамотный и структурированный ответ – весьма достойный на первый взгляд.
Но специалисты, которые решают такие задачи ежедневно, работают не с синтетическими примерами. С условным ChatGPT они все, конечно, умеют взаимодействовать и, тем не менее, покупают доступ к нашей системе. Понятно, что клиенты выбирают не конкретный способ решения NLP-задач (они вообще не думают о компьютерной лингвистике), а Enterprise B2B-систему. Однако в этой статье я рассуждаю именно о лингвистической составляющей успеха.
Итак, в техническом аспекте клиентам нужно быть уверенными, что система учла все публикации за период, а не только ограниченную выборку, быстро подтянула статьи после их публикации и дала ответ независимо от объекта интереса (анализируемой компании, бренда). Например, под названием «Северсталь» в конкретной публикации может упоминаться и металлургический холдинг, и хоккейный клуб. Задача такой идентификации упоминаний с организациями, персонами и регионами физического мира по контексту в NLP называется Entity Linking. Кроме того, клиенту важна тональность и вычленение из текстов конкретных событий (Fact Extraction). То есть обеспечение потребности клиента глобально распадается на инфраструктурную задачу (оперативность, полнота базы) и лингвистическую (Entity Linking и Fact Extraction). Инфраструктурная составляющая сразу отметает опцию «просто использовать ChatGPT», но оставляет возможность в теории написать систему сбора данных, а всё лингвистическое ядро уже сделать на LLM и других готовых моделях. Соответственно и передо мной, как перед архитектором, стоит выбор – забыть имеющееся NLP-ядро и переделать всё с нуля на современных технологиях ИИ или сохранять ядро, а осовременивать точечно изнутри.
Всё переделать – всегда большой риск из-за больших инвестиций, но не переделать – потенциальный риск проигрыша стартапу или конкуренту, который выберет такой подход. В этой статье я рассуждаю, почему выбираю не переделывать. И сразу четко озвучу гипотезу, которую защищаю: грамотный комбинированный подход без тотальной переделки обеспечивает качество настолько высокое, что обгон его любым подходом не даст конкурентного преимущества в бизнесе, при этом эксплуатация комбинированного подхода очень дешева и не может быть оптимизирована в существенном для бизнеса объеме.
Рассуждать я буду на примере задачи Entity Linking. Это ядро нашего продукта – мы фактически продаем результаты решения этой задачи – в том числе напрямую через API. Для анализа PR или рисков требуется очень высокое качество решения: больше 95% и по полноте (recall), и по точности (precision). Ответ ChatGPT учитывает не все публикации и решает задачу Entity Linking с неизвестным качеством. Если нет полного состава публикаций, то нет метрик, зато есть риск пропустить важное. Кроме того, специалистам нужно быть уверенными, что, скажем, вчерашний пост в Телеграме о сбросе отходов уже привязан к юрлицу, классифицирован как экологический риск и попал в алерт до того, как тему подхватили федеральные СМИ. То есть нужно промышленное решение на больших объемах.
На вопрос от студента я дам еще и альтернативный ответ от одного из соискателей на должность главы ML. Суть его предложения сводилась к следующему: «Платите мне 3 млн рублей в месяц и еще миллион рублей в день за LLM, и ваша задача будет решена, а отдел компьютерной лингвистики можно будет распустить». Только вот мы бы разорились, а без такого подхода – нет.
Что делает СКАН
Каждые сутки в СКАН-Интерфакс – систему мониторинга СМИ и соцмедиа – попадает около 500 000 публикаций из интернет-СМИ, соцсетей, ТВ, радио и прессы. СКАН решает две категории задач.
Мониторинг рисков. Банку нужно знать, что его контрагент стал участником судебного разбирательства. Энергетической компании важно вовремя получить информацию о том, что подрядчик фигурирует в экологическом расследовании. Счет идет буквально на часы: чем раньше принят сигнал, тем больше шансов минимизировать ущерб.
Мониторинг репутации и PR. Пиар-специалисту нужно видеть все упоминания бренда или персоны, понимать их тональность, а также оценивать эффективность своих активностей. При этом каждая компания измеряет PR по своим показателям, а репутационный риск для ритейлера и для авиаперевозчика – это разные категории рисков.
500 000 публикаций, 20 миллионов юрлиц и задача, которую нельзя решить промптом
Разберу одну задачу – связывание сущностей (то самое Entity Linking). Алгоритм определяет, какой объект реального мира стоит за упоминанием в тексте. В нашем случае – какое юрлицо из базы, насчитывающей 20 миллионов организаций.
Как работает каскад
В ленту СКАНа попадает статья с упоминанием организации «Рога и Копыта». Это небольшая компания, в СМИ появляется нечасто и обычно с полным названием. Алгоритм находит строку в тексте (задача NER) и дальше определяет, какое именно это юрлицо, поскольку в базе их может быть несколько. Смотрит контекст: упоминается руководитель – берем результат NER для персоны из контекста и сверяем с ЕГРЮЛ; упоминается город – определяем, что за город (снова Entity Linking и снова похожая цепочка – задача NER уже решена, поискать, какие города, села и области есть рядом, чтобы снять неоднозначность через взаимные связи).
Рассмотрим другой масштаб компании: название «Северсталь» без уточнений. Речь идет о ПАО «Северсталь» или о хоккейном клубе «Северсталь»? Алгоритм анализирует тематику источника, снова соседние сущности (не спортсмены ли?), ключевые слова и т.п. Это в общих чертах, а в реальности в алгоритмах много статистики, логических ветвлений, учитывается встречаемость имен персон, население и упоминаемость населенных пунктов, контекстная связанность объектов, множество семантических словарей с неустаревающими данными о семантике типов организаций, регионов и персон и т.д. и т.п. Это классический legacy-трудноподдерживаемый код, но работает он с некоторым базовым качеством.
Получается, что у нас есть тот самый то ли актив, то ли балласт – развивавшийся с 2009 до 2020 года каскад правил на сотни тысяч строк кода и гигабайты семантических словарей и баз знаний. В результате мы получаем относительно высокую точность и полноту без единого вызова нейросети для Entity Linking.
А что значит высокое качество? И какое нужно? Если оценивать в среднем, мы получим некую оценку, с которой не совсем ясно, что делать. Нам важно, чтобы клиенты могли на основе этих данных решать свои задачи. А клиенты разные и задачи у них разные. Для ООО «Рога и Копыта» – одно качество из коробки, для «Северстали» и PR хоккейного клуба – другое базовое качество и другие требования, для НК «Роснефть» (нет неоднозначности) – третий вариант и т.д.
В результате параллельно с развитием каскада правил в 2010-2020-х годах развивались и методы ручной коррекции результатов под клиента. Из коробки плохое качество по «Северстали»? Пожалуйста, сейчас докрутим – изменим баланс между значимостью признаков для этого объекта, добавим какие-то разрешающие неоднозначность признаки, а какие-то уберем на основе изучения контекстов упоминаний – то есть донастроим алгоритм конкретно для этого юрлица, не затронув другие объекты.
Чем сложнее задача идентификации конкретного объекта, тем дольше его донастраивать вручную. Но за то или иное количество усилий донастроить можно до желаемого качества (для большинства задач это обычно > = 99% полноты и точности). Таким образом, достижение требуемого качества под клиента конвертируется в некое измеримое количество ресурсов (стоимость эксплуатации инфраструктуры + стоимость ручной донастройки). Причем эта стоимость укладывается в нашу бизнес-модель: качество получается достаточным, и проект генерирует прибыль.
Конечно, Entity Linking – это не все задачи NLP в проекте, и сам он использует решение задачи NER. Но я здесь фокусируюсь именно на Entity Linking как на ярком и редко упоминаемом примере, который промышленно мало кто делает.
Экономика LLM-подхода «в лоб»
Теперь посчитаем экономику подхода в лоб. Допустим, я стартапер, который верит, что «LLM может всё». Пусть публикация содержит в среднем 10 сущностей и около 200 слов. Для идентификации каждой сущности нужен контекст – описание «кандидатов» из базы, допустим тоже по 200 слов. Среднее количество кандидатов по одному названию – около двух (в реальности от одного до тысяч).
Итого: системный промпт 500 токенов + публикация 200 слов + 10 сущностей X 2 кандидата X 200 слов + небольшой выход = ~4500 слов кириллицей = 9000 токенов.
При этом для поддержания качества нужно около 200 000 публикаций в сутки и пропускная способность 15 000 публикаций в час (в прайм-тайм) – это если реальный поток предварительно кластеризовать и отправлять в LLM не всё, а только 30% публикаций. Итого требуется минимум 1,8 млрд токенов в сутки и пропускная способность 2,25 млн токенов в минуту.
Теперь берем самую дешевую и легкую модель (самая дешевая из современных у Claude – Haiku 4,5), которая даже вряд ли выиграет по качеству у проработанной алгоритмической системы (не проверял на большой выборке), и получаем очень грубую оценку стоимости в $1800/день только на Entity Linking + высокие требования к пропускной способности.
Наша инфраструктура – 30 ядер CPU и 150 ГБ RAM в облаке – это вся лингвообработка целиком. Стоимость составляет порядка 0,01 рубля за публикацию и около 6000 рублей в день даже на всем потоке, а не на 30%. То есть тут выигрыш стоимости на два порядка компенсирует грубость расчетов.
Понятно, что есть и другие подходы к Entity Linking, но это уже про реализацию на нашей стороне, а не про «использовать API, а эмэльщиков уволить».
Где LLM действительно нужна
Донастройка
Я специально выше немного утрированно обрисовал ситуацию: LLM и DL против уже написанных алгоритмов – точно дороже, даже если достигают нужного качества. А мы достигаем его ручной донастройкой алгоритмов. Вывод лежит на поверхности: LLM может заменить саму ручную донастройку и при правильном применении будет дешевле и надежнее.
Работу, которую раньше делал специалист вручную, – анализ ошибок, выявление паттернов, формулировка правил, мониторинг качества – теперь может выполнять языковая модель. Она просматривает случаи, где алгоритм ошибся, анализирует контекст и предлагает поправки.
Таким образом, я формулирую гипотезу, которую мы в продукте проверяем сейчас. Алгоритмический NLP-код – все же не балласт, а ценнейший ресурс, который дает возможность использовать LLM вместо ручного труда для точечной донастройки и решить клиентскую задачу дешево – дешевле, чем мы решаем ее сейчас, и намного дешевле, чем без имеющихся алгоритмов и экспертизы.
Fact Extraction и тональность
Вторая область применения LLM – извлечение фактов (Fact Extraction) и определение тональности. Эволюция подходов в нашей системе была постепенной: от правил и шаблонов через обучаемые классификаторы к дообученным нейросетевым моделям. Сегодня в СКАНе у нас гибридный пайплайн: базовые классификаторы и старые лингвистические правила + дообученные DL-модели на сложных кейсах.
Но и здесь главная ценность – в нашем знании предметной области. «Риск» для банка – судебное разбирательство контрагента. «Риск» для авиакомпании – пост пассажира о неисправности. Это разные классы событий, и наше понимание разницы накапливалось и углублялось годами работы с клиентами. Оно встроено в архитектуру и в разметку обучающих данных.
Что все это значит
На рынке можно выделить две заметные категории компаний: те, кто создает универсальные модели (OpenAI, Anthropic и др.), и те, кто внедряет ИИ в свои процессы (чат-бот, автоматизация, генерация контента).
СКАН-Интерфакс относится к третьей, довольно редкой категории. Мы не разрабатываем фундаментальные модели. Мы с самого начала решали задачи ИИ и компьютерной лингвистики, но не универсальные, а специализированные, в узком предметном поле. Сейчас мы – пользователи современного ИИ с 15-летним алгоритмическим ядром и глубокой экспертизой в своей области. Мы точечно интегрируем LLM там, где это дает максимальный эффект (где алгоритмы упираются в потолок) при минимальных затратах, при этом используем каскады правил и Deep Learning и собираемся сохранять эту гибридную архитектуру. При том, что проблема legacy-алгоритмического кода постепенно отходит на второй план из-за появляющихся возможностей ИИ-ассистентов в разработке: ими все равно очень сложно написать аналогичный каскад правил, но зато очень удобно его поддерживать. При этом ядро обеспечивает экономику, стабильность и масштаб, недоступные чистому LLM-подходу.
Я полагаю, что эта модель актуальна и за пределами мониторинга СМИ. Везде, где есть большой поток данных, жесткие требования к точности и конечный бюджет, выигрывает тот, кто умеет комбинировать.
Интересно услышать, кто еще нашел точки, где LLM усиливает классические NLP-пайплайны, а не заменяет их. Если есть похожий опыт – делитесь в комментариях. А если вам интересно строить такие системы – мы в СКАН-Интерфакс ищем людей, которым нравится решать задачи, а не оборачивать API.
ссылка на оригинал статьи https://habr.com/ru/articles/1026422/