Методика порівняння

Дата аналізу: 2026-10-12. Джерела: лише TeamTestResult, підготовлений Markdown у цій папці та код D:/work/CTO/www/soloway-aiassistant-monorepo-original.

Одиниця аналізу

Один результат = тестер × локальний кейс × blind model ID × варіант. Кейс 1 різних тестерів не є одним проєктом. Корпус містить 240 очікуваних комірок: 6 тестерів × 8 моделей × (3 оцінки + 2 підбори). Є 241 артефакт результату, бо для складу Юри / M8 збережено два варіанти. PNG Віталіка / M2 / підбір 2 включено через візуальну транскрипцію. Вхідні документи й логи не рахуються як відповіді.

Сашин estimate_3 виключено з прямого порівняння якості: M1 отримала Web3-запит; M3 — транскрибацію дзвінків; решта — суперечливу назву ToolShare разом з описом транскрибації. Збережено всі результати, але перевагу M3 за цим кейсом не зараховано. Отже, описова таблиця має 18 estimation-комірок на модель, а зіставний набір — 17. Це не гарантія повної ідентичності системних промптів і вкладень у решті комірок.

Стани та знаменники

• estimate: видно готову структуровану оцінку. Це не означає, що бюджет правильний.
• matching: видно результат підбору. Наявність профілів не доводить правильність усіх фільтрів.
• insufficient: застосунок показав fallback «недостатньо контексту». Це не автоматично виправдана відмова моделі.
• technical_error: видима технічна помилка. Її причина невідома без raw reply, parser/provider logs і часу виконання.
• unknown: артефакт не показує результату, достатнього для класифікації.

Для підбору готова оцінка проєкту є неправильним сценарієм, а не успішним підбором. Варіанти складського кейсу M8 не усереднюються й не дозволяють вибрати найкращу спробу. У зіставній таблиці ця одна комірка має нуль готових оцінок та окремий статус «помилка / результат не видно».

Погоджені метрики

Числа completion — опис корпусу, не оцінка повторюваної надійності та не ймовірність конверсії. Якісні висновки наведено через конкретні кейси й джерела. Суцільного числового балу та штучної точності немає: ваги метрик не були погоджені. Provider-level latency і cost доступні окремо, але end-to-end latency та вартість одного готового estimate не встановлені через відсутність кореляції між 188 викликами й 240 тестовими комірками. Відсутній результат погіршує клієнтський outcome; зміст його неіснуючих етапів чи припущень позначається як неоцінюваний, а не як вигаданий нульовий бал.

Як обрано рекомендацію

Фінальний авторський пріоритет для пілота: M7, M1, M8, M2, M3, M5, M4, M6. Він балансує прийнятну якість і готовність із provider-level вартістю та часом: M7 має 12/17 готових оцінок, 0 видимих estimation technical errors, середню ціну API-виклику $0.004866 і медіану часу генерації 26.155 s; M1 має 13/17, але $0.094224 і 40.812 s. Це бізнес-пріоритизація для пілота, а не статистичний score: ваги не задані, 188 API-викликів не приєднані до 240 test cells, provider time не є end-to-end latency, а conversion не вимірювалась. Вісім позицій є практичним порядком за цими компромісами й не доводять універсальну перевагу M7. Окремо показано, як зміниться вибір за пріоритету арифметичної прозорості або мультимодальності.

Обмеження джерел і кодовий контракт

30 PDF Юри отримані OCR з мовою ru; сумнівні числа/слова не використано як негативні факти без перевірки. Технічні стани звірено з заголовками, зображеннями та локальними нотатками. Числа ключового успішного OCR-кейсу Y2/M1 перевірено на зображенні. Розбір PDF може переставляти колонки й етапи; порядок тексту не дорівнює порядку виконання робіт.

Під час фінальної перевірки виявлено, що застарілий паралельний запуск OCR перезаписав журнал, похідні зображення сторінок і чотири агреговані текстові файли. Підготовлені Markdown не змінені: журнал відновлено з їхніх збережених посторінкових текстів із явною позначкою recovery_method, перевіркою SHA-256 оригіналів і наявності пов’язаних зображень. Дві порожні сторінки повторно відрендерено у початковій роздільності та перевірено за раніше збереженим hash. Це відновлення збереженої копії, а не новий запуск OCR чи повторна перевірка кожного символу; аудит окремих OCR-плиток не заявляється. Решта пов’язаних зображень відображає той самий оригінальний PDF в іншій роздільності. Збережено попередній журнал analysis/ocr/manifest_failed_batch.json.

Поточний llm.constants.ts дозволяє оцінку за type + detail, вимагає два речення summary, етап узгодження та явні припущення. Адмінський DB prompt і pricing можуть змінюватися; їхні історичні версії в експорті не збережені. Тому невідповідність поточному контракту позначається як проблема для теперішнього продукту, без твердження, що модель порушила саме історичний prompt.

У поточному sessions.service.ts input gate працює перед prompt/LLM і може одразу повернути fallback. session-input-gate.service.ts класифікує лише typedText, не текст вкладень. Це реальний альтернативний шлях появи fallback, особливо для sketch-only input. У корпусі немає історичного gate mode/verdict, тому completion порівнює протестовані конфігурації продукту під blind ID, а не ізольовану здатність провайдерської моделі. Кодова можливість не доводить причину конкретного історичного збою.

Сума тривалостей етапів може перевищувати календарний строк через паралельність. Monthly ranges за контрактом не мусять точно сумуватися до total. Сума рольових headcount не обов’язково дорівнює унікальним людям: одна людина може виконувати кілька ролей. Не застосовуються механічні штрафи за ці розбіжності.

Кандидатів повертає COWO після LLM; fixed CTA/disclaimer додає застосунок. Бюджети, ставки й vendor claims у відповідях не перевірялися зовнішніми джерелами. Без експертного еталона немає MAE/MAPE або висновку «ця ціна правильна». Ідентичності восьми моделей і реальна конверсія в корпусі не встановлені.

Операційні агрегати OpenRouter

Для provider-level показників використано локальний OpenRouter CSV та похідні model-operations.csv, model-operations.json і README. Оброблено 188 рядків; зіставлення виконано лише за явними мітками Модель1…Модель8, без висновків про реальну provider identity. Виклики охоплюють UTC-інтервал 2026-10-08T12:28:38Z—2026-10-09T18:33:40Z, інферований із Unix-префікса generation_id. Дату 2026-10-12 у назві CSV не використовуємо як часовий діапазон викликів; сирі created_at у джерелі відображені як 8/10/26 та 9/10/26.

cost_total_usd і похідні середнє/медіана трактуються як USD за контрактом локального проєкту (llm-client.service.ts мапить usage.cost у costUsd, а usage-record.entity.ts зберігає cost_usd), хоча окремого поля валюти у CSV немає. Секунди generation_time_ms і time_to_first_token_ms рахуються окремо; їх не додаємо. P90 — nearest-rank по всіх викликах моделі, включно з cancelled. Є 6 cancelled; 180 записів мають нормалізований stop/end_turn/completed, а 8 мають порожній нормалізований finish. Порожній finish не перетворюється на інферовану помилку, а 180 stop не означає 180 валідних UI outcomes.

Середні ціни не є контрольованими model tariffs: моделі мають різні input/output/reasoning/cache tokens, різну кількість викликів і різні дати. Операційні агрегати не стверджують ціну восьми моделей за один estimate, не корелюють виклики з конкретними кейсами і не додають енд-ту-енд часу до provider generation time.