# Порівняння 8 моделей для SoloWay AI Assistant

Дата: 12 жовтня 2026. Аналіз виконано лише за локальним тестовим корпусом і кодом проєкту.

## Рішення

**Рекомендую Модель 7 для контрольованого пілота основного сценарію — попередньої оцінки проєкту для потенційного клієнта.** Вона дає 12/17 готових оцінок у зіставному наборі, 0 видимих estimation technical errors, найсильніше використання політик GearShare та значно нижчі спостережені середня ціна API-виклику й час генерації: $0.004866 за виклик і 26.155 s generation median. Це баланс прийнятної готовності, якості, вартості й очікування; 2 provider cancellations залишаються видимими в операційних даних і не трактуються як нуль усіх збоїв.

**Модель 1 — головний порівняльний кандидат за якістю та покриттям**: вона має найбільше готових оцінок — 13/17 — і сильна на коротких конкретних запитах, але спостережено найдорожча й повільніша ($0.094224 за виклик, 40.812 s generation median). **Модель 8 — альтернатива за швидкістю** з 12/17 і найшвидшою generation median 20.616 s. **Модель 2 — кандидат за поясненням кошторису**: вона найкраще показує години × ставки, межі scope і зовнішні залежності, але має 11/17 готових оцінок і повільніша за M7/M8.

Це вибір для пілота з помірною впевненістю, а не доказ переваги конкретного провайдера або готовності до автономного production. Ідентичності моделей за blind ID у матеріалах не встановлені. Результати також залежать від routing, input gate, prompt, parsing і COWO. Поточний код дозволяє fallback ще **до виклику LLM**. Тому рекомендація стосується найкращого спостереженого бізнес-балансу під ID 7; зростання конверсії та повторювана надійність потребують вимірювання в продукті.

## Що структуровано

Є 6 тестерів, по 3 estimation та 2 matching кейси, 8 blind моделей: **240 очікуваних комірок**. Збережено **241 результат**: 240 PDF/MD та один PNG із ручною транскрипцією; додатковий артефакт — другий варіант складського кейсу Юри/M8. Вхідні PDF, DOCX, зображення й admin notes не змішані з відповідями.

Підготовлено:

- [повний реєстр JSON](../metrics/runs.json) і [CSV](../metrics/runs.csv): tester, case, model, variant, очікуваний сценарій, видимий outcome, шлях до джерела, hash, якість extraction, вхід і результат;
- [каталог вимог](../cases/cases_catalog.md) і [фактичні запити](../cases/actual_requests.json);
- [методику](methodology.md), [реєстр перевірених доказів](evidence-ledger.md) і [таблицю рішення CSV](model-comparison.csv).

Векторизація для цього рішення не потрібна: вона допомогла б шукати схожі фрагменти, але не встановила б арифметичну правильність, покриття або виконання обмежень. База порівняння — зіставлення конкретного запиту з конкретним результатом і збережені джерела. Embeddings можна додати як пошуковий індекс над цим реєстром, не замінюючи ним метрики.

## Готові результати та збої

«Оцінка» означає наявність готового результату, а не підтвердження ціни чи якості всіх його припущень. Таблиця показує всі 18 estimation-комірок на модель. Підбір оцінено окремо: 12 комірок на модель.

| Модель | Готова оцінка / 18 | Estimation fallback | Estimation технічна помилка | Готовий підбір / 12 | Інший matching outcome |
|---:|---:|---:|---:|---:|---|
| **1** | **13** | 4 | 1 | 9 | 2 fallback, 1 оцінка замість підбору |
| 2 | 11 | 6 | 1 | 9 | 2 fallback, 1 технічна помилка |
| 3 | 12 | 5 | 1 | 9 | 2 fallback, 1 технічна помилка |
| 4 | 11 | 6 | 1 | 10 | 2 fallback |
| 5 | 11 | 6 | 1 | 10 | 2 fallback |
| 6 | 11 | 5 | 2 | 9 | 2 fallback, 1 технічна помилка |
| 7 | 12 | 6 | 0 | 10 | 2 fallback |
| 8 | 12 | 5 | 1 варіант | 10 | 2 fallback |

Для M8 у складській комірці два артефакти: технічна помилка та варіант без видимого результату. Вони рахуються окремо в реєстрі, але як одна комірка в таблиці; невідомий результат не прирівнюється до доведеного timeout.

**Сашин estimation case 3 виключено з прямого зіставлення**: різним моделям введено Web3, транскрибацію дзвінків або суперечливе поєднання ToolShare/транскрибації. Після виключення готові оцінки у 17-комірковому наборі:

| Модель | Готові оцінки / 17 | Частка спостережених готових результатів |
|---:|---:|---:|
| **1** | **13** | **76.5%** |
| 2 | 11 | 64.7% |
| 3 | 11 | 64.7% |
| 4 | 11 | 64.7% |
| 5 | 11 | 64.7% |
| 6 | 11 | 64.7% |
| 7 | 12 | 70.6% |
| 8 | 12 | 70.6% |

Ці частки описують невеликий корпус, не є прогнозом conversion rate чи оцінкою статистичної значущості. Відмінність M1 від M7/M8 — лише одна комірка. Повна ідентичність історичних system prompts, gate settings, вкладень і порядку запусків не доведена.

Вибір M7 підтримує найкращий спостережений баланс provider-level cost/time, UI outcome і GearShare з матеріалами. M1 залишається важливим comparator: короткий запит Оксани про транскрибацію й експорт та «Uber для майстрів» Юри дали оцінку лише у M1. Водночас GearShare із матеріалами завершився помилкою у M1–M6 і оцінкою у M7/M8. [Докази E01–E02, E10](evidence-ledger.md).

## Порівняння за погодженими метриками

Якісна частина спирається на критичні вимоги й конкретні приклади, а не на довжину відповідей або keyword scores. Загальний бал не обчислюється: не погоджено ваги й немає еталонного кошторису. Операційні агрегати додано нижче, але вони не прив’язані до окремих кейсів. Нижче наведено сильні сторони й матеріальні обмеження кожної моделі; це дозволяє перевірити компроміси вибору.

| Модель | Покриття вимог і необґрунтовані доповнення | Декомпозиція, обґрунтування та невизначеність | Узгодженість, формат і користь клієнту |
|---:|---|---|---|
| **1** | Сильний поділ MVP/full у field service, конкретні offline/migration/privacy. На книжковому marketplace додає gateway, не заданий клієнтом. | Докладні етапи й межі; на коротких запитах робить явні припущення й дає результат. Вартість зазвичай без відтворюваного розрахунку годин. | Найбільше готових оцінок; A1 має три речення summary. На vague Y2 confidence «Середній» оптимістичний. GearShare помилка, image/sketch склад fallback. |
| **2** | Найкраще стримує зайвий scope: ручна оцінка Vaultix, без gateway для книжок; розмежовує MVP/full. | Найпрозоріші години × ставки; конкретні межі AI Vision, КЕП/реєстру, доступності API. Сильний Odoo staffing budget. | П’ять перевірених розрахунків сходяться. Але A1/Energy hero показує повний продукт під MVP-label; короткі O3/Y2 не дали оцінки. |
| **3** | Детальні основні модулі; у Calmi обирає native Swift/Kotlin за референсом, тому ціна не співставна зі Flutter без нормалізації scope. | Конкретні етапи, залежності й parallel execution; Vaultix розмежовує ручну ринкову ціну та автопідсумок. | У зіставному наборі 11 готових оцінок. Є phrases `/q0/q0` у тексті книжкового чату — видимий артефакт, без встановленої причини. S3 не зараховано як перевагу. |
| **4** | Детальний scope, але у книжках додає gateway/commission; широкі обіцянки реалізації. | Етапи зрозумілі, припущення названі; окремий коефіцієнт +25–30% native не обґрунтований локальним розрахунком. | A1 full/MVP mismatch; Odoo staffing не пояснює fit у cap $25K при full-time Senior $60/h. Переваги completion над M1 немає. |
| **5** | Стислий і контрольований scope Vaultix/Calmi; у Calmi явно зберігає deletion, confirmation, audit trail та safe-use. Gateway книжок усе ж додано. | Практичні assumptions і deferrals; етапи менш деталізовані за M1/M2. Годинна база кошторису не показана в перевірених прикладах. | A1 і книжки мають однореченнєві summaries. Менші цифри самі по собі не доводять точності або кращої конверсії. |
| **6** | Покриває основні функції та future scope; Vaultix без цінових API, Calmi із зовнішнім AI й приватністю. | Зрозумілі стандартні етапи; Odoo staffing загальний і без fit-розрахунку. | Найбільше estimation technical errors у наборі: 2. На основному сценарії немає показаної переваги над M1/M2; 11 готових оцінок. |
| **7** | Найдокладніше використала політики GearShare; ширший scope. У Vaultix hero «автоматична оцінка» залежить від непідтвердженого джерела цін. | Детальна декомпозиція, численні інтеграції та припущення. Не розв’язує явно суперечності GearShare; трапляється категоричний sales tone. | 0 видимих estimation technical errors; 12 готових оцінок. A1 full/MVP mismatch; fallback на O3/Y2. Хороший challenger для матеріалів. |
| **8** | Основні модулі стисло описані; у A1 немає окремої числової оцінки full product, у GearShare менше конкретних policy details. | Lean/cross-platform підхід; слабше пояснює числову базу й суперечності вкладень. Calmi safe-use/fallback/audit trail не так явно розписані. | 12 готових оцінок; часто коротші строки, що не є доказом реалізовності. Warehouse variants не дали оцінки. Твердження «майже вдвічі» економії не обґрунтоване. |

Перевірені приклади й джерела: [E03–E10](evidence-ledger.md), [E15–E17](evidence-ledger.md). «Необґрунтоване доповнення» тут означає оплачуваний scope або категоричний факт без основи у вхідних матеріалах; явно назване припущення не прирівнюється автоматично до hallucination.

**Арифметика.** Найкраще перевіряється M2: Calmi $107,800–129,700, Energy total $180,800–225,500 та MVP $74,300–92,050, coworking $34,820 і Odoo staffing $24,660 відтворюються. Це обґрунтовує вибір M2 як challenger; не підтверджує, що заданих годин достатньо для всіх вимог. Для решти немає підстав оголошувати всі числа неправильними через відсутність такого деталізованого розрахунку. Сума етапів, monthly ranges і role headcount не штрафувалися механічно. [E07–E09](evidence-ledger.md).

**Формат.** Видимі estimation results містять звичні блоки бюджету/строків/команди/етапів/assumptions. Повний raw JSON та parser issues відсутні, тому schema compliance не виміряно. Збережені summaries дають конкретні приклади невиконання нинішньої вимоги двох речень у M1/M5. Статичні CTA/disclaimer не додають моделі балів. [E17](evidence-ledger.md).

## Вартість і час за OpenRouter

Додано [експорт активності](../../openrouter_activity_2026-10-12.csv): **188 унікальних викликів, сумарно $7.132567**. Unix-префікси `generation_id` відповідають періоду **8–9 жовтня 2026 UTC**, а не дню 12 жовтня з назви файлу. Усі записи явно позначені `Модель1`…`Модель8`; зіставлення з blind ID пряме, але реальні назви провайдерських моделей не розкриваються.

| Модель | Виклики | Сума, USD | Середня ціна API-виклику, USD | Генерація: медіана, с | Генерація: P90, с | Перший токен: медіана, с | Скасовані |
|---:|---:|---:|---:|---:|---:|---:|---:|
| 1 | 25 | 2.355604 | 0.094224 | 40.812 | 60.896 | 4.690 | 0 |
| 2 | 23 | 0.690760 | 0.030033 | 44.634 | 71.955 | 10.894 | 0 |
| 3 | 26 | 0.090955 | **0.003498** | 80.230 | 195.233 | 1.058 | 2 |
| 4 | 23 | 1.694565 | 0.073677 | 71.721 | 158.452 | 1.198 | 1 |
| 5 | 23 | 0.965024 | 0.041958 | 87.584 | 151.358 | 2.631 | 1 |
| 6 | 23 | 0.965170 | 0.041964 | 115.297 | 227.706 | 1.313 | 0 |
| 7 | 26 | 0.126518 | 0.004866 | 26.155 | 51.120 | **0.789** | 2 |
| 8 | 19 | 0.243971 | 0.012841 | **20.616** | **30.369** | 2.768 | 0 |

Середня ціна — `cost_total / кількість записаних викликів`. Медіана й P90 пораховані за всіма спробами, включно зі скасованими; P90 — nearest-rank. Значення `generation_time_ms` і `time_to_first_token_ms` переведено в секунди та показано окремо: їх не додавали. Це **таймінги провайдера, не повний час очікування клієнта** з upload/OCR, input gate, parsing і COWO.

У самому CSV немає поля валюти. USD — інтерпретація за локальним контрактом: [LLM client](D:/work/CTO/www/soloway-aiassistant-monorepo-original/apps/api/src/modules/llm/llm-client.service.ts:38) описує OpenRouter `usage.cost` як USD. `cost_total` використано без повторного додавання інших cost-полів чи розрахунку тарифів із токенів.

Це різні за довжиною входу/відповіді й використанням cache виклики, без case/session ID. Тому **188 API-викликів не зіставлено з 240 тестовими комірками**, ціна одного API-виклику не є ціною готової оцінки, а скасування не прирівнюються до техпомилок у PDF. У CSV 6 скасувань, 180 `stop` та 8 порожніх finish reason; порожній reason сам по собі не доводить помилки, а `stop` не доводить коректної відповіді UI. Зокрема, M7 має 2 скасування у CSV попри 0 видимих estimation-техпомилок у тестових PDF.

**Практичний висновок:** M7 у цьому журналі приблизно у **6.2 раза дешевша за M2** за середньою ціною API-виклику, із медіаною генерації **26.2 проти 44.6 с**. M8 має найменші медіану й P90 генерації; M3 — найменшу середню ціну, але значно більші таймінги. M1 дає найбільше готових оцінок у MD-корпусі, проте має найбільшу середню ціну API-виклику — приблизно **19.4 раза вище M7**. Це опис експорту, не прогноз вартості на однаковому production-навантаженні.

Повні середні, медіани, P90, діапазони, токени та окремий зріз завершених викликів: [операційний CSV](../operations/model-operations.csv), [JSON](../operations/model-operations.json), [методика обробки](../operations/README.md).

## Чому не можна вибрати за найменшим бюджетом

На кейсі Алекса з виїзним сервісом головні цифри описують різні продукти:

| Модель | Видима головна картка | Що вона оцінює |
|---:|---|---|
| 1 | $82–102K; 15–18 тижнів | MVP; full product окремо як додаткові роботи |
| 2 | $142–172K; 36–44 тижні | Повний total; MVP $43.1–45K / 14–16 тижнів у narrative |
| 3 | $78–100K; 14–18 тижнів | MVP зі своїми deferrals |
| 4 | $140–170K; 35–42 тижні | Повний продукт; MVP $70–85K у narrative |
| 5 | $86–112K; 16–20 тижнів | Пілот; full product $170–230K окремо |
| 6 | $105–125K; 16–20 тижнів | MVP; наступна фаза окремо |
| 7 | $180–260K; 32–42 тижні | Повний описаний продукт; ранній пілот — підмножина |
| 8 | $41.5–47.8K; 14–16 тижнів | MVP; окремого full budget немає |

Отже, автоматична медіана цих восьми карток змішала б MVP і full product. Аналогічно на книжках M2 виключає gateway, який інші додають. «Ближче до середньої» та «дешевше» тут не є метриками правильності. [E03–E06](evidence-ledger.md).

## Спільні продуктові проблеми, які важливіші за заміну моделі

1. **Достатні короткі запити губляться у fallback.** У тестах Свята custom furniture tool і WooCommerce delivery calculator не дали оцінки в жодній конфігурації. У поточному коді input gate перевіряє typed text перед LLM і не отримує вкладення. Потрібно перевірити саме цей шлях і historical gate verdict, а не покладати всі відмови на модель. [E13](evidence-ledger.md).
2. **Режим оцінки й підбору змішується.** Обидва підбори Оксани — 16 fallback із mode «Оцінка проєкту». У Юри/M1 підбір команди перетворився на кошторис. Це слід відокремлювати від якості matching narrative. [E14, E18](evidence-ledger.md).
3. **MVP і full product потребують окремих полів та карток.** Нинішній UI завжди підписує headline як час до MVP, навіть коли модель оцінює весь продукт. Додавання `estimate_scope` та окремого MVP/full горизонту зробить відповідь зрозумілішою; це пропозиція, код у цьому аналізі не змінено.
4. **Суперечності вкладень треба явно показувати.** GearShare має різні платформи й способи оплати в тексті та flow. Навіть успішні M7/M8 не дають чіткого conflict resolution. Складський sketch не дав успішної оцінки у жодної з восьми. [E10–E11](evidence-ledger.md).

Кодові джерела: [LLM instructions](D:/work/CTO/www/soloway-aiassistant-monorepo-original/apps/api/src/modules/llm/llm.constants.ts), [input gate](D:/work/CTO/www/soloway-aiassistant-monorepo-original/apps/api/src/modules/session/input-quality-gate/session-input-gate.service.ts:26), [gate перед LLM](D:/work/CTO/www/soloway-aiassistant-monorepo-original/apps/api/src/modules/session/sessions.service.ts:328), [estimate schema](D:/work/CTO/www/soloway-aiassistant-monorepo-original/packages/types/src/estimation.ts), [parser](D:/work/CTO/www/soloway-aiassistant-monorepo-original/apps/api/src/modules/estimation/estimate-parser.ts).

## Як застосувати рішення

Взяти blind ID 7 як основний кандидат порівняльного estimation-пілота, M1 — quality/coverage comparator, M8 — fast alternative, а M2 — challenger за прозорістю scope і кошторису. Для matching окремої переваги M1 немає: M4/M5/M7/M8 мають по 10 видимих підборів проти 9 у M1, але retrieval quality не виміряно.

Рішення чутливе до пріоритетів: за максимальної арифметичної прозорості варто обрати M2; за поєднанням ціни, часу генерації, GearShare outcome і готовності — M7 має сильнішу позицію. M1 зберігає перевагу в одному готовому результаті зіставного набору. Без погоджених ваг та однакового навантаження немає підстав перетворювати це на точний сумарний бал.

Перед масштабуванням пілота достатньо одного контрольного набору з тим самим input, attachments, pinned mode, prompt/pricing/gate versions для всіх кандидатів і кількох повторів. Зберігати model identity/version, raw reply, parse result, gate verdict, latency, токени й фактичну вартість. Вимірювати конверсію від показу результату до контакту з командою й частку оцінок, які PM суттєво перерахував. Це майбутні перевірки; поточний звіт не підміняє їх вигаданими даними.

**Фінальний вибір після доповнення OpenRouter: Модель 7 для основного пілота; Модель 1 як quality/coverage comparator, M8 як fast alternative, M2 як estimate explainability challenger.** Сильніший числовий baseline і перевірка продуктового pipeline потрібні, щоб перетворити цей вибір на стабільне production-рішення.

## Фінальний лідерборд

Це експертний бізнес-пріоритет для пілота, без агрегованого числового score і вигаданих ваг. Порядок балансує прийнятну якість, готовність, середню ціну API-виклику та час генерації провайдера; він не доводить універсальну перевагу моделі чи conversion. M7 випереджає M1 попри 12/17 проти 13/17: різниця в одну комірку на малому зіставному наборі компенсується 0 проти 1 видимої UI estimation error, приблизно у 19.4 раза нижчою середньою ціною API-виклику ($0.004866 проти $0.094224), медіаною часу генерації 26.155 проти 40.812 s і найкращим GearShare policy coverage. Для M7 збережено 2 provider cancellations; це не означає нуль усіх збоїв. Знаменник **17** — зіставні estimation-комірки після виключення Sasha E3; **18** — усі estimation-комірки для UI technical errors. 188 API-викликів не приєднані до 240 test cells, USD випливає з контракту проєкту, а provider time не є end-to-end latency.

| Місце | Модель | Готові оцінки / 17 | UI-помилки оцінки / 18 | Середня ціна API, USD | Медіана generation, s | P90 generation, s | Основна причина / рішення |
|---:|---:|---:|---:|---:|---:|---:|---|
| **1** | **M7** | 12 (70.6%) | **0** | 0.004866 | 26.155 | 51.120 | Найкращий спостережений баланс якості, вартості й часу; найсильніший GearShare. Основний пілотний кандидат. |
| **2** | **M1** | **13 (76.5%)** | 1 | 0.094224 | 40.812 | 60.896 | Найбільше готових оцінок і сильне покриття коротких запитів, але найдорожча та повільніша за M7. Порівняльний кандидат за якістю та покриттям. |
| **3** | **M8** | 12 (70.6%) | 1 | 0.012841 | **20.616** | **30.369** | Найшвидша модель із 12 готовими оцінками; слабше покриває policy details, складський кейс має помилковий та невідомий варіанти. Альтернатива за швидкістю. |
| **4** | **M2** | 11 (64.7%) | 1 | 0.030033 | 44.634 | 71.955 | Найкраща перевірена арифметика й пояснення кошторису, але менше готових оцінок і повільніша за M7/M8. |
| **5** | **M3** | 11 (64.7%) | 1 | **0.003498** | 80.230 | **195.233** | Найдешевша, але має довгий P90 і видимий `/q0/q0` артефакт. |
| **6** | **M5** | 11 (64.7%) | 1 | 0.041958 | 87.584 | 151.358 | Контрольований scope; приблизно на 43% дешевша за M4 і має трохи нижчий P90, але повільніша медіана. |
| **7** | **M4** | 11 (64.7%) | 1 | 0.073677 | 71.721 | 158.452 | Детальний scope, але дорожча за M5 і має MVP/full mismatch та слабше пояснені коефіцієнти. |
| **8** | **M6** | 11 (64.7%) | **2** | 0.041964 | **115.297** | **227.706** | Найбільше UI estimation errors і найповільніша медіана generation; показаної переваги немає. |

Matching залишається окремою довідковою метрикою, а не основою цього порядку. M7/M8/M4/M5 мають по 10 готових підборів проти 9 у M1; це не змінює рішення для основного estimation-пілота.