Учёные: LSP редко экономит токены кодовым ИИ-агентам сильнее grep
Авторы задались вопросом, который, по их словам, все повторяют, но никто не измерял: экономит ли Language Server Protocol (LSP), механизм точного, типизированного поиска по коду, которым пользуются IDE, токены у кодовых ИИ-агентов по сравнению с обычным лексическим поиском (grep). Grep, универсальный, мгновенный и не требует настройки инструмент, но «шумный»: он не отличает определение переменной от её вызова или упоминания в комментарии. LSP точнее, но требует запущенного и проиндексированного сервера и тратит время на обращение к нему за каждым символом.
Чтобы дать честный ответ, авторы ввели единую метрику, «токены до успеха» (число токенов, потраченных агентом до успешного решения задачи), и разработали эксперимент из пяти вариантов настройки инструментов, который отделяет эффект от использования именно семантического поиска от посторонних факторов. Предварительное исследование прогнали на репозиториях на Python и TypeScript с тремя моделями: Claude Opus 4.8, Sonnet 4.6 и Haiku 4.5.
Ответ получился условным и по большей части отрицательным. На задачах локализации кода по имени символа (найти место в коде по имени функции/переменной) LSP обходится агенту дороже обычного поиска, от +6% до +118% токенов, и агенты сами это чувствуют: они выбирают grep в 94, 100% случаев на таких задачах, обращаясь к LSP лишь в 0, 6% случаев, даже когда доступ к нему бесплатный. На задачах поиска всех ссылок на символ (reference-completeness) картина другая: LSP даёт точность, но не экономию токенов и не поднимает потолок полноты поиска, он определяется тем, насколько тщательно работает сама модель; экономию токенов LSP даёт только самой слабой из трёх моделей. При этом на задачах со ссылками агенты обращаются к LSP примерно в половине случаев без специальной подсказки, то есть выбор инструмента зависит от типа задачи.
Самый показательный результат, тест на реальных правках кода, которые проверялись прогоном настоящих тестов. Grep безупречно справляется с переименованием сущности сразу в нескольких файлах. LSP, ограниченный только определением местоположения, проваливает три четверти таких переименований, пропуская место вызова. Даже «улучшенная» версия LSP, с полным индексом, прогретым заранее, и с текстом каждой ссылки прямо в выдаче (как это делают промышленные LSP-MCP-серверы), закрывает большую часть разрыва, но не весь: переименование должно затронуть упоминания в комментариях и строках, а семантические ссылки LSP их не учитывают.
Вывод авторов не в том, что LSP не нужен, а в том, что нужен адаптивный маршрутизатор инструментов, который выбирает grep или LSP в зависимости от типа задачи, возможностей модели и уровня «шума» в лексическом поиске, вместо повсеместной ставки на семантический поиск как более совершенный по умолчанию.
Ключевые факты
- На локализации кода по имени символа LSP тратит на +6, 118% больше токенов, чем grep, и агенты сами выбирают grep в 94, 100% случаев
- На задачах поиска всех ссылок на символ LSP даёт точность, но экономит токены только для самой слабой из трёх протестированных моделей
- На реальных многофайловых переименованиях grep решает задачу безупречно, а LSP, ограниченный только локализацией, проваливает три четверти случаев из-за пропущенных мест вызова
- Даже полнофункциональный, заранее проиндексированный LSP не закрывает разрыв целиком: переименование должно затронуть комментарии и строки, которые семантические ссылки LSP игнорируют
- Эксперимент проведён на репозиториях на Python и TypeScript с моделями Claude Opus 4.8, Sonnet 4.6 и Haiku 4.5; вывод авторов, не «LSP всегда», а адаптивный выбор инструмента по типу задачи
Почему это важно
Индустрия ИИ-агентов для кода массово продвигает семантический поиск через LSP как более совершенную замену обычному текстовому поиску, но, как указывают авторы, эта экономия токенов заявлялась почти везде и не была измерена почти нигде. Работа впервые формализует вопрос единой метрикой и контролируемым экспериментом и показывает, что на практике всё чаще наоборот: LSP обходится дороже, а выигрыш в точности не всегда превращается в выигрыш по токенам.
Кому это важно
Результат важен разработчикам кодовых ИИ-агентов и инструментов вроде LSP-MCP-серверов, которые решают, каким поиском по коду оснастить агента по умолчанию, а также командам, которые считают стоимость запуска таких агентов в токенах и хотят понимать, где семантический поиск действительно окупается, а где только усложняет цепочку инструментов.
Как это применить
Практический вывод, не отказ от LSP и не отказ от grep, а маршрутизация: выбирать инструмент по типу задачи. Для локализации кода по имени символа предпочтителен grep, он и дешевле, и агенты выбирают его сами. Для многофайловых правок вроде переименований нужен не просто LSP, а его полная, заранее проиндексированная версия с текстом ссылок в выдаче, и даже она не заменяет проверку по комментариям и строкам. Для задач поиска всех ссылок на символ выигрыш от LSP по токенам ощутим прежде всего у более слабых моделей.
Можно ли доверять
Это предварительное («preliminary») академическое исследование с явно заявленной методологией: одна метрика («токены до успеха»), пятивариантная схема эксперимента, изолирующая эффект семантического поиска от посторонних факторов, и проверка части задач реальным прогоном тестов, а не только оценкой модели. Ограничение, сами авторы отмечают, что это предварительные результаты на конкретных репозиториях на Python и TypeScript и с конкретным набором из трёх моделей; масштаб выборки и число задач в источнике не приводятся.
Риски и подводные камни
Главный риск, переносить выводы шире, чем позволяет выборка: результат получен на Python- и TypeScript-репозиториях с тремя конкретными моделями и может не воспроизводиться один в один на других языках, кодовых базах или моделях. Отдельная ловушка, сама формулировка «LSP не экономит токены» справедлива не всегда: на задачах поиска ссылок он всё же экономит токены слабой модели, а на многофайловых переименованиях наиболее полная версия LSP заметно сокращает число проваленных случаев, просто не закрывает разрыв целиком.