Полезные приемы работы с LLM: Shotgun, Architecture as Code, Cursor

# Shotgun-ить

По мотивам этого поста я решил попробовать шотганить:

- Быстро, но детально стараетесь описать архитектуру текущего решения + задачу, которая перед вами стоит
- Склеиваете это все со ВСЕЙ кодовой базой и начинаете отправлять это в AI
- Первоначально говорите: "ты – архитектор, задай вопросы, чтобы детализировать Архитектуру и ТЗ"
- Отвечаете на вопросы и получаете Архитектуру
- Отправляете это еще раз: "ты – проект, распиши детально таски, которые нужно сделать"
- Результат отправляете еще раз: "ты – группа senior разработчиков, измени код, чтобы имплементировать фичу"
- Еще раз: "ты – группа QA, напиши тесты и проверь код"

Последние 2 этапа я делаю сразу в IDE, но результат просто фантастический...

Когда ты даешь LLM сразу весь контекст с большим кол-вом деталей, которые она же тебе и написала, она начинает выдавать реально крутой результат

Единственное, маленькие фичи / правки она будет долго выдавать, поэтому дальнейшие итерации по правками лучше делать сразу большим списком, опять же через: "я хочу вот это поправить, помоги мне это детальнее расписать, напиши задачи как это поправить, поменяй код, протестируй"

# Architecture as a Code – и никак иначе

Следующий важный аспект – вот все текстовые результаты, сделанные на предедущем этапе надо хранить в репозитории вместе с кодом. Как и всю другую документацию, которую вы будете писать.

Потому что как только вы описали свою архитектуру словами и добавили ее в AI, он сразу становится x100 умнее.

Короче, забыли о Notion, Google Doc и остальной херне и теперь пишем всю доку только в репах.

# Copilot – кал, Cursor – красава

Я как фанат VSCode все пытался выжать что-то из Copilot, но боги... как только я открыл Cursor и посидел час я понял, что так напрасно так долго мучался

Он и контекст понимает, и не обрывается на пол фразе, и быстрее, и позволяет создавать правила и не теряет их

Короче, даже не пробуйте, просто берите Cursor и все

А у тех, кто перешел в Cursor на что-то другое вопрос: на что и почему?

На самом деле лучше MCP с GraphRAG на все доки, включая по стеку

Ммм звучит прям очень секси

Собираем Github, Gitlab, Confluence, Notion, Swagger сайты, Google Docs, засовываем в БД, делаем поверх RAG / CAG и MCP и вот у компании ахуенная система, знающая все и вся и спосообная писать код по всей кодовой базе

Если такого еще нет, надо срочно делать

Ты имеешь ввиду вот этот GraphRAG? А в чем именно его фишка в отличии от других RAG либ?

Это в целом подход разделения (чанкинг) для эмбендингов при котором связь между контентом одного документа и релевантных кусков выстраивается не только в векторном пространстве по токенам, но и связях, которые создаются от структуры документов, категоризация, тегирование, разделение технологий.

Чтобы у RAG было высокое качество важно делать хорошую кластеризацию в векторном пространстве, чтобы не связанные темы были дальше друг от друга, чем связанные, чтобы score значительно отличался в выборке

Вот так это выглядит, если разделять чисто по токенам в векторах.
Много пересечений всегда будет, по факту используются те же слова/термины и всё вокруг одного - ИТ тематики.
Кластеризацию делать чисто на токенах мало смысла имеет. Поэтому есть гибридные поиски, когда мы ещё по дополнительным признакам фильтруем в каких векторах поиск делать. Но, документ превышающий в среднем 1536 токенов будет разбит на несколько частей, т.к. модель эмбендингов больше токенов не может переварить. И тут возникает проблема связать эти части между собой, т.к. они все становятся в плоскую структуру и разные куски и разных документов будут выдаваться в результаты с одним скором, просто из-за совпадения токенов (по факту слов) исключая смысловую связь этих кусков и последовательность.

На примере выше как раз тематики отношений, семья, секс, психология которые во многом пересекаются по описанной выше причине.

То есть, условно, мы не просто храним вектора, мы также создаем, храним и используем «связь векторов» (граф), которая также участвует при формировании ответа?

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

буду немного ленивой жопой, но он хорошо объяснил)