Cursor учит ИИ-агентов искать по коду быстрее без бесконечного сканирования файлов
Cursor опубликовал технический разбор fast regex search - подхода к ускорению поиска по регулярным выражениям для ИИ-агентов, работающих с крупными кодовыми базами. Проблема здесь вполне земная: агенту недостаточно «понимать» код, ему постоянно нужно находить точные текстовые совпадения - имена функций, сигнатуры, константы, куски конфигурации и повторяющиеся шаблоны. В небольшом проекте это почти незаметно, но в большом монорепозитории каждый такой запрос превращается в задержку. Cursor прямо пишет, что в некоторых случаях обычный запуск ripgrep может занимать больше 15 секунд.
И вот здесь начинается самое интересное. Cursor не предлагает «волшебный ИИ-поиск», который всё понимает сам по себе. Вместо этого компания возвращается к старой, но очень полезной инженерной идее: прежде чем запускать дорогой поиск по всем файлам, стоит сначала быстро сузить круг кандидатов. Именно так десятилетиями строились хорошие поисковые системы, и именно так, как напоминает Cursor, работали многие прежние решения для code search.
Что не так с обычным grep
Для обычного пользователя разница выглядит так. Представим, что нужно найти книгу в огромной библиотеке. Классический grep или ripgrep - это очень быстрый библиотекарь, но он всё равно в каком-то смысле просматривает книги, чтобы убедиться, что нужная строка там действительно есть. На практике ripgrep отлично оптимизирован, и именно поэтому он считается одним из самых быстрых инструментов в своем классе. Но когда кодовая база становится очень большой, а агент запускает много поисковых запросов подряд, даже очень быстрый библиотекарь начинает упираться в потолок.
Cursor исходит из простого наблюдения: если агент ищет по коду постоянно, то выгоднее заранее подготовить индекс - что-то вроде каталога в библиотеке, а уже потом обращаться к самим файлам только там, где совпадение действительно вероятно. Это не отменяет обычную проверку regex по содержимому, но резко сокращает объем лишней работы.
Как помогает индекс из триграмм
В основе идеи лежат триграммы - последовательности из трех символов. Например, слово search можно разложить на sea, ear, arc и rch. Такой подход давно известен в поиске по коду: если регулярное выражение содержит определенные символьные фрагменты, то можно быстро проверить, в каких документах они вообще встречаются, и не открывать остальные файлы. Именно этот принцип подробно описывал Расс Кокс в материале о том, как работал Google Code Search.
Cursor использует этот классический фундамент, но сразу оговаривается: одной идеи «разобьем всё на триграммы» уже недостаточно. В маленьких корпусах это работает отлично, а вот в очень больших репозиториях можно упереться в другую проблему - индекс начнет возвращать слишком много потенциальных кандидатов. Тогда система снова станет тратить время на лишние проверки, и выигрыш окажется меньше ожидаемого.
Иными словами, Cursor не пытается заменить regex чем-то модным. Компания пытается сделать так, чтобы обычный точный поиск сначала задавал правильный вопрос: «Какие файлы вообще стоит читать?» и только потом тратил ресурсы на полный разбор.
Что Cursor меняет в старой схеме
Чтобы уменьшить число лишних срабатываний, Cursor добавляет более сложную фильтрацию: вероятностные маски и sparse n-grams - «разреженные n-граммы». Если говорить совсем просто, система старается выбирать не любые кусочки текста, а самые полезные и самые редкие. Это похоже на поиск человека в толпе не по слову «человек», а по сочетанию признаков вроде «красная куртка» и «желтый рюкзак». Чем реже признак, тем быстрее можно сузить круг поиска.
Компания пишет, что веса для таких сочетаний можно оценивать по очень большим наборам открытого кода. Тогда индекс будет знать, какие символьные комбинации встречаются слишком часто и потому мало помогают, а какие, наоборот, хорошо отделяют нужные файлы от всех остальных. Для пользователя это означает простую вещь: агент реже будет без нужды перерывать половину репозитория.
Почему всё это будет работать прямо на компьютере пользователя
Самая важная деталь в статье Cursor - индексы компания собирается строить и использовать локально, а не на сервере. Это выглядит не так эффектно, как «облачный ИИ», но инженерно решение очень логичное. Даже если индекс быстро подскажет вероятные файлы, потом их всё равно нужно читать и проверять уже обычным regex-поиском. Если держать всё это на сервере, придется либо постоянно синхронизировать кодовую базу, либо тратить время на лишние сетевые обмены. Локальный вариант помогает и со скоростью, и с приватностью, и с удобством работы в живом проекте.
Для обычного пользователя вывод здесь простой: Cursor пытается ускорить не «красивую демонстрацию ИИ», а самую рутинную и самую частую операцию, от которой зависит ощущение скорости всего редактора. Когда агент долго думает, причина нередко не в модели как таковой, а в том, что она слишком долго ищет нужный кусок кода. И если этот этап сократить, редактор станет отзывчивее без смены самой ИИ-модели. Это уже не вопрос магии, а вопрос хорошей инфраструктуры. Такой подход давно знаком всем, кто следит за развитием grep, ripgrep и code search: сначала убирают лишнюю работу, а уже потом улучшают всё остальное.
Cursor здесь не изобретает поиск с нуля, а развивает старую школу инженерных решений. Компания прямо опирается на идеи trigram index, знакомые еще по Google Code Search, и обсуждает ограничения, которые позже поднимали разработчики GitHub при создании собственной системы code search.
