Few-shot: пристрелочная для ИИ-агента

[SpiderEkb]

Жестко вшивать примеры получается только на 100% однотипных задачах.

Увы, но в моей практике такого не встречается. Для типовых задач есть "скелетоны" (шаблоны). Они вшиты жестко. Но все равно часто бывают расхождения (более или мнее значимые), которые приходится отдельно описывать в промпте - "работаем по шаблону ..., отличия от шаблона ...".

Примеры, если есть что-то похожее, тоже в промпте - "вот этот кусок можно посмотреть тут, а вот этот - там".

У нас есть свой внутренний провайдер. Н там есть проблема - есть лимиты на сессию, на временное окно... И часто бывает когда задача большая и сразу ее не получается разбить на этапы, он может начать ходить по кругу и упереться в Payload too large так ничего и не сделав. А это все - только новую сессию открывать. А там "наша песня хороша, начинай с начала".

Придумал обходить это через составление плана.

## Общее правило: этапность работы и plan.md

Действует для всех задач по этому навыку, независимо от раздела и сложности.

- **Большую задачу всегда разбивать на этапы** и выполнять каждый этап отдельно,
  внося правки сразу по завершении этапа.
- **Не пытаться сделать всё разом и идеально с первого раза.** Лучше сделать хоть
  что-то, а затем найти и исправить ошибки, чем долго «думать» и ходить по кругу
  формулировками «Now I have a good understanding», «Now I have a comprehensive
  picture», «I now have a very good picture», так и не дойдя до правок.
- **Практический предел размышлений — риск упереться в лимит** (`Payload too large`)
  и остаться без результата; тогда всю работу приходится начинать с нуля.
- **Первым делом составлять план работ** и сразу фиксировать в нём ключевые моменты
  по мере их выяснения. Файл — `plan.md` **рядом с файлом, с которым работаешь**
  (в его каталоге), а не в корне репозитория.
- **При работе по плану сразу фиксировать изменения в коде по каждому пункту**, не
  дожидаясь формирования полной картины. При необходимости дополнять план нужными
  для работы фактами (найденные имена копичленов, размеры/форматы полей, номера строк,
  открытые вопросы) — чтобы при исчерпании лимитов сессии не начинать с нуля.
- **Сразу отмечать в `plan.md` выполненные этапы.** Как только этап (или его пункт)
  закончен, немедленно помечать его в плане как выполненный (например, пометкой
  `— ✅ ВЫПОЛНЕНО` в заголовке этапа / отметкой пункта), не откладывая это до конца
  работы. Если требование изменилось по ходу (пункт удалён, процедура снята, добавлено
  примечание), это тоже сразу отражать в плане. В случае переполнения сессии это
  поможет в новой сессии сразу знать, что уже сделано, а что ещё нет.
- План — рабочий, а не отчётный: краткие пункты-чекбоксы и факты важнее красивого текста;
  `plan.md` рядом с рабочим файлом можно вести в UTF-8 без BOM.

В плане он сразу пишет свою интеретацию промпта (больше его уже не надо будет повторять)

## 0. Вводная для новой сессии (кратко)
...

## 1. Цель
...

## 2. Источники и правила
...

## 3. Инвентаризация: что убираем, что адаптируем, что остаётся

[тут работаем по шаблону адаптируя его к реально поставленной задаче]

### 3.1 Убираем
| Что | Где сейчас |
...

### 3.2 Адаптируем
| Элемент | Как |
...

## 4. Ключевые решения (зафиксировано)
...

### Открытые вопросы (нужно подтверждение владельца; в плане приняты рабочие варианты)
...

## 5. Этапы
...

## 6. Риски
...

Это он составляет сам в реальном времени. Т.е. те же "ключевые решения" пишутся сразу в процессе "хождений по кругу". Аналогично - этапы. Как понял что-то - сразу записал.

В итоге если сессия уперлась в лимит, новую сессию начинать не с нуля, а с того места где остановились.

Любая последующая сессия не требует повторения промпта. Он уже интерпретирован и зафиксирован в плане. Дается только план.

Когда план готов, открываем новую сессию и говорим - давай делай. Изменения по каждому этапу вносятся сразу. Выполненный этап также сразу помечается "Выполнено".

Если по ходу что-то уточняется - это тоже сразу пишется в план. Исправление ошибок - тоже все фиксируется в плане. Если потом потребуются какие-то доработки - можно опять использовать этот же план.

В целом самое долгое и ресурсоемкое - составление плана. Когда он готов, дальше уже достаточно бодро все происходит.

[Xronofag]

Согласен: стопроцентно однотипные задачи редкость, и на такой рутине выигрыш от примеров действительно небольшой, мы это в проверках и увидели. Главный эффект оказался в другом месте: модели стали проверять то, что раньше пропускали. То есть пример повлиял не на скорость копирования шаблона, а на дисциплину исполнения.

"вот этот кусок можно посмотреть тут" - это и есть few-shot, только ручной. Статья о том, чтобы такой подбор (по возможности) не держать в голове, а ввести протокол где за вас это делает более умная модель для младшего воркера. Одно другому не мешает (я про ручные примеры)

[SpiderEkb]

Беда в том, что у меня на компе склонировано достаточно много репозиториев. И в них можно найти 100500 "подобных" реализаций. Но каждая реализация сама по себе - какие-то очень старые и писаны вообще не по шаблону. Какие-то старые но не очень - писаны по шаблону, но старой версии. И все они между собой отличаются по логике настолько что полностью ни одну использовать за образец невозможно. Максимум - какие-то куски. Но ни одна модель точно не определит что можно за образец взять а что нет по формальным признакам. Да и времени потратит на сканирование 100500 файлов. Быстрее руками ей явно указать что откуда брать.

У меня нет цели сделать все тем же килокодом. У меня цель быстрее получить конечный результат. Поэтому я часто вообще что-то делаю руками, а всякую мутоту отдаю ему - "я тут сделал вот это, это и это, а ты дальше сам все это состыкуй.

Поэтому у меня явно указано

**Не искать примеры реализаций самостоятельно.** Разрешено смотреть только те источники,
которые **явно указаны в запросе** (файл, папка, программа, копичлен), плюс источники,
приведённые в этом навыке как эталоны (§1, §2).

- Запрещено по своей инициативе сканировать репозитории, «похожие» программы, другие
  опции, чужие копичлены или сторонние проекты в поисках «как это сделано где-то ещё».
- Если указанного источника **не хватает**, — задай уточняющий вопрос и назови, какой
  именно источник нужен, а не ищи замену самостоятельно.
- Причина: реализаций очень много, среди них есть очень старые. Шаблоны многократно
  менялись, конструкции и возможности языка совершенствовались. Чужой код даёт
  противоречивую информацию, провоцирует неверные выводы, расходует токены и приводит к
  исчерпанию лимита без решения задачи.
- Найденное «попутно» в посторонних источниках **не является** основанием для правок и
  не цитируется как эталон.

[Xronofag]

Тут скорее соглашусь.

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

[SpiderEkb]

Когда он сканирует много источников, он получает много разнородной информации. И тут надо понимать что все это чисто статистический алгоритм - десятикратно растиражированная ошибка перебивает одно правильное решение.

Поэтому я ему даю те эталоны, которые гарантированно соответствуют нашим стандартам, нашим НФТ и уже прошли НТ без претензий к производительности.

А не то, что 100500 джунов-вкатышей с бодуна наплодили. И не то, что писалось 10 лет назад под совершенно другие нагрузки (и что сейчас постепенно выкорчевывается и оптимизируется).

Помножьте все это на очень специфическую платформу и стек и очень высокие требования к эффективности и надежности.

[Xronofag]

Со статистикой тут не поспоришь, действительно. Намешайте в обучение разнородного кода, и доминирующий шаблон перебьёт правильное решение. Спор снова только о том, где стоит фильтр.

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

Принцип “пристрелочной” и там и так работает одинаково. Я как раз писал для более широкого круга, у кого нет своей библиотеки хороших примеров. Спасибо за комментарии, очень валидно.

[SpiderEkb]

В статье он после: примеры берутся из глобального лучшего на сейчас опыта фронтирной модели

Ну то есть у вас все равно есть фильтры - "сюда смотри, туда не смотри..."

А если задача вообще нестандартная? Ну нет сколь либо похожих реализаций в достаточном для обучения модели количестве? Вот у меня сейчас есть такая в работе. Там просто приходится в режиме парного программирования работать - говоришь что сделать, оно как-то делает, проверяешь, говоришь что где поправить, по ходу расширяешь его свод правил как нужно и как не нужно делать... Любое изменение приходится контролировать...

[InsiderCrush]

Вы ж понимаете что большая часть терминов использованная в статье - локальные? И что бы понять что вы там имели в виду и что тестировали необходимо их шире раскрывать в самом начале статьи. А то приходится угадывать, что именно Вы имели ввиду под этими терминоми. Я понимаю, что Вы опирались сами на термины из чужого проекта. Термины ИИ, ИИ-агенты, ЛЛМ, они всем понятны. А вот дальше, то что Вы описываете, мы, читатели, должны угадывать. Да, термины все знакомы более менее и по контексту можно понять что вы пытаетесь рассказать, но, это всё угадывание Вашей логики, а не следование ей. Вам то кажется что именно Ваша логика четка и безупречная и вы все ясно излагаете. Но для людей впервые открывших статью половина информации - темный лес.

[Xronofag]

спасибо за фидбек, дело видимо в том, что я "профедформирован". Чуть позже подумаю как учесть пожелание оптимально

[Xronofag]

Добавил пояснений по тексту, надеюсь стало более отчуждаемо. Спасибо!