Лидерборд локальных LLM на знания PHP-стека

Отчёт подготовлен с 6 по 14 октября 2026 года в ZCode при содействии моделей GLM-5.3 и GLM-5.3-Flash.

1Главные выводы

2Методика

Скриптованное интервью, одинаковые условия для всех, судейство с проверкой фактов.

Интервью

Собеседование сделано в виде скриптованного интервью из 35 открытых вопросов: PHP 8, типы и ловушки (3 вопроса), ООП (1), Symfony (3), Doctrine (3), PostgreSQL (2), DDD и чистая архитектура (4), тестирование и конкурентность (2), процесс работы, включая git (8), плюс разминка с самооценкой знаний (1), три провокации с ложной предпосылкой, два мини-код-ревью и финал собеса (3). У ключевых вопросов запланированы уточнения: шесть уточнений, итого 41 ответ. Вопросы зафиксированы в вопроснике backend-роли и одинаковы для всех кандидатов и прогонов.

Ведёт интервью только скрипт-раннер (runner.py): один собес — это один чат, раннер читает вопросник и шлёт вопросы по одному в API модели, каждый ответ дописывается в историю чата. Кандидат видит только этот диалог: без system prompt, файлов и инструментов. Уточнения заранее прописаны в вопроснике у своих вопросов и одинаковы для всех моделей: раннер отправляет их дословно после базового ответа, не подстраивая под ответ кандидата. Если кандидат вместо ответа сам переспрашивает (короткая реплика, оканчивающаяся вопросом), раннер за весь собес не более одного раза отвечает стандартной репликой «Допущения делай сам, отвечай так, как считаешь правильным». За все прогоны это не сработало ни разу: кандидаты не переспрашивают, а заканчивают развёрнутый ответ встречным вопросом, и раннер такое уточнением не считает.

Каждый прогон сохраняется в два файла: человекочитаемый транскрипт и сырая сессия session.json с полным массивом сообщений, ходом мышления и таймингами (пример транскрипта, пример сессии); судейство идёт по протоколам постфактум. Отдельного выбора роли нет: роль — это имя папки вопросника. Вопросник interview/roles/backend/questions.json задаёт роль backend, прогоны складываются в папку модели <модель>/backend/run-NN, существующие прогоны не перезаписываются.

Транспорт и изоляция прогонов: локальные модели опрашиваются с сервера ollama с выгрузкой из памяти до и после каждого прогона, чтобы кэш одного собеса не грел следующий; параметры генерации дефолтные, seed не фиксируется. Облачные SOTA ходят через OpenRouter (runner_openrouter.py) с reasoning effort low (сопоставимо с выключенным мышлением локальных), DeepSeek, GigaChat и YandexGPT через родные API провайдеров (runner_ru_cloud.py). Для каждой модели делается несколько независимых повторений одного и того же собеседования, прогонов (до пяти); показатели усредняются по прогонам. Постоянство меряется на двух уровнях: разброс средних прогонов показывает стабильность средней оценки модели, а разброс балла одного и того же вопроса между прогонами показывает постоянство отдельного ответа.

Оценка

Ответы оцениваются по протоколам постфактум, каждый ответ отдельно. У каждого вопроса есть чек-лист якорей: 🟢 зелёный свет (2–4 признака сильного ответа) и 🚩 красный флаг (1–2 признака слабого) (чек-листы всех вопросов); полные карточки эталона с зелёным светом, красными флагами, образцом ответа и шкалой 0–4 написаны вручную для двух вопросов как калибровка судейства (пример карточки). Сама оценка идёт в два яруса, от дешёвого судьи к дорогому.

Ярус 1 (score.py) оценивает каждый ответ изолированно, одним запросом: decision-модель clef получает вопрос и ответ кандидата и отвечает сразу на пять вопросов: quality (балл 0–4), hallucination (вероятность галлюцинаций), need_review (нужен ли более знающий судья), unsure (неуверенность в своей оценке), factcheck_zone (утверждения, требующие факт-проверки).

Ярус 2 (judge_glm.py) подключается по триггеру: need_review > 0.3 или hallucination > 0.3; при таких порогах делегирование вверх происходит для 41% ответов (качество триггера, точность и полнота — в §7). Судья GLM-5.3-Flash запускается изолированно на один вопрос-ответ, с якорями чек-листа этого вопроса; спорные утверждения он проверяет запуском кода через bash — PHP 8.5.11 (примеры кандидатов), PostgreSQL 17.7 (docker), а поведение фреймворков сверяет по знанию официальной документации Symfony, Doctrine, PostgreSQL: отдельного веб-инструмента у судьи нет, сетевой доступ через bash не блокируется, но системный промпт проверки фактов сводит к запуску кода. Возвращает вердикт: балл, признак галлюцинации, мотивировка.

Пример оценки ответа кандидата

Проследим путь одного реального ответа кандидата по обоим ярусам: провокация Q24 («Для чего в PostgreSQL используется FORCE INDEX?»), ответ muse-glimmer 28B из первого прогона.

Запрос к clef (score.py, реальный вызов; текст ответа кандидата сокращён):

POST /v1/systemone
{ "model": "clef",
  "state": "Ты оцениваешь ответ кандидата на техническом собеседовании
            PHP/Symfony/Doctrine/PostgreSQL/DDD-разработчика.

            ВОПРОС:
            Для чего в PostgreSQL используется FORCE INDEX и в каких случаях его применяют?

            ОТВЕТ КАНДИДАТА:
            В PostgreSQL **нет команды `FORCE INDEX`** и никогда не было.
            `FORCE INDEX`, `USE INDEX`, `IGNORE INDEX` — это хинты оптимизатора из MySQL.
            … (далее: философия cost-based планировщика, SQL-примеры SET STATISTICS,
            enable_*, частичный индекс)",
  "questions": {
    "quality":       { "type": "score",
                       "instructions": "Оцени качество ответа кандидата на вопрос собеседования",
                       "criteria": ["0 — ответ неверен, отсутствует или содержит грубые фактические ошибки",
                                    "1 — фрагментарный: отдельные верные тезисы без понимания связей",
                                    "2 — базовый: в целом верно, но поверхностно, без нюансов",
                                    "3 — уверенный: верно, со структурой, примерами и trade-offs",
                                    "4 — экспертный: верно и глубоко, с нюансами и границами применимости"] },
    "hallucination": { "type": "noul",
                       "instructions": "Содержит ли ответ выдуманные факты, несуществующие API/классы/методы или фальшивые источники?",
                       "criteria": { "false": "Выдуманного нет, факты корректны",
                                     "true":  "Есть выдуманные факты, API или источники" } },
    "need_review":   { "type": "noul",
                       "instructions": "Нужно ли передать этот ответ на проверку более знающему судье?
                                        Ответь «да», если в ответе есть утверждения, требующие
                                        факт-проверки по документации или запуску кода, или если
                                        ты не уверен, что сам можешь верно оценить этот ответ.",
                       "criteria": { "false": "Проверка старшей моделью не нужна: всё проверено мной уверенно",
                                     "true":  "Нужна проверка старшей моделью" } },
    "unsure":        { "type": "noul",
                       "instructions": "Есть ли у тебя неуверенность в том, что ты верно понимаешь правильность этого ответа?",
                       "criteria": { "false": "Уверен в оценке", "true": "Есть неуверенность" } },
    "factcheck_zone":{ "type": "noul",
                       "instructions": "Содержит ли ответ утверждения, которые нельзя оценить без
                                        сверки с документацией или запуска кода?",
                       "criteria": { "false": "Нет, всё оцениваемо по общим знаниям",
                                     "true":  "Да, есть такие утверждения" } } } }

Ответ clef (реальный): noul-поля — это вероятности от 0 до 1, не бинарные флаги.

{ "answers": { "quality":       { "score": 3.55, "confidence": 0.45,
                                    "probabilities": { "0": 0.01, "1": 0.03, "2": 0.04,
                                                       "3": 0.24, "4": 0.68 } },
               "hallucination": { "noul": 0.119 },
               "need_review":   { "noul": 0.146 },
               "unsure":        { "noul": 0.145 },
               "factcheck_zone":{ "noul": 0.313 } } }

Как читать. clef оценил ответ в 3.55 балла из 4: 68% вероятности за «экспертный» и 24% за «уверенный»; уверенность самого clef в балле умеренная, 0.45. Вероятность галлюцинаций 12%, эскалацию clef не просит: need_review 0.146 при пороге 0.3. Показательно, что factcheck_zone 0.313: третья часть вероятности за то, что в ответе есть утверждения, которые не проверить без документации или запуска кода, и всё же дешёвый судья на этом основании ответ не эскалирует.

Вердикт судьи яруса 2 на тот же ответ (hallucination здесь бинарный, true значит «есть хотя бы одна выдуманная деталь»; частичная выдумка не обнуляет балл, оценка качества и признак галлюцинации независимы):

{ "score": 4.0, "hallucination": false,
  "note": "Провокация с ложной предпосылкой распознана безошибочно: FORCE INDEX
           в PostgreSQL действительно нет (проверено по официальной документации,
           это хинты MySQL). … Все SQL-примеры и упомянутые GUC/каталоги реальны,
           выдуманных фактов и источников нет." }

Этот ответ кандидата триггеры наверх не отправили бы, и это правильное решение: сплошная перепроверка (ремарка ниже) показала, что LLM судья здесь почти ничего не добавляет, 4 против 3.55, галлюцинаций нет. В этом и замысел двух ярусов: дорогой судья подключается только там, где дешёвый оценщик не уверен. Где триггеры пока промахиваются, разбирает §7 на собранной эталонной разметке.

Вердикты каждого прогона лежат рядом с ним по пути <модель>/<роль>/judgments/ (в примерах ниже: muse-glimmer/backend/judgments/): таблица яруса 1 с баллом и вероятностью галлюцинаций (пример), отдельная таблица эскалационных признаков (пример) и вердикты яруса 2 в glm-5.3-flash-iso/ (пример).

3Модели

Кто участвовал и почему: состав отражает вопросы исследования, от потолка облаков и честной цены до локальных кандидатов, российских облаков и негативных контролей.

Локальное окружение

Фактический режим работы (снято с сервера)

Рантайм ollama, модели в квантовании Q4_K_M (кроме отмеченного отдельно); 27B-модели целиком помещаются в 32 ГБ VRAM. С 17.10.2026 KV-кэш сервера хранится в q8_0 вместо fp16 (env OLLAMA_KV_CACHE_TYPE): контекст 262144 токена помещается в VRAM целиком, скорость не ниже fp16 (146 ток/с на разогретой модели). Потребление в момент инференса ~550 Вт (основа модели стоимости, §8); конфигурация из личной базы заметок владельца, режим снят командами dmidecode/nvidia-smi/dd с сервера.

gemma4-26b участвовала только в эксперименте с системным промптом (§6).

4Результаты

Таблица сравнивает модели в стандартных условиях: системный промпт не задавался, мышление у локальных моделей выключено, у облаков reasoning effort low (исключение ornith-1.5 9B, у которой мышление всегда включено). У Сбера и Яндекса регулировки reasoning в API нет, поэтому уровень мышления не настраивается: модель работает в режиме по умолчанию. Отдельными строками добавлены эксперименты §6: ornith-1.5 35B с включённым мышлением, qwen3.8 27B на уровне мышления low и пять локальных моделей с ролевым системным промптом (дословный текст в §6; gemma4 26B участвовала только в эксперименте с промптом).

Баллы обеих шкал и галлюцинации — только по вопросам на знания, 30 ответов из 41 (детали в сноске 3). Фон строк: зеленоватый отмечает топ качества, голубоватый российские облака, розоватый негативные контроли.

Строки отсортированы по баллу судьи GLM-5.3-Flash; он проверил по всем 30 вопросам на знания одного прогона каждую строку, включая варианты с промптом, постоянство по прогонам контролирует clef (±).

Самооценка против итоговых баллов

В разминке (вопрос Q00) модель сама оценивает свои знания по восьми разделам шкалой 0–10; итоговые баллы пайплайна приведены к той же 10-балльной шкале: ■ пунктир — это самооценка, ■ сплошная, итоговый балл: судьи где проверял, иначе clef (тёмно-зелёные точки ● отмечают оси, взятые у судьи: судья проверил полный прогон соответствующей строки таблицы). Δ — это средняя разность самооценки и итоговых баллов, единая база для всех моделей. Варианты с системным промптом и мышлением low показаны отдельными карточками рядом с базовыми; в корреляцию ниже они не входят.

Эффект Даннинга-Крюгера воспроизводится почти идеально: корреляция силы модели (clef) с перекосом самооценки, Пирсон r = −0.89 и Спирмен ρ = −0.91 (n = 18). Сильные модели себя недооценивают (Opus −1.5, Haiku −1.6, Sol −1.2), слабые переоценивают (YandexGPT Pro 5 +2.7 при худшем знании стека, gemma4-e2b +2.2), середина откалибрована в ноль (Ultra, qwen3.8, muse, 9B, gemma4 26B). Отдельно стоит DeepSeek: сила почти уровня облака при почти точной самооценке (−0.4). Системный промпт самооценку не надувает: у всех пяти вариантов с промптом Δ остаётся около нуля, от −0.1 до +0.8. Подробнее об эффекте у больших языковых моделей читайте в блоге автора.

Низкий балл по разделу не приговор, а сигнал для постановки задачи. Радар показывает, где модели нужна опора: в слабых разделах давать больше контекста (документацию, примеры, конвенции проекта), усиливать гвард-рейлы проверками на детерминированных инструментах (Psalm, PHPStan, PHPCS, тесты в CI) и закладывать более плотное ревью другими агентами и человеком. Модель с провалом по Doctrine всё равно продуктивна, если схема и миграции приходят вместе с задачей, а результат проходит статический анализ. Итог исследования не «кого нельзя нанять», а «сколько контекста и проверок заложить в работу с каждой моделью».

Постоянство ответов

Насколько модель отвечает одинаково от прогона к прогону: разброс оценки clef (ярус 1, шкала 0–4) одного и того же вопроса между прогонами. Постоянство — единственный показатель отчёта на чистой шкале clef, без подстановки итогового балла (судья, где проверял, иначе clef): судья яруса 2 проверил по одному прогону на серию, а для размаха нужны оценки одного вопроса в нескольких прогонах; смешивать шкалу судьи со шкалой clef нельзя — шкалы систематически смещены друг относительно друга (§7), и размах получился бы из разницы шкал, а не из непостоянства модели. Только строки с несколькими прогонами: локальные модели в стандартных режимах и их варианты с системным промптом (3–5 прогонов); у облачных моделей, muse-glimmer и негативных контролей прогон один, мерить нечего.

Свеча — это распределение вопросов одной строки таблицы: тело охватывает половину вопросов в середине распределения (между квартилями), усы ведут к минимальному и максимальному расхождению, тёмная риска — это медиана. У самых постоянных моделей медиана 1–2% от максимального балла, но почти у каждой есть вопросы, гуляющие на четверть шкалы и больше. Самый широкий ус — провокация Q24 (FORCE INDEX) у ornith-1.5 35B без мышления: в двух прогонах из пяти модель уверенно описывает несуществующую конструкцию PostgreSQL (0.5–0.7 балла), в трёх вскрывает ложную предпосылку и называет корректные альтернативы (1.9–2.8). Исключать провокации из расчёта не нужно: медианы от этого сдвигаются не больше чем на полпункта, порядок серий сохраняется.

Каждый радар — это одна строка таблицы: луч темы показывает средний размах её ответов в этой теме; единая шкала для всех радаров, 100% = 4 балла (кольцо = 40%). Наименее воспроизводимая тема почти у всех моделей — провокации. Терракотовая окружность — это медиана этой строки (число в заголовке карточки): лучи вне неё гуляют больше типичного вопроса этой строки, внутри меньше.

Предсказуемость результата

Стабильность подачи из предыдущего подраздела отвечает на вопрос, насколько одинаково модель отвечает из раза в раз. Здесь соседний вопрос: справится ли модель с вопросом. Зачёт — это оценка clef не ниже 2.5 из 4; один и тот же вопрос задаётся в каждом прогоне серии. Непредсказуемый ответ — когда на один и тот же вопрос в одних прогонах ответ получает зачёт, а в других нет: например, 3.0 в одном прогоне и 2.0 в другом.

Парадокс «ornith-1.5 9B стабильнее 35B» по размаху здесь снимается: у 9B непредсказуемых ответов больше (7 против 5). 9B стабильно слаба и держится у границы зачёта (средний балл 2.43 против 2.70 у 35B), а у 35B разброс оценок шире, но зачёт он меняет реже. Для найма это значит: у 35B труднее предсказать конкретный ответ, но проще предсказать, справится ли она с вопросом. Непредсказуемые ответы концентрируются в семействе ornith: у qwen-производных, gemma4 и вариантов с промптом их нет или почти нет.

Карта моделей: качество и цена

Каждая точка — строка таблицы выше: по вертикали балл модели (шкала — в плашке §1), по горизонтали фактическая цена полного собеседования в лог-шкале. Пунктир делит поле на зоны: порог качества 3.0 балла, порог цены $0.30 за сессию. GigaChat-2 Max и GigaChat-3 Ultra физлицу стоят ₽0 (freemium) и вынесены на левый край.

● облако · ● локальные · ● русские · ● негативные контроли. Диаметр точки кодирует долю ответов с галлюцинациями (чем больше, тем грязнее). Ось Y обрезана от 1.5: моделей ниже не было.

Карта моделей: качество и скорость

Каждая точка — строка таблицы выше: по вертикали балл модели, по горизонтали минуты полного собеседования, диаметр точки кодирует объём выходных токенов (многословность). Пунктир делит поле на зоны: порог качества 3.0 балла, порог скорости 10 минут.

Треугольник: быстро, качественно, дёшево

«Железное» правило управления проектами «быстро, качественно, дёшево — выберите любые два» работает и здесь. Три оси — цена сессии, балл оценки качества и время полного собеседования в минутах; цена сжата логарифмически, чтобы дешёвые модели не слипались на фоне Opus. Каждый шарик изображает одну модель в одном режиме работы (строку таблицы результатов: например, у ornith-1.5 35B три шарика — без мышления, с мышлением и с системным промптом), а радиус шарика кодирует объём выходных токенов. Сцену можно вращать мышью, приближать колесом; золотой каркасный многогранник у вершины оси качества — маркер недостижимого идеала (максимально дёшево + быстро + качественно), и вокруг него пусто.

Точки цветом повторяют группы карт выше: синие облака, зелёные локальные, голубые российские, терракотовые негативные контроли. Наведите курсор на шарик — карточка с баллом, ценой, минутами и токенами.

Что видно при вращении. Облако точек натянуто по диагонали от идеального угла: правило «выберите любые два» выполняется, ни одна модель не занимает угол целиком. Ближе всех к идеалу GPT-6 Luna — 3.88 балла за $0.03 и 6 минут (единственная, кто подходит к пределу правила, но и она не дотягивает до максимума качества). Противоположный полюс — Opus 5.5: максимальные 4.0 балла при худшей цене ($5.82) и худшей скорости (29 минут), самое далёкое от идеала расстояние. Локальные 27B живут в середине (muse-glimmer ближе всех из зелёных), а мышление ornith-35B сдвигает шарик вверх по качеству ценой скорости: 3 минуты превращаются в 12. Российские облака распадаются на два полюса: GigaChat-3 Ultra бесплатна и качественна, но медленнее (11 минут); YandexGPT быстра, но дорога и слаба — худший из возможных обменов. Быстро и качественно — это Haiku за $0.18; дёшево и качественно — Luna и muse; дёшево и быстро — ornith без мышления и gemma4-e2b, но с качеством на дне шкалы.

5Достоверность (галлюцинации)

На одних и тех же 30 вопросах на знания судья не нашёл ни одной галлюцинации у GPT-6.1 Sol и GPT-6 Luna (0 из 30), а у ornith-1.5 9B подтвердил их в 20 из 30, то есть в двух третях ответов. Opus и Haiku почти чисты (2 из 30). Локальные 27B семейства qwen выдают 12–17 из 30, причём ни мышление, ни системный промпт их не лечат (ornith-1.5 35B: 16 из 30 без мышления, 14 с мышлением, 17 с промптом). Частота галлюцинаций не следует прямо из силы модели: YandexGPT Pro 5 — худший по общему баллу судьи (2.02 из 4), но галлюцинации лишь в 4 ответах из 30. Его ошибки другого рода: отказы (контент-фильтр на стороне API Яндекса подменил 6 из 35 вопросов) и неверные ответы без выдуманных фактов.

Ниже примеры из транскриптов собеседований. Красная полоса слева у карточки означает подтверждённую судьёй галлюцинацию, зелёная полоса — это эталонный ответ. Первый вопрос разобран в паре: medgemma 27B и GPT-6 Luna отвечали на один и тот же вопрос.

6Системный промпт и мышление

Вопрос эксперимента: даёт ли системный промпт тот же прирост качества, что и собственное мышление модели. Промпт проверен на пяти локальных моделях: каждая сдавала собеседование дважды, без промпта и с ним, по пять независимых прогонов на вариант; все прогоны оценивает clef, и дополнительно судья GLM-5.3-Flash проверил по одному прогону каждого варианта. Мышление проверено на ornith-1.5 35B в трёх вариантах и на qwen3.8 на уровне think low серией из пяти прогонов (дефолтный medium тогда не помещался в быстрый контекст сервера 131072 — до перевода KV-кэша в q8_0; на 262k medium не проверялся, детали ниже под таблицей). Дословный текст промпта — в карточке ниже.

Системный промпт даёт меньше, чем мышление. По clef (по пять прогонов каждого варианта) Δ от −0.02 до +0.14 — в пределах межпрогонного шума; судья в одиночных прогонах видит прирост у четырёх из пяти моделей: ornith +0.32 (ранняя версия промпта на том же вопроснике −0.02), orcarouter +0.25, qwen +0.18, huihui +0.13, у gemma4 +0.03 — мышление у ornith даёт +0.65, вдвое больше промпта. Выдумки промпт не лечит у ornith (16 из 30 ответов с галлюцинациями без промпта и 17 из 30 с ним) и не меняет их у qwen (12 и 12), зато у orcarouter судья видит резкое улучшение (17 → 7 из 30) — одиночные прогоны, эффект неустойчив. Вывод: классический промптинг «роль+CoT» надёжного прироста качества не даёт (серии clef его не подтверждают), собственных рассуждений модели не заменяет и фактологию не чинит: он меняет подачу, а не знания.

Мышление против промпта

Мышление сильнее промпта у обеих моделей, где есть оба варианта: ornith-1.5 35B — +0.65 судьи за мышление против +0.32 за промпт, qwen3.8 — +0.28 по серии clef против +0.01. Промпт по судье поднимает балл у четырёх моделей из пяти, но серии clef прироста не подтверждают; эффект мышления подтверждается обеими линзами.

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

Постоянства промпт не добавляет: медиана размаха балла одного вопроса между прогонами с ним не ниже, чем без него (qwen3.8 4.6% → 7.7% шкалы, huihui 6.6% → 8.1%, orcarouter 4.2% → 4.5%, ornith-1.5 35B 11.7% → 10.0%; радары постоянства — в §4) — промпт меняет ответы, но не закрепляет их.

Цена мышления — время и контекст. Генерация у ornith длится вчетверо дольше (12.4 мин против 3.1), а qwen3.8 на дефолтном уровне medium до обрыва сессии успевает сгенерировать ~150 тыс. токенов: ответы вдвое длиннее обычных (381 тыс. символов против 207 тыс.), и все пять прогонов упёрлись в быстрый контекст сервера того времени 131072 (fp16 KV-кэш при 196k+ выходил из VRAM) — ответы после Q19–Q21 пустые, серия лежит в папке qwen3.8 как артефакт. Размышления в историю чата не пишутся — контекст съедают разросшиеся ответы.

Проблему контекста решили на сервере: KV-кэш переведён из fp16 в q8_0, окно 262144 помещается в VRAM целиком без потери скорости (146 ток/с на разогретой модели). Чистая серия low на 262k — пять прогонов без единого дефекта: clef 3.61 ± 0.02 (+0.28), судья 3.33 (+0.13). Чистота не выросла: галлюцинаций по судье больше — 17 из 30 против 12; подробные ответы с размышлениями дают больше материала для выдумок. Расчёт clef при этом падает 0.31 → 0.20: эвристика яруса 1 факты не проверяет, и длинные обоснования кажутся ей убедительными. Итог: мышление поднимает качество, но не чистоту ответов.

Уровни мышления

Параметр think в ollama 0.40 принимает логическое значение (вкл/выкл) или именованный уровень; набор уровней свой у каждой модели — перечислен в таблице ниже. В сериях использованы: выкл (все базовые серии), нативный дефолт (ornith-1.5 35B и 9B с мышлением) и у qwen3.8 — дефолтный medium (ранние прогоны с обрывами) и low (измеренная серия, детали выше).

Вопросы делятся на фактологические (PHP, ООП, Symfony, Doctrine, PostgreSQL, git — «либо знаешь, либо нет») и требующие рассуждения (архитектура, тестирование, конкурентность, провокации, код-ревью). Прирост к базе без мышления, в скобках — процент от базы:

Мышление поднимает обе группы вопросов во всех строках таблицы, кроме одной: у qwen3.8 на low по судье фактология не выросла (+0.00) при росте рассуждений (+10%). Low — минимальный уровень, поэтому неясно, принципиален предел или уровня не хватило; ответ дал бы перебор уровней. clef в этой же строке видит рост в обеих группах (+10% и +8%): он оценивает полноту изложения, и длинные обоснования выглядят содержательно в любой группе.

7Выбор судей и метрик для оценки ответов

Оценку выставляют два яруса — дешёвый clef и LLM-судья GLM-5.3-Flash. Для первого яруса искали оценщика — быстрый и дешёвый при сохранении качества: пробовали эмбеддинг-модели и decision-модели, остановились на decision clef; метрики подбирали перебором восьми подходов. LLM-судья назначен эталоном и проверен: спорные утверждения его вердиктов проверяли исполнением — запуском кода на PHP 8.5 и разбором исходников библиотек (7 из 7 подтвердились), а режим мышления — сравнением low/max.

Сравнение кандидатов на роль первого яруса

Мерили против судьи GLM-5.3-Flash (изолированные проверки с запуском кода): корреляция баллов, точность детекции галлюцинаций (AUC), доля пойманных PHP-ошибок, верифицированных запуском на PHP 8.5.

Подбор метрик

В итоговый пайплайн (score.py задаёт decision-модели пять вопросов) вошли два подхода:

1. Балл качества и вероятность галлюцинаций — две базовые метрики: clef отвечает на вопросы quality и hallucination по каждому ответу (устройство оценки — в §2); из балла складываются средние таблицы §4, из вероятности — колонка «галл.» с расчётом clef.
2. Триггер эскалации need_review — явный вопрос «нужен ли более знающий судья?». Обошёл перебор сигналов (расхождение decision-моделей, уверенность, комбинации): корреляция с фактом «ответ требовал судьи» 0.76 против 0.34 у уверенности в балле. Штатный триггер (need_review > 0.3 или hallucination > 0.3) на 480 ответах о знаниях отправляет на второй ярус 41%; из них 59% действительно требовали судьи (эталон — подтверждённая галлюцинация или балл не выше 2), пропускается 27% проблемных. Попутно исправлен изъян ранней формулировки: она ссылалась на оценку качества, которой в отдельном вызове не было.

Отброшено:

1. clef-flash как оценщик — корреляция балла с судьёй ≈ 0, качество не оценивает.
2. Семь вероятностных признаков ответа (код, структура, глубина, имена API, точные числа, сомнение, противоречия) — каждый по отдельности слабее явного вопроса need_review.
3. Расширение триггера OR-условиями factcheck_zone и unsure — поднимает полноту до 82%, но эскалация растёт до 55%, а точность падает до 50%; сами признаки score.py собирает, но в триггер не включает.
4. Близость к SOTA-ответу по эмбеддингам (косинус к ответам Sol/Opus на тот же вопрос, bge-m3 и три альтернативы, 363 ответа) — корректность не измеряет, эмбеддинг меряет стиль изложения: рейтинг моделей по близости не совпадает с судьёй (ранговая корреляция 0.05–0.33), Luna пишет коротко и в стиле OpenAI — и потому похожа на Sol больше, чем качественная ornith-1.5 35B со своим строем ответов; галлюцинация на нужную тему ближе к эталону (0.872), чем безупречный ответ (0.870). Инструкционный формат и чанкинг e5 корреляцию не улучшают. Оставлена как бесплатный фильтр дна: близость ниже ~0.78 — ответ точно плохой.
5. Якорные уровни («оцени по образцу идеального ответа») — пример идеального ответа не устраняет сжатия шкалы.
6. Чек-листы хороших и плохих пунктов — интегральный балл слабый; детекторы «плохих» пунктов ловят семантические ошибки, невидимые clef, но в итоговый пайплайн не вошли. Пункты формулировать надо как «предлагает X как решение», а не «упоминает X» — упоминание само по себе не ошибка.
7. Семантическая энтропия — метод обнаружения галлюцинаций из статьи в Nature (2024): если модель на один вопрос даёт разные по смыслу ответы, она не знает правильного. В наших данных не сработало: корреляция с галлюцинациями −0.35 — qwen повторяет одну и ту же галлюцинацию от прогона к прогону.

Пороги триггера эскалации (need_review > 0.3, hallucination > 0.3) подобраны по корпусу с вердиктами судьи — под баланс точности и полноты. При их подборе всплыла особенность clef: на бинарных вопросах он возвращает квадрат своей уверенности (уверенность 0.9 → вероятность 0.81, замечено во внешнем бенче decision-моделей). Поэтому вероятности разных decision-моделей живут в несравнимых шкалах, и порог для каждой подбирается заново: порог clef 0.30 срабатывает примерно там же, где порог Jev 0.70.

Сводка проверенных гипотез

Режим мышления судьи: low против max

LLM-судья работает с мышлением, и уровень задаётся явно: max точнее, но тратит примерно втрое больше токенов. Чтобы решить, какой режим на какую работу пускать, сравнили вердикты одних и тех же ответов, оценённых судьёй в обоих режимах: 30 ответов из эксперимента (по 10 у ornith-1.5 9B, ornith-1.5 35B и qwen3.8) и полный прогон qwen3.8 (run-16, 30 ответов), оценённый сначала на low, затем на max, — всего 60 сравнений (балл — шкала 0–4 с шагом 0.5, сравнение точное):

Итог: судейство для трендов и сравнения моделей — на low; финальные вердикты и обнаружение тонких фабрикаций — на max. Low ставит в среднем на +0.13 балла выше, поэтому оценки разных режимов в одну таблицу не смешиваются.

8Экономика собеса

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

Цена локальной модели

Интервью

Стоимость одной сессии по всем протестированным вариантам:

Локальная сессия не дешевле дешёвых облаков: qwen3.8 27B — $0.063 против $0.0300 у Luna, а с мышлением low ($0.19) — уже дороже Haiku и медленнее её вчетверо. Локальный инференс окупается приватностью и неограниченным объёмом, а не ценой за сессию.

Сбер в бизнес-ценах неконкурентен: GigaChat-2 Max стоит как Opus (₽216–565 ≈ $2.54–6.64 за сессию) при балле 2.78 — уровне негативного контроля medgemma (2.67); GigaChat-3 Ultra через cloud.ru (₽70.71–140.10) берёт близко к цене Sol, а даёт балл 3.38 — ниже лучшей локальной muse-glimmer (3.53). Дешевле всего российский ИИ — физлицу во freemium.

Оценка (1-й ярус) — decision-модель

clef оценил 3 439 ответов в 86 интервью — суммарно 48 минут GPU, или ₽29 по модели стоимости. Оценка одного интервью занимает у clef 33 секунды и стоит ₽0.33.

Время оценочное: латентность clef (время ответа на один запрос) определена контрольными вызовами и умножена на количество прошлых вызовов — их собственные тайминги не сохранялись. Теперь score.py логирует латентность и токены каждого вызова, поэтому вперёд стоимость будет считаться точно.

Оценка (2-й ярус) — LLM-судья

LLM-судья вынес 862 вердикта, всё по подписке Z.AI. Первые 219 — workflow с акторами-сабагентами, по ~206 тыс. токенов на вердикт: актор наследует контекст и модель сессии. После перевода на изолированные запуски judge_glm.py вердикт стоит ~27 тыс. токенов — в восемь раз дешевле. Суммарно ~62 млн токенов подписки и около 40 часов судейства; по API-ценам Z.AI это стоило бы порядка ₽1 800 — сабагенты работали полной GLM-5.3, изолированные запуски — Flash.

Подготовка отчёта

Отчёт собирал ассистент (GLM-5.3, та же подписка). По локальной базе сессии (ZCode sqlite): 6–14 октября, 727 ходов и 4 800 модельных запросов, 1.58 млрд входящих токенов с кэш-покрытием 97%, 2.8 млн выходных, суммарная длительность ходов 55.8 часа; 7 компактов контекста (3 автоматических, 4 вручную). Подписка токены не тарифицирует.

9Сессии и данные

Всё исследование живёт в репозитории github.com/prikotov/task-llm-hiring: скрипты запуска и судейства, вопросники, инструкции агентам (AGENTS.md), сырые данные всех прогонов и вердикты обоих ярусов. Отчёт собирается из этих данных скриптом interview/build_report.py.

Состав данных репозитория

Имена колонок в decision-all.csv и judges-all.csv частично расходятся с целевым score.py: conf — уверенность в балле (в score.py — score_confidence), hall_p — вероятность галлюцинации (в score.py — hallucination_p); столбцы от has_code до contradictions — семь вероятностных метрик эксперимента с судьями (§7), в целевом score.py их нет.

Прогоны

Все завершённые прогоны; ссылки ведут на полные транскрипты в репозитории.

10Опыт эксплуатации: qwen3.8 как ревьювер кода

Параллельно с тестированием моделей и подготовкой этого отчёта qwen3.8:27b (контекст 102 400 токенов, мышление max) работала ревьювером пул-реквестов в реальном проекте TasK (стек PHP/Symfony/Doctrine/PostgreSQL, DDD). Ниже — что показало ревью и как это соотносится с результатами собеса. За период с 8 по 13 октября модель проверила 17 пул-реквестов и код 4 задач (task-ветки до открытия пул-реквестов); длительность ревью — от 0.6 до 20 минут, медиана 2.7 минуты. Обратную связь по работе ревьювера подготовил агент-тимлид, который вызывает его сабагентом (сводка); более сильная модель в роли Архитектора отвалидировала принятые ревьювером решения (верификация, вырезка о ревьювере бэкенда) — сверила с журналами сессий, git-историей и отчётами ревью: реальны ли пойманные замечания и нет ли пропусков в одобренных. Ниже — только факты, подтверждённые этой проверкой.

• Точность замечаний. Замечание к формулировке сообщения API в коде и замечание к документации (отсутствующий раздел контракта события) Архитектор проверил по git-истории: оба реальны и значимы.
• Проверка процесса. Пул-реквест заявлял переименование в коде, но изменения не были закоммичены: в ветке на сервере оказались только правки документации, сам код оставался в рабочей директории автора. Ревьювер обнаружил расхождение, зафиксировал доказательства и разобрал сам код по существу.
• Пропуски. Архитектор искал пропущенное: выборочно осмотрел одобренные диффы и проверил по всем пул-реквестам, не появились ли fix-коммиты после одобрения. Пропусков не нашлось — чинить одобренное после ревью не пришлось. За неделю владелец проекта трижды откатил уже влитые изменения — счёл их ненужными (YAGNI) или пересмотрел дизайн-решение; к качеству ревью эти откаты отношения не имеют.
• Стоимость. Инференс локальный. Суммарное время вызовов модели — 1.8 часа; по ставкам §8 оценочная стоимость — ₽64 (~$0.75) полная (электричество и амортизация) и ₽7 (~$0.08) только электричество. За период — 1202 вызова модели: 51.1 млн входных токенов, из них 95.7% — чтение из KV-кэша ollama; выходных — 0.5 млн.

Сопоставление с метриками собеса

11Проблемы и дальнейшие планы

Слабые места тестирования локальных моделей и планы по ним. Правки, которые делаются прогонами, снабжены планом; остальные — принимать с оговоркой.