Шпаргалка: что куда вписывать
| Поле | Что ставить | Зачем |
|---|---|---|
| Task and constraints | Опиши задачу своими словами, по-английски | По ключевым словам определяется тип задачи. По-русски распознаётся хуже. |
| Model | qwen2.5:7b | Точное имя модели в Ollama. Быстрая, не думающая. |
| Model class | medium | Размер модели. 3B → small, 7–13B → medium, больше → large. Часть техник не годится для мелких. |
| Provider | ollama | Откуда брать модель. Второй вариант — свой OpenAI-совместимый сервер. |
| Structured output | ✅ | Модель умеет выдавать JSON по схеме принудительно. Для извлечения обязательно. |
| System messages | ✅ | Понимает системную инструкцию. Есть почти у всех. |
| Tool calling | ❌ | Только для агентских задач с инструментами. |
| Reasoning control | ❌ | Только если модель «думающая» и хочешь ускорить её, отключив размышления. |
| Dataset | multiconer-en | На чём проверять. Бери от 100 примеров, иначе цифры ничего не значат. |
| Repeats | 3 | Сколько раз прогнать каждый пример. При 1 стабильность показывает фальшивую единицу. |
| Optimizer rounds | 2 | Работает только для кнопки Optimize. На Benchmark и Compare не влияет. |
| Optimizer search | DSPy MIPROv2 | Тоже только для Optimize. Из четырёх вариантов только он давал прирост. |
Порядок кнопок: Create my prompt → Create with this technique → Benchmark this prompt → Compare all recommended. Optimize the prompt — в последнюю очередь, если захочешь выжимать дальше.
Что это делает
Обычно промпт пишут наугад и правят, пока не покажется, что стало лучше. Проверить это нечем.
Здесь по-другому: инструмент подбирает способ составить промпт, показывает готовый текст и прогоняет его на настоящей модели по десяткам примеров. В конце ты видишь цифры вместо ощущений.
Четыре кнопки, по порядку
Описываешь задачу своими словами. Получаешь ранжированные методы с объяснением, почему именно эти, и готовый промпт для первого из них.
На любом другом методе из списка. Показывает промпт, в который собирается он, — ровно тот текст, который уйдёт в модель.
Проверяет этот промпт на живой модели по всем примерам датасета. Это главная кнопка.
То же самое, но сразу для всех трёх способов, чтобы выбрать лучший.
Две главные цифры
quality — насколько ответы правильные
Считается с частичным зачётом. Если из четырёх нужных вещей модель нашла три — это примерно 0.85, а не ноль. Поэтому 0.78 значит «в основном справляется, но регулярно теряет по одной штуке».
reliability — насколько ответ правильно оформлен
Это про форму, а не про смысл. Ответ пришёл как надо: правильный JSON, все нужные поля, ничего лишнего вокруг.
Не путай эти две. Бывает reliability 1.00 при quality 0.4. Это значит: модель аккуратно и в правильном формате выдаёт неправильные ответы.
Остальные цифры
mean latency | Сколько секунд уходит на один пример. |
mean tokens | Сколько токенов тратится на один пример. Это прямо деньги, если модель платная. |
mean calls | Сколько раз дёргается модель на один пример. Больше вызовов — дороже и медленнее. |
failures | Сколько примеров вообще не отработало. Должно быть 0. |
stability | Даёт ли модель один и тот же ответ на один и тот же вопрос. |
Три вещи, на которых легко обжечься
1. Поставь Repeats = 3. При Repeats = 1 стабильность всегда показывает 1.000. Это не значит «стабильно» — это значит «никто не проверял». Модель может выдавать разное на один и тот же вход, и ты этого не увидишь.
2. Мало примеров — цифрам верить нельзя. На 6 примерах разница в 5% ничего не значит. Бери датасет от сотни примеров, если собираешься что-то решать по результату.
3. Цифры привязаны к модели. Померил на одной модели — для другой это снова догадка. Инструмент честно пишет measured, если мерил, и prior only, если только предполагает.
Что делать по результату
| Что видишь | Что делать |
|---|---|
| quality низкое, reliability высокое | Форма в порядке, смысл нет. Смотри блок Weakest examples внизу — там три худших примера. Обычно за низким качеством стоит одна повторяющаяся ошибка. |
| reliability низкое | Модель болтает лишнее вокруг ответа. Поставь галочку Structured output — формат начнёт применяться движком, а не просьбой. |
| failures больше нуля | Модель не успевает отвечать. Возьми модель побыстрее — «думающие» модели тратят по 40 секунд на пример. |
| Всё хорошо, но дорого | Сравни с более простым способом. Часто три вызова модели не окупаются качеством. |
| Цифры скачут между запусками | Мало примеров или Repeats = 1. Увеличь и то и другое. |
Кнопка Optimize
Пробует переписать промпт сама и проверяет, стало ли лучше.
Смотри только на таблицу Held-out validation — это проверка на примерах, которых оптимизатор не видел. Если там нули или минус, улучшения не было, что бы ни показывала таблица выше.
Так бывает часто. Оптимизатор легко подгоняется под те примеры, на которых учился, и на новых работает не лучше. Это нормально, просто не верь цифрам «сверху».
Свои данные
Встроенные примеры — чтобы разобраться. Выводы делай на своих. Файл — по одной задаче на строку:
{"id": "1", "input": "Мара вошла в Вейр с Капитаном Орином.",
"expected": {"people": ["Мара", "Капитан Орин"], "places": ["Вейр"]}}Обязательны только id и input. Остальное подберётся само.
Одно правило. Правильный ответ должен встречаться в тексте слово в слово. Если в тексте «Капитаном Орином», а в ответе «Капитан Орин» — модель получит незачёт за то, что не угадала твою форму записи.
Подробности — если нужно копать глубже
Откуда берётся quality
Это метрика field_f1: считает и то, что модель пропустила, и то, что она придумала лишнего. В таблице Graders она помечена как headline. Рядом лежит exact_match — совпало ли всё целиком, без поблажек. Он почти всегда сильно ниже, это нормально.
Проверки формата там же: json_validity (распарсился ли ответ), json_schema (совпал ли со схемой полностью), no_prose (нет ли болтовни вокруг). Если json_validity = 1.00, а field_f1 низкий — проблема в понимании задачи, а не в формате.
Откуда берётся reliability
Это доля ответов с правильным форматом, умноженная на стабильность. Отсюда и подвох с Repeats: при одном прогоне стабильность равна единице по определению, и reliability выглядит завышенной.
p95 latency
Время, в которое укладываются 95% примеров. Если оно намного выше среднего — бывают редкие очень долгие ответы. Для интерактивных сценариев это важнее среднего.
Measured против Declared
Declared — оценка из конфига техники, поставленная до всяких замеров. Measured — что получилось на самом деле. Расхождение — это польза, а не ошибка: после замера конфиг перестаёт учитываться.
Сравнение техник
Колонка Weighted — сводная оценка с твоими весами. Но если у стоимости токенов ненулевой вес, техника может выиграть за счёт дешевизны, будучи хуже по сути. Сверяйся с колонкой Quality.
Колонки latency и tokens в сравнении относительные — считаются от лучшей техники в этом же прогоне, и с другими прогонами не сопоставимы.
Pareto front в оптимизации
Список вариантов, которые никто не превзошёл сразу по всем признакам. Среди них иногда есть вариант и точнее, и дешевле того, что объявлен победителем.
Стадии промпта
У некоторых техник промпт разбит на несколько стадий — это несколько вызовов модели подряд. Надписи вида {previous} — места, куда во время работы подставится результат предыдущей стадии.
Пустые примеры в датасете
Оставляй в данных случаи, где правильный ответ — пустой. Без них промпт, который угадывает наугад, будет выглядеть хорошо: ошибкам не на чем проявиться.
Ещё подробнее — в README.md и папке docs/.