Впервые статья была
опубликована
на Хабре, а здесь мы предлагаем ее адаптированную версию.
Сегодня большинство людей ассоциирует ИИ прежде всего с продуктами компаний OpenAI, Anthropic и Google или с другими нейросетями, появившимися на рынке за последние несколько лет. Массовый интерес к таким технологиям действительно возник сравнительно недавно - после выхода ChatGPT в ноябре 2022 года.
Однако алгоритмы ИИ начали приносить практическую пользу задолго до этого. Сейчас большинство компаний внедряют ИИ для оптимизации процессов, повышения качества сервиса и снижения операционных затрат. Но есть и системы, в которых подобные технологии изначально были заложены в архитектуру продукта. К таким относится и СКАН-Интерфакс, алгоритмы анализа данных в которой используются с 2008 года.
В этой статье мы ставим вопрос с неочевидным ответом: где мы в эпоху ИИ и как вообще такие системы должны развиваться, чтобы иметь будущее?
Уже в далеком 2016 году наш проект участвовал в конкурсе по решению одной из классических задач компьютерной лингвистики - Named Entity Recognition - и показал результат, сопоставимый с лидерами
-
ABBYY. Наши алгоритмы и подходы были схожи: огромные семантические словари, правила, синтаксический анализатор, но их команда - была в 20 раз больше, а задачи шире. Однако в 2024 году ABBYY распустила команду лингвистов и перестала решать задачи NLP самостоятельно. А мы - нет, и пока процветаем. Мы правы или нет, развивая собственное NLP-ядро? И на что мы рассчитываем в ближайшем будущем?
Вопрос, с которого все началось
Действительно, если набрать в диалоге с 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 с неизвестным качеством. Если нет полного состава публикаций, то нет метрик, зато есть риск пропустить важное. Кроме того, специалистам нужно быть уверенными, что, скажем, вчерашний пост в Телеграме о сбросе отходов уже привязан к юрлицу, классифицирован как экологический риск и попал в алерт до того, как тему подхватили федеральные СМИ. То есть нужно промышленное решение на больших объемах.
Что делает СКАН
Каждые сутки в СКАН-Интерфакс попадает около 500 000 публикаций из интернет-СМИ, соцсетей, ТВ, радио и прессы. СКАН решает две категории задач:
Мониторинг рисков.
Банку нужно знать, что его контрагент стал участником судебного разбирательства. Энергетической компании важно вовремя получить информацию о том, что подрядчик фигурирует в экологическом расследовании. Счет идет буквально на часы: чем раньше принят сигнал, тем больше шансов минимизировать ущерб.
Мониторинг репутации и PR.
Пиар-специалисту нужно видеть все упоминания бренда или персоны, понимать их тональность, а также оценивать эффективность своих активностей. При этом каждая компания измеряет PR по своим показателям, а репутационный риск для ритейлера и для авиаперевозчика - это разные категории рисков.
500 000 публикаций, 20 миллионов юрлиц и задача, которую нельзя решить промптом
Разберем одну задачу - связывание сущностей (то самое Entity Linking). Алгоритм определяет, какой объект реального мира стоит за упоминанием в тексте. В нашем случае - какое юрлицо из базы, насчитывающей 20 миллионов организаций.
Как работает каскад
В ленту СКАНа попадает статья с упоминанием организации «Рога и Копыта». Это небольшая компания, в СМИ появляется нечасто и обычно с полным названием. Алгоритм находит строку в тексте (задача NER) и дальше определяет, какое именно это юрлицо, поскольку в базе их может быть несколько. Смотрит контекст: упоминается руководитель - берем результат NER для персоны из контекста и сверяем с ЕГРЮЛ; упоминается город - определяем, что за город (снова Entity Linking и снова похожая цепочка - задача NER уже решена, поискать, какие города, села и области есть рядом, чтобы снять неоднозначность через взаимные связи).
Рассмотрим другой масштаб компании: название «Северсталь» без уточнений. Речь идет о ПАО «Северсталь» или о хоккейном клубе «Северсталь»? Алгоритм анализирует тематику источника, снова соседние сущности (не спортсмены ли?), ключевые слова и т.п. Это в общих чертах, а в реальности в алгоритмах много статистики, логических ветвлений, учитывается встречаемость имен персон, население и упоминаемость населенных пунктов, контекстная связанность объектов, множество семантических словарей с неустаревающими данными о семантике типов организаций, регионов и персон и т.д. и т.п. Это классический legacy-трудноподдерживаемый код, но работает он с некоторым базовым качеством.
Получается, что у нас есть тот самый то ли актив, то ли балласт - развивавшийся с 2009 до 2020 года каскад правил на сотни тысяч строк кода и гигабайты семантических словарей и баз знаний. В результате мы получаем относительно высокую точность и полноту без единого вызова нейросети для Entity Linking.
А что значит высокое качество? И какое нужно? Если оценивать в среднем, мы получим некую оценку, с которой не совсем ясно, что делать. Нам важно, чтобы клиенты могли на основе этих данных решать свои задачи. А клиенты разные и задачи у них разные. Для ООО «Рога и Копыта» - одно качество из коробки, для «Северстали» и PR хоккейного клуба - другое базовое качество и другие требования и т.д.
В результате параллельно с развитием каскада правил в 2010-2020-х годах развивались и методы ручной коррекции результатов под клиента. Из коробки плохое качество по «Северстали»? Пожалуйста, сейчас докрутим - изменим баланс между значимостью признаков для этого объекта, добавим какие-то разрешающие неоднозначность признаки, а какие-то уберем на основе изучения контекстов упоминаний - то есть донастроим алгоритм конкретно для этого юрлица, не затронув другие объекты.
Чем сложнее задача идентификации конкретного объекта, тем дольше его донастраивать вручную. Но за то или иное количество усилий донастроить можно до желаемого качества (для большинства задач это обычно >
= 99% полноты и точности). Таким образом, достижение требуемого качества под клиента конвертируется в некое измеримое количество ресурсов (стоимость эксплуатации инфраструктуры + стоимость ручной донастройки). Причем эта стоимость укладывается в нашу бизнес-модель: качество получается достаточным, и проект генерирует прибыль.
Экономика 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%. То есть тут выигрыш стоимости на два порядка компенсирует грубость расчетов.
Где LLM действительно нужна
Донастройка
Вывод лежит на поверхности: LLM может заменить саму ручную донастройку и при правильном применении будет дешевле и надежнее. Работу, которую раньше делал специалист вручную, - анализ ошибок, выявление паттернов, формулировка правил, мониторинг качества - теперь может выполнять языковая модель. Она просматривает случаи, где алгоритм ошибся, анализирует контекст и предлагает поправки.
Таким образом, я формулирую гипотезу, которую мы в продукте проверяем сейчас. Алгоритмический NLP-код - все же не балласт, а ценнейший ресурс, который дает возможность использовать LLM вместо ручного труда для точечной донастройки и решить клиентскую задачу дешево - дешевле, чем мы решаем ее сейчас, и намного дешевле, чем без имеющихся алгоритмов и экспертизы.
Fact Extraction и тональность
Вторая область применения LLM - извлечение фактов (
Fact Extraction
) и определение тональности. Эволюция подходов в нашей системе была постепенной: от правил и шаблонов через обучаемые классификаторы к дообученным нейросетевым моделям. Сегодня в СКАНе у нас гибридный пайплайн: базовые классификаторы и старые лингвистические правила + дообученные DL-модели на сложных кейсах.
Но и здесь главная ценность - в нашем знании предметной области. «Риск» для банка - судебное разбирательство контрагента. «Риск» для авиакомпании - пост пассажира о неисправности. Это разные классы событий, и наше понимание разницы накапливалось и углублялось годами работы с клиентами. Оно встроено в архитектуру и в разметку обучающих данных.
Что все это значит
На рынке можно выделить две заметные категории компаний: те, кто создает универсальные модели (OpenAI, Anthropic и др.), и те, кто внедряет ИИ в свои процессы (чат-бот, автоматизация, генерация контента).
СКАН-Интерфакс относится к третьей, довольно редкой категории. Мы не разрабатываем фундаментальные модели. Мы с самого начала решали задачи ИИ и компьютерной лингвистики, но не универсальные, а специализированные, в узком предметном поле.
Сейчас мы - пользователи современного ИИ с 15-летним алгоритмическим ядром и глубокой экспертизой в своей области. Мы точечно интегрируем LLM там, где это дает максимальный эффект (где алгоритмы упираются в потолок) при минимальных затратах, при этом используем каскады правил и Deep Learning и собираемся сохранять эту гибридную архитектуру. При том, что проблема legacy-алгоритмического кода постепенно отходит на второй план из-за появляющихся возможностей ИИ-ассистентов в разработке: ими все равно очень сложно написать аналогичный каскад правил, но зато очень удобно его поддерживать. При этом ядро обеспечивает экономику, стабильность и масштаб, недоступные чистому LLM-подходу.
Мы полагаем, что эта модель актуальна и за пределами мониторинга СМИ. Везде, где есть большой поток данных, жесткие требования к точности и конечный бюджет, выигрывает тот, кто умеет комбинировать.
Попробуйте технологии
SCAN
в деле
