В предыдущей заметке обсуждалось как искать похожий код в репозитории. Для этого мы брали код около курсора, превращали его в поисковый запрос, находили кандидатов через BM25 и добавляли наиболее релевантные фрагменты в контекст модели.

Но код - это не просто текст. Импорт ссылается на конкретное объявление, переменная имеет определенный тип, а метод может принадлежать классу или интерфейсу. В этой заметке мы добавим в систему автодополнения источник контекста, который знает об этих связях внутри проекта.

Продолжаем разбирать, как система автодополнения собирает контекст для LLM. В реальном репозитории потенциально полезных файлов слишком много, поэтому мало просто найти фрагменты с похожими словами - нужно понять, какие из них действительно стоит показать модели.

Разберём один из классических алгоритмов ранжирования - BM25: почему редкие идентификаторы важнее популярных слов, зачем учитывать размер файла и почему десять одинаковых совпадений не должны быть в десять раз полезнее одного.

Автодополнение кода появилось задолго до больших языковых моделей. Ещё в 1997 году IntelliSense в Visual Basic 5.0 подсказывал конструкции, допустимые в текущем контексте программы. Позже подсказки начали ранжировать с помощью машинного обучения, а в 2021 году GitHub Copilot сделал LLM-based автодополнение массовым продуктом.

При этом основная задача почти не изменилась: понять по доступному контексту, какой код разработчик собирается написать дальше. В этой заметке разберём, какой контекст можно передать модели, почему одного кода рядом с курсором часто недостаточно и как количество и качество контекста влияют на итоговую подсказку.

Небольшая заметка про Fill-in-the-Middle - способ обучения моделей, который позволяет предсказывать не следующий токен, а код между уже существующими фрагментами. Разберём основную идею (формат PREFIX–SUFFIX–MIDDLE) и посмотрим простой пример его применения для предсказания кода.

VSCode создавался с прицелом на возможность расширения функционала с помощью плагинов. От UI интерфейса до своих AI агентов — почти каждую часть VS Code можно настроить и улучшить с помощью VSCode API. Многие части самого VSCode фактически являются плагинами.

Есть подробная документация по созданию своего плагина, а большое количество "мини-плагинов" с демонстрацией возможностей можно найти в репозитории vscode-extension-samples. Сама dts-ка с описанием API есть в основной репе microsoft/vscode вот тут. Кроме src/vscode-dts/vscode.d.ts в директории еще много других файлов в формате vscode.proposed.*.d.ts. Это экспериментальное API. О нем и пойдет речь в данной статье.

Эта статья родилась из опыта использования GraphQL в проекте одного из крупнейших аэропортов РФ. Проект посвящен созданию системы по автоматизации обслуживания рейсов и управлению ресурсами аэропорта в реальном времени (MRMS система).

Проект реализован на базе микросервисной архитектуры, где модель данных аэропорта представлена в виде GraphQL API, а сервер, предоставляющий API, написан на java. Клиентами этого API являются не только web/mobile, но и сервисы на java, golang и python.

Статья написана как пошаговое руководство по созданию своего GraphQL клиента на python с нуля, где попутно автор демонстрирует проблемы, возникающие на этом пути. Использовать реальную GraphQL схему аэропорта не представляется возможным, поэтому для наглядности будем использовать открытую схему github GraphQL API.

Речь в статье пойдет о специальных инструментах для работы с GraphQL на Python в качестве клиента. Если вы используете GraphQL в своих сервисах на Python, то, скорее всего, сталкивались с необходимостью писать и хранить строки, содержащие GraphQL запросы, а так же писать Python классы для хранения результатов этих запросов. Вероятнее всего, вам было неудобно: не хотелось дублировать схожие запросы, постоянно править классы при частом изменении схемы и т.п. Вот и мне тоже. Поэтому, решая описанные проблемы, появились на свет два пакета: graphql-query и graphql2python.