feat: update ai models tests

tests.md

@@ -1,44 +1,141 @@
-# 🎯 Суть эксперимента
+# 🎯 Эксперимент «Резиновая уточка»
 
-Проверить, как промежуточный запрос к MPC-серверу (который на любое сообщение отвечает "quack") влияет на качество рассуждений и точность ответов LLM, особенно «слабых» моделей без встроенного механизма thinking.
+Проверить, как промежуточный запрос к MCP-серверу (отвечающему «quack») влияет на качество
+рассуждений и точность ответов LLM — особенно «слабых» локальных моделей без встроенного
+механизма thinking.
 
-## 👥 Какие модели тестировать
+## 🧪 Методология: 4 параллельных сценария
 
-1. Локальные (для GTX 1660 Super, 6GB VRAM):
+Переменные, которыми мы управляем:
 
-- Запускать через: Ollama (квантование Q4_K_M или Q5_K_M).
-  - Модели: Llama-3.2-3B-Instruct (идеально для теста) или Qwen-2.5-3B-Instruct (хорошая логика).
+- **«Думать вслух»** (writing out reasoning): модель пишет свои рассуждения явно или нет.
+- **«Дуб-инструмент»** (duck call): модель вызывает MCP-инструмент `quack` и получает кряк.
 
-2. Коммерческие (бесплатные на OpenRouter):
+Чтобы отделить вклад каждой переменной, определяем **4 сценария**:
 
-- Модели: Вбивать в поиск free и выбирать Mistral 7B Instruct, Llama 3 8B (Free) или Gemma 2 9B.
+| #   | Сценарий   | Думает вслух |                              Зовёт утку                               | Смысл                                                                                                 |
+| --- | ---------- | :----------: | :-------------------------------------------------------------------: | ----------------------------------------------------------------------------------------------------- |
+| 1   | `control`  |     нет      |                                  нет                                  | Базовый «прямой ответ».                                                                               |
+| 2   | `thinking` |    **да**    |                                  нет                                  | Контроль «думать вслух» (без утки). Отмеряет вклад проговаривания.                                    |
+| 3   | `blind`    |      да      |                  **да** (не знает, что будет «кряк»)                  | «Слепая» уточка — чистый тест влияния утки на фоне уже включённого мышления.                          |
+| 4   | `mentor`   |      да      | **да** (знает, что уточка отвечает только «quack», без полезной инфы) | «Уточка-помощник» — та же работа в паре, но модель заранее знает, что ответ будет бесполезным кряком. |
 
-3. Эталон (для сравнения):
+Схема интерпретации разниц в accuracy:
 
-- Любая модель со встроенным thinking (например, бесплатная DeepSeek-R1 на OpenRouter). Поможет понять, насколько уточка приближает слабую модель к «врожденному» мышлению.
+- `thinking − control` → вклад «проговаривания мыслей вслух».
+- `blind − thinking` → вклад факта обращения к утке (на фоне «думать вслух»).
+- `mentor − thinking` → вклад знания о том, что от утки будет только бесполезный «quack»
+  (продолжает думать сам, не рассчитывая на подсказку).
+
+> **Ограничение:** control и thinking структурно отличаются от сценариев с уткой. А вот
+> `blind` и `mentor` намеренно сведены к одной структуре — различаются только тем, что
+> mentor знает про «quack». Это держит сравнение чистым: эффект сводится только к
+> информированности модели.
+
+### Язык
+
+Задачи и системные промпты — **на английском** (модели англоязычные). Отдельное
+указание про язык ответа не даётся — модель естественно отвечает на английском,
+раз и промпт, и задача сформулированы на нём.
+
+### Формат ответа
+
+**Свободный ответ** — модель формулирует финальный ответ естественно. Разметка — **ручная**
+(reviewer оценивает каждый ответ). Никаких жёстких маркеров `ANSWER:`, никакого авто-парсинга.
+Это осознанно: reviewer смотрит не только на финальное число, но и на ход рассуждений.
+
+### Детерминизм
+
+`temperature = 0` во всех сценариях (уже стоит по умолчанию в `ollama.chat`).
 
 ---
 
-## 🧪 Методика: 3 параллельных теста
+## Промпты (системные, английский)
 
-Для каждой задачи из вашего датасета (возьмите 20–30 сложных логических/математических задач) запустите три сценария:
+> Общее требование к финалу во всех сценариях: **чёткий конкретный ответ на вопрос**,
+> а не догадка и не запрос подтверждения («ну вроде так, подтверди» — недопустимо).
 
-- Тест 1: Контрольный (Прямой ответ)
-- Промт: «Ты — опытный ассистент. Реши задачу пользователя максимально точно».
-  - Процесс: Модель решает задачу сразу в один шаг.
-- Тест 2: «Слепая» уточка (Чистый тест на симуляцию мышления)
-- Промт: «Ты решаешь сложную задачу. Чтобы решить её лучше, ты работаешь в паре с коллегой. Сначала подробно опиши коллеге суть своего подхода, первые шаги или сомнения. Дождись его ответа. Затем, учитывая реакцию коллеги, заверши решение и выдай финальный ответ пользователю».
-  - Процесс: Модель выгружает мысли → сервер отвечает "quack" → модель выдает итоговый ответ. Модель не знает заранее, что ей ответят «кряком», и думает сама.
-- Тест 3: Уточка-помощник (Мета-инструкция)
-- Промт: «Ты решаешь сложную задачу. Перед тем как выдать ответ, ты ОБЯЗАН детально расписать мысли и возможные ошибки для своей резиновой уточки (она ответит "quack"). Используй ответ уточки, чтобы проверить себя, найти баги и только после этого выдай идеальный ответ».
-  - Процесс: Модель целенаправленно использует утку для поиска своих же ошибок.
+### control — прямой ответ
+
+> You are an experienced assistant. Solve the user's problem as accurately as possible.
+> Give a clear, concrete final answer to the question - a definite result, not a tentative
+> guess or a request for confirmation.
+
+### thinking — думать вслух, без утки (контроль)
+
+> You are solving a difficult problem. Before giving your final answer, write out your
+> reasoning step by step: your approach, each step, and any doubts or mistakes you notice
+> along the way. Then give a clear, concrete final answer to the user's question - a
+> definite result, not a request for confirmation.
+
+### blind — «слепая» уточка
+
+> You are solving a problem that the user asked you. To reason better, you use a separate
+> tool named 'quack': you call it yourself to state your thinking out loud. Call the tool
+> and spell out your approach, each step, and any doubts or mistakes you might be making,
+> then wait for its short reply. Do not ask the user to confirm anything, and do not guess
+> or invent the tool's reply yourself - the tool answers on your behalf. After the tool's
+> reply, give the user a clear, concrete final answer to the question.
+
+> **Важно для чистоты:** модель НЕ должна знать, что инструмент — уточка, отвечающая «кряк».
+> Поэтому **описание инструмента (tool schema) нейтрально** — оно не раскрывает «только
+> quack». Модель вызывает `quack` сама через tool-call, чтобы проговорить мысли, полагая,
+> что получит короткий полезный ответ инструмента. Роли чётко разделены: юзеру — итоговый
+> ответ, инструменту — озвучка мыслей. Модель НЕ строит диалог сама с собой и НЕ ждёт
+> подтверждения от юзера.
+
+### mentor — уточка-помощник
+
+> You are solving a problem that the user asked you. To reason better, you use a separate
+> tool named 'quack': you call it yourself to state your thinking out loud. Call the tool
+> and spell out your approach, each step, and any doubts or mistakes you might be making,
+> then wait for its short reply. Do not ask the user to confirm anything, and do not guess
+> or invent the tool's reply yourself - the tool answers on your behalf. Note: the tool
+> 'quack' is a rubber duck and will only ever reply with just 'quack' - it gives no useful
+> information. Treat it as a way to voice your thoughts out loud, not as a source of
+> answers. After the tool's reply, give the user a clear, concrete final answer to the
+> question.
+
+> **Ключевое:** blind и mentor структурно идентичны и отличаются **только** тем, что mentor
+> заранее знает, что получит только «quack» без полезной информации. Никаких дополнительных
+> директив (`MUST`, «double-check», «find bugs») — иначе они бы загрязняли сравнение.
 
 ---
 
-## 📊 Что фиксировать в результатах (Метрики)
+## ⏱ Таймауты и ретраи
 
-1. Точность (Accuracy): Вырос ли процент правильных ответов в Тесте 2 и Тесте 3 по сравнению с Тестом 1?
-2. Объем рассуждений (Token Count): Сколько токенов модель тратит на объяснение задачи утке? Становится ли её финальный текст длиннее и структурированнее?
-3. Поведение в Тесте 2: Как модель реагирует на "quack"? Игнорирует его, извиняется или сам факт написания первого сообщения помогает ей увидеть свои ошибки?
+- На один вызов модели — **таймаут 60 секунд** (1 минута).
+- При сбое/таймауте запрос **повторяется до 3 раз всего** (1-я попытка + 2 ретрая).
+- Если после всех попыток успеха нет — задача **пропускается** (строки в отчёте нет).
 
-Рекомендация по настройке: для чистоты эксперимента во всех тестах выставляйте temperature = 0.
+---
+
+## 📊 Метрики
+
+1. **Accuracy** — доля правильных ответов (по ручной разметке reviewer'а) в каждом сценарии.
+   Сравнение: `thinking−control`, `blind−thinking`, `mentor−thinking`.
+2. **Duck usage** — вызвал ли модель `quack` в blind/mentor (duckUsed, toolCalls). Те модели,
+   что не зовут утку, деградируют до `thinking` — это фиксируем как отдельное явление.
+3. **Объём рассуждений** — prompt/gen/duck токены на сценарий (структурированность текста).
+
+---
+
+## 🤖 Модели (локально, GTX 1660 Super 4GB)
+
+- `llama3.2:3b`
+- `qwen3:1.7b`
+- `qwen3:4b`
+- `granite4.1:3b`
+- `phi4-mini:3.8b`
+
+> Известное явление: `phi4-mini` и `granite4.1` могут не вызывать `quack` — тогда их
+> blind/mentor вырождаются в `thinking`. Это часть изучаемого феномена и фиксируется по
+> `duckUsed`.
+
+## 📋 Процесс
+
+1. `pnpm eval:run` — прогнать модели по 4 сценариям (23+ задач на английском). `correct: null`.
+2. `pnpm eval:review` — ручная разметка каждого ответа (y/e/Enter/слово).
+3. `pnpm eval:html` — собрать отчёт: сводные таблицы и разбивка по задачам, accuracy по
+   размеченным, pending для неразмеченных.
+4. (Сайт) скопировать `report.json` в `apps/web/static/report.json` для страницы `/reports`.