Порівняння 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 і CSV: tester, case, model, variant, очікуваний сценарій, видимий outcome, шлях до джерела, hash, якість extraction, вхід і результат;
- каталог вимог і фактичні запити;
- методику, реєстр перевірених доказів і таблицю рішення 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.
Порівняння за погодженими метриками
Якісна частина спирається на критичні вимоги й конкретні приклади, а не на довжину відповідей або 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, E15–E17. «Необґрунтоване доповнення» тут означає оплачуваний 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.
Формат. Видимі estimation results містять звичні блоки бюджету/строків/команди/етапів/assumptions. Повний raw JSON та parser issues відсутні, тому schema compliance не виміряно. Збережені summaries дають конкретні приклади невиконання нинішньої вимоги двох речень у M1/M5. Статичні CTA/disclaimer не додають моделі балів. E17.
Вартість і час за OpenRouter
Додано експорт активності: 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 описує 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, JSON, методика обробки.
Чому не можна вибрати за найменшим бюджетом
На кейсі Алекса з виїзним сервісом головні цифри описують різні продукти:
| Модель | Видима головна картка | Що вона оцінює |
|---|---|---|
| 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.
Спільні продуктові проблеми, які важливіші за заміну моделі
- Достатні короткі запити губляться у fallback. У тестах Свята custom furniture tool і WooCommerce delivery calculator не дали оцінки в жодній конфігурації. У поточному коді input gate перевіряє typed text перед LLM і не отримує вкладення. Потрібно перевірити саме цей шлях і historical gate verdict, а не покладати всі відмови на модель. E13.
- Режим оцінки й підбору змішується. Обидва підбори Оксани — 16 fallback із mode «Оцінка проєкту». У Юри/M1 підбір команди перетворився на кошторис. Це слід відокремлювати від якості matching narrative. E14, E18.
- MVP і full product потребують окремих полів та карток. Нинішній UI завжди підписує headline як час до MVP, навіть коли модель оцінює весь продукт. Додавання
estimate_scopeта окремого MVP/full горизонту зробить відповідь зрозумілішою; це пропозиція, код у цьому аналізі не змінено. - Суперечності вкладень треба явно показувати. GearShare має різні платформи й способи оплати в тексті та flow. Навіть успішні M7/M8 не дають чіткого conflict resolution. Складський sketch не дав успішної оцінки у жодної з восьми. E10–E11.
Кодові джерела: LLM instructions, input gate, gate перед LLM, estimate schema, parser.
Як застосувати рішення
Взяти 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-пілота.