LLM понимание кода через LSP: модель получает типы и связи вместо сырого текста

Идея проста: IDE уже знает, что returnService это объект с методами submit, cancel, getById и update. Проблема в том, что большинство систем автодополнения на базе LLM (большой языковой модели) до сих пор ищут контекст через текстовое сходство, например через алгоритм BM25. Совпадение слов не равно связи между частями программы. Источник, на который опирается этот материал, показывает, как подключить языковой сервер к конвейеру автодополнения и передать модели структурированные факты вместо сырого текста.

Что понадобится

• Редактор с поддержкой LSP: VS Code, IntelliJ IDEA (через PSI, внутреннюю систему семантического анализа кода), Eclipse, Vim/Neovim с LSP-клиентом или любой другой, поддерживающий протокол
• Языковой сервер для вашего стека: TypeScript Language Server, gopls для Go, rust-analyzer для Rust и так далее
• Доступ к LLM с поддержкой FIM (Fill-in-the-Middle, режим дописывания кода в середине файла): подойдут модели, работающие через API, в том числе доступные на Yandex Cloud
• Базовое понимание JSON-RPC: протокол прост, запрос содержит поля method, params и id, ответ возвращает тот же id и либо result, либо error
• Время: настройка занимает от одного до трёх часов, если языковой сервер уже установлен

Как устроена сессия между редактором и языковым сервером?

Прежде чем строить конвейер, полезно увидеть, что происходит «под капотом». Протокол LSP стандартизирует обмен между LSP-клиентом (встроен в редактор) и языковым сервером (отдельный процесс, который разбирает код).

27 июня 2016 года Microsoft, Red Hat и Codenvy публично объявили о совместной работе над LSP. VS Code уже использовал JSON-протокол для общения с языковыми серверами, Codenvy добавляла поддержку в Eclipse Che, а Red Hat работала над отдельным Java-сервером. Спецификацию открыли, чтобы один сервер подключался к разным редакторам.

Сессия выглядит так:

1. initialize: клиент и сервер обмениваются возможностями, редактор узнаёт, какие языковые функции поддерживает сервер
2. didOpen / didChange: редактор передаёт серверу актуальную копию файла, включая несохранённые изменения
3. textDocument/definition, textDocument/hover, textDocument/references: клиент спрашивает, сервер отвечает адресом определения, типом, списком использований

Сам протокол не понимает TypeScript, Go или Rust. Он задаёт формат сообщений, а точность ответов зависит от конкретного языкового сервера.

Пошаговая инструкция

1. Определите точку курсора и соберите импорты

Система автодополнения фиксирует позицию курсора в файле. В примере из источника курсор стоит на строке 8 внутри функции createReturn, после набранных букв ret.

1. Отправьте textDocument/definition для каждого импорта

Для импорта returnService запрос выглядит так:

json { "method": "textDocument/definition", "params": { "textDocument": { "uri": "file:///project/returns.ts" }, "position": { "line": 0, "character": 12 } } }

Языковой сервер вернёт не исходный код, а адрес: URI файла и диапазон строк, где объявлен returnService. LSP-клиент читает этот файл и извлекает определение.

1. Запросите тип переменной через textDocument/hover

Для переменной request с типом ReturnRequest сервер вернёт сигнатуру интерфейса: поля orderId, reason и их типы. Модель получит точную структуру, а не угадает её по совпадению имён.

1. Соберите доступные методы через textDocument/completion

Если пользователь написал returnService., сервер вернёт допустимые элементы: cancel, getById, submit, update. Но в нашем случае мы не останавливаемся на списке методов: LLM предскажет намерение и сгенерирует целое выражение, используя сигнатуры этих методов как контекст.

1. Сформируйте промпт (запрос к модели) с LSP-контекстом

Вместо того чтобы вставлять в промпт «похожие файлы», добавьте конкретные блоки: - определение returnService с его методами и аргументами - интерфейс ReturnRequest с полями - интерфейс ReturnReason, если он доступен через цепочку определений

1. Передайте собранный контекст в LLM в режиме FIM

Модель получает префикс (код до курсора), суффикс (код после курсора) и LSP-контекст как дополнительный блок. Результат: подсказка опирается на реальные типы и сигнатуры, а не на текстовое сходство.

return returnService.submit({
  orderId: request.orderId,
  reason: request.reason
});

Что делать с этим прямо сейчас?

Разработчику на 1С или в Yandex Cloud. LSP-серверы существуют для десятков языков. Если вы работаете в VS Code с подключением к облачной среде, проверьте, поддерживает ли ваш языковой сервер методы definition, hover и references. Эти три метода покрывают базовый набор для построения контекста.

Автору технического контента на Дзене. LLM-понимание кода через LSP это конкретная тема для серии постов с практическими примерами. Покажите разницу между подсказкой «без контекста» и «с LSP-контекстом» на скриншотах, такой формат собирает сохранения.

Тимлиду или предпринимателю. Если ваша команда использует внутреннее автодополнение, добавление LSP-контекста не требует дообучения модели и не увеличивает расходы на инференс (вычисление ответа модели). Вы улучшаете вход, а не меняете модель.

Связка LSP и LLM не требует замены модели или редактора. Она требует одного архитектурного решения: спрашивать у IDE то, что IDE уже знает, и передавать ответ в промпт. Кто сделает это первым в своём рабочем процессе, получит подсказки, которые читают структуру проекта, а не гадают по словам.