Представьте футбольного тренера, который перед каждым матчем просматривает записи всех предыдущих игр своей команды за последние несколько лет. Игр – сотни. Записей – тысячи часов. Задача: быстро найти момент, когда конкретный игрок забил гол с угла поля в дождь, под давлением защитника слева. Можно, конечно, сначала аккуратно разложить все записи по папкам, пронумеровать, составить каталог – это займёт недели. А можно научиться быстро искать по смыслу и находить нужное за секунды, даже если записи хранятся вразброс. SmartSearch – это именно второй подход. И он работает лучше.
Зачем ИИ нужна «долгосрочная память»
Когда вы разговариваете с голосовым ассистентом или чат-ботом на протяжении нескольких недель или месяцев, между вами накапливается огромный массив информации. Вы упоминали своё имя, рассказывали о работе, жаловались на погоду, обсуждали планы на отпуск. Хороший помощник должен всё это помнить – и уметь использовать в нужный момент.
Но вот в чём проблема: диалоги длинные, информация в них перемешана, а контекст, который помощник может «держать в голове» одновременно, ограничен. Большие языковые модели – те самые нейросети, которые умеют генерировать текст – имеют так называемый лимит токенов. Токен – это примерно слог или короткое слово. Если диалог слишком длинный, модель просто не может обработать его целиком за один раз.
Это как пытаться прочитать роман в 800 страниц, когда тебе разрешено держать в руках только 50 страниц единовременно. Нужно выбрать, какие именно страницы взять – и не ошибиться.
Именно поэтому исследователи в области искусственного интеллекта давно занимаются разработкой систем разговорной памяти – механизмов, которые умеют из длинной истории диалога извлекать только самое нужное и передавать это нужное в модель в нужный момент.
Как это делали раньше: дорого, сложно, но привычно
Традиционный подход к проблеме выглядит примерно так. Когда ассистент ведёт диалог, каждая новая порция разговора немедленно обрабатывается и структурируется. Большая языковая модель читает сырой текст и превращает его в аккуратный набор фактов: «Пользователя зовут Андрей. Он живёт в Москве. Любит джаз. Работает архитектором». Получается что-то вроде досье – красиво, упорядоченно, удобно для поиска.
Потом, когда пользователь задаёт вопрос, система обращается к этому досье и ищет в нём ответ. Иногда используются векторные базы данных – математические пространства, в которых слова и фразы превращаются в числовые координаты, а похожие по смыслу фрагменты оказываются «рядом» друг с другом. Иногда строятся графы знаний – схемы связей между людьми, событиями и объектами, упомянутыми в разговоре.
Всё это звучит красиво. Но у таких подходов есть серьёзные издержки.
- Дороговизна структурирования. Каждый раз, когда поступает новый кусок диалога, его нужно обработать с помощью большой языковой модели. Это требует вычислительных ресурсов, времени и денег – особенно если диалогов миллионы.
- Потеря деталей. Когда мы пересказываем что-то своими словами, мы неизбежно теряем нюансы. То же самое происходит при автоматическом структурировании: тонкие детали, важные оговорки, эмоциональный контекст – всё это может исчезнуть в процессе «перевода» живого диалога в набор сухих фактов.
- Зависимость от обучающих данных. Системы, которые используют обученные модели для поиска, требуют большого количества размеченных примеров. Нет данных – нет нормальной работы.
- Плохая обобщаемость. Модель, настроенная на один тип диалогов, может плохо работать с другим.
Именно на фоне этих недостатков и появился SmartSearch – система, которая решила пойти совершенно другим путём.
SmartSearch: танец без репетиции
Ключевая идея SmartSearch проста и даже немного дерзка: не нужно предварительно структурировать историю диалога. Вообще. Пусть она хранится как есть – в виде сырого текста, как поток живой речи. А когда придёт вопрос, система будет искать ответ прямо в этом потоке, быстро и умно.
Это похоже на опытного музыканта, который не учит партитуру наизусть перед выступлением, а умеет с листа прочитать любую ноту и сыграть её точно в нужный момент. Никакой предварительной подготовки – только мастерство исполнения.
Конвейер SmartSearch состоит из трёх этапов. Разберём каждый из них так, чтобы было понятно даже без инженерного диплома.
Этап первый: найти всё возможное 🔍
Когда пользователь задаёт вопрос, SmartSearch не просто ищет слова из вопроса в тексте диалога. Система сначала выделяет из вопроса именованные сущности – это имена людей, названия мест, даты, организации и другие конкретные объекты. Этот процесс называется распознавание именованных сущностей, или NER (от английского Named Entity Recognition).
Например, если вопрос звучит как «Что Андрей говорил про свою поездку в Санкт-Петербург в прошлом году?», то именованные сущности здесь – «Андрей» и «Санкт-Петербург». Их система выделяет отдельно и при поиске даёт им больший вес, чем обычным словам вроде «говорил» или «поездка».
Затем идёт поиск по подстрокам – то есть буквальный поиск совпадений в тексте истории диалога. Простой, быстрый, надёжный. Никаких нейросетей на этом шаге – только текст и правила.
Результат: система находит все фрагменты диалога, в которых встречаются нужные слова или сущности. На этом этапе лучше найти лишнее, чем пропустить нужное. И SmartSearch справляется блестяще: в ходе исследования выяснилось, что на этапе первичного поиска система находит 98,6% всей релевантной информации. Почти идеальный результат.
Этап второй: расширить сеть 🕸️
Иногда ответ на вопрос не лежит в одном месте. Информация разбросана по нескольким частям диалога, и чтобы собрать её воедино, нужно сделать несколько «шагов».
Представьте: пользователь спрашивает про «лучшего друга Марины». В диалоге где-то упоминается, что «Марина всегда ходит в кино с Катей», а в другом месте – что «Катя недавно переехала в Екатеринбург». Чтобы ответить на вопрос полно, нужно связать эти два фрагмента.
SmartSearch делает это через расширение по сущностям. Система анализирует уже найденные фрагменты, извлекает из них новые имена и объекты – и снова запускает поиск, уже с ними. Этот процесс повторяется несколько раз, как круги на воде: каждый новый шаг расширяет охват, добавляя связанные фрагменты. Правила для этого расширения написаны вручную – никакого обучения, никакой нейросети. Просто логика и грамматика.
Это как в игре «шесть рукопожатий»: от одного человека до другого можно добраться через цепочку знакомств. SmartSearch делает то же самое с информацией.
Этап третий: отсортировать с умом 🎯
Вот мы добрались до самого главного – и самого интересного. После двух предыдущих этапов у системы есть большой набор фрагментов диалога: часть из них точно нужна, часть – вероятно, часть – совсем нет. Нужно выбрать лучшее.
На этом этапе SmartSearch использует два обученных инструмента ранжирования, которые работают в паре.
Первый – ColBERT. Это модель, которая умеет сравнивать запрос и фрагмент текста на уровне отдельных слов. Она не просто смотрит, есть ли совпадение, а оценивает, насколько каждое слово запроса «перекликается» с каждым словом фрагмента. Это гораздо точнее, чем просто считать количество совпадений. ColBERT работает быстро и справляется с большим числом кандидатов.
Второй – CrossEncoder. Это более мощная модель: она берёт запрос и фрагмент вместе и оценивает их соответствие как единое целое, учитывая тонкие смысловые связи. Она точнее, но медленнее – поэтому её применяют только к лучшим кандидатам, уже отобранным ColBERT.
Итоговая оценка каждого фрагмента формируется из комбинации результатов обоих инструментов. Это называется объединение рангов (rank fusion). Получается что-то вроде жюри из двух судей: один оценивает быстро и широко, второй – медленно, но очень внимательно. Вместе они выносят более точный вердикт, чем каждый по отдельности.
И всё это – включая оба инструмента ранжирования – работает на обычном процессоре (CPU) и занимает около 650 миллисекунд. Меньше секунды. Для разговорного ассистента это вполне приемлемо.
Умное усечение: брать только то, что нужно
После ранжирования система должна передать отобранные фрагменты в большую языковую модель, которая сформирует финальный ответ. Но у модели ограниченный «карман» – тот самый лимит токенов. Значит, нужно решить, сколько фрагментов взять.
Традиционный способ: взять топ-N фрагментов и всё. Просто, предсказуемо, но неточно. Если граница проходит посередине важного куска информации – ответ будет неполным. Если включить слишком много – модель утонет в шуме.
SmartSearch использует адаптивное усечение на основе оценок. Система смотрит на оценки релевантности, которые присвоил CrossEncoder каждому фрагменту. Пока оценка высокая – берём. Как только оценка начинает резко падать – останавливаемся. Это динамическая граница, которая подстраивается под конкретный запрос и конкретный диалог.
Результат впечатляет: в среднем SmartSearch передаёт в модель в 8,5 раза меньше токенов, чем системы, которые просто скармливают модели весь доступный контекст. При этом качество ответов не падает – наоборот, растёт. Потому что модель концентрируется на действительно важном, а не пытается разобраться в горе лишней информации.
Это как готовить эспрессо вместо ведра растворимого кофе: меньше объёма, больше концентрации, лучше вкус.
Оракульный анализ: где прячется узкое место
Исследователи провели интересный эксперимент – так называемый оракульный анализ. Они проверили, что происходит, если взять идеальный сценарий: система находит все нужные фрагменты (recall 98,6%), но затем без какого-либо ранжирования обрезает их до фиксированного лимита токенов.
Результат оказался красноречивым: при таком подходе до финального ответа доживает лишь 22,5% действительно важных фрагментов. Почти всё ценное теряется – просто потому что оказалось не в начале списка.
Этот эксперимент наглядно показывает: найти – это только половина дела. Важно правильно расставить приоритеты. Представьте, что вы нашли в интернете 200 статей по нужной теме, но прочитать можете только 10. Какие выберете? Если случайные – вероятно, пропустите самое главное. Если по умному рейтингу – скорее всего, найдёте то, что искали.
Именно эту задачу и решает этап ранжирования в SmartSearch. Он превращает теоретически высокий recall в практически высокое качество ответов.
Как SmartSearch показал себя на испытаниях
SmartSearch проверяли на двух стандартных тестовых наборах, которые используются в научном сообществе для сравнения систем разговорной памяти.
LoCoMo (Long-Context Memory – «долгосрочная контекстная память») – набор очень длинных диалогов, в которых много «шумной» информации, не относящейся к делу. Задача системы: среди этого шума найти именно то, что нужно для ответа.
LongMemEval-S (Long Memory Evaluation, Simplified – «оценка долгой памяти, упрощённая версия») – набор, сфокусированный на точном извлечении конкретных фактов из длинных диалогов.
Результаты SmartSearch:
- На LoCoMo – 93,5%
- На LongMemEval-S – 88,4%
Это лучшие результаты среди всех известных систем, протестированных по тем же протоколам оценки. Причём SmartSearch не настраивался отдельно под каждый из этих наборов данных – он работал с одними и теми же параметрами на обоих. Это говорит о том, что система хорошо обобщается на разные типы задач.
Для сравнения: системы, которые используют полный контекст диалога (то есть передают в модель всё подряд без фильтрации), тратят в 8,5 раза больше токенов – и при этом показывают худшие результаты. Больше не значит лучше. Особенно когда речь идёт об информации.
Почему это важно за пределами лабораторий
Вся эта история о SmartSearch – не только про цифры и бенчмарки. За ней стоит более широкая идея, которая важна для понимания того, куда движется разработка разговорных систем.
Долгое время считалось, что чем более структурированы данные перед подачей в модель, тем лучше. Идеальный ассистент должен сначала «переварить» весь диалог, разложить его по полочкам, создать аккуратную базу знаний – и только потом работать с запросами. SmartSearch показывает, что это убеждение не является абсолютной истиной.
Иногда лучший порядок – это не идеальный архив, а умение быстро найти нужное в живом, неупорядоченном потоке. Как опытный джазовый музыкант, который не играет по нотам, а слышит музыку и отвечает на неё в реальном времени.
С практической точки зрения это означает следующее:
- Меньше затрат на подготовку данных. Не нужно тратить ресурсы на предварительное структурирование каждого диалога с помощью дорогостоящих языковых моделей.
- Более быстрое развёртывание. Систему можно запустить на новом типе диалогов без длительной настройки и переобучения.
- Меньше искажений. Сырой диалог сохраняется как есть – со всеми нюансами и деталями, которые могли бы быть потеряны при структурировании.
- Экономия вычислительных ресурсов. Меньше токенов – меньше затрат на API, быстрее генерация ответов.
Это делает подобный подход особенно привлекательным для продуктов, где важна скорость реакции и стоимость обработки каждого запроса – то есть практически для любого коммерческого ассистента.
Ограничения и открытые вопросы
Было бы нечестно не упомянуть и о том, что SmartSearch – не универсальное решение всех проблем.
Во-первых, подход основан на поиске подстрок и именованных сущностей. Это значит, что он хорошо работает, когда в запросе и в диалоге используются одинаковые или близкие слова. Если пользователь спрашивает про «транспортное средство», а в диалоге речь шла про «машину» – система может что-то пропустить. Семантический разрыв остаётся уязвимым местом.
Во-вторых, исследование проводилось на двух конкретных тестовых наборах. Насколько хорошо SmartSearch справится с диалогами на других языках, в других предметных областях или при других стилях общения – отдельный вопрос, требующий дополнительных проверок.
В-третьих, система использует два обученных компонента ранжирования – ColBERT и CrossEncoder. Они не требуют специальной настройки под конкретные данные, но всё же являются обученными моделями, и их качество зависит от того, на каких данных они изначально тренировались.
Тем не менее результаты SmartSearch – это убедительный сигнал: в разработке систем памяти для ИИ-ассистентов стоит меньше инвестировать в сложную предварительную обработку и больше – в умное ранжирование.
Итого: ранжирование как новая суперсила
SmartSearch – это история о том, что иногда самые эффективные решения выглядят обманчиво простыми. Не строить идеальный архив, а научиться быстро находить нужное в живом потоке. Не структурировать заранее, а сортировать с умом в момент запроса.
Система достигает результатов, которые превосходят более сложные и ресурсоёмкие аналоги – и делает это быстрее, дешевле и с меньшим количеством данных для обучения. Всё потому, что авторы сосредоточились на правильном вопросе: не «как лучше хранить информацию?», а «как лучше её находить?»
Алгоритмы не лучше нас – они просто другие. И иногда они находят решения там, где мы ищем сложность.
