Як ми вимірюємо

1. Навіщо існує ця сторінка

Скептично налаштовані покупці не повинні самотужки розбиратися, що стоїть за маркетинговим текстом. Maguyva індексує репозиторії та подає по всьому сайту твердження про точність, охоплення мов і вартість. Для цих тверджень потрібна сторінка методології, яка чесно пояснює межі вимірювання: що підтверджують тестові набори, що спирається на оцінювання, а що є лише способом подачі, а не незалежною сертифікацією.

2. Що ми вимірюємо

Якість інтелекту коду вимірюється передусім на мовному рушії — вилучення символів, зв'язків і графів із вихідного коду, — а не за суб'єктивними оцінками «задоволеності агента».

• Тестові набори для кожної мови: очікувані ребра та символи, які обробник має вилучити коректно
• Класифікація точності на фікстурах: GREEN вимагає точності ≥ 0.95, повноти ≥ 0.99, F1 ≥ 0.97 і щонайменше 20 очікуваних ребер, а також додаткових перевірок добору фікстур. Це правило для відомих тестових випадків, а не оцінка статистичної впевненості чи твердження, що кожна ввімкнена мова має статус GREEN.
• Виміри language-audit: точність, структурна цілісність, повнота, якість і продуктивність на дошці валідації
• Цикли за корпусами та вибірковими перевірками: ребра з реальних репозиторіїв, узяті як вибірка та класифіковані за рубрикою (правильно, хибнопозитивно, помилка типу/області/метаданих), — описані в наших дописах блогу про language-grind
• Прапорці можливостей продукту: те, що оголошує сервер (AST, аналіз локальних областей видимості, вилучення графа), окремо від розміру каталогу

Важливо: Перевірка спирається на тестові набори, які ми написали самі. Зелений статус означає, що відомі випадки проходять перевірку. Він не означає автоматично, що рушій коректно видобуває дані з кожної конструкції реального коду. Це розрізнення навмисне й публічне.

3. Зелений статус проти незалежно підтвердженого

Дошка language-audit використовує кілька осей, щоб один зелений індикатор не можна було прочитати як «доведено бездоганно». Ключові числа на дошці зазвичай розбиті на:

• overall_green — відсутність регресій відносно тестових наборів на основі власних знімків і пов'язаних перевірок на корпусах (необхідна, але не достатня умова)
• independently_verified — має сильний сигнал оцінювання, наприклад початкова вибірка для вибіркової перевірки (включає мови, де все ще видно оцінені помилки)
• verified_clean / нуль оцінених помилок на вибіркових ребрах — суворіша підмножина оцінених мов
• добір тестових випадків / довіра до еталона — чи вважаються самі тестові набори надійними еталонами
• структурні прапорці — вилучення графа та можливість AST не тотожні членству в каталозі

Маркетинговий лічильник мов (наприклад, «285+ мов») — це розмір каталогу: налаштовані мови та записи сервера. Розмір каталогу не є SLA якості AST. Надавайте перевагу багаторівневій звітності перед єдиною ефектною цифрою. Актуальні можливості продукту див. у розділах «Сумісність» і «Посібники з мов»; оповідні деталі — у дописі блогу про рекурсивне самовдосконалення мов.

4. Якість пошуку та отримання результатів

Якість семантичного пошуку мультимодальна: об'єднуються текст, AST, граф та ембединги. Ми документуємо свідомі інженерні компроміси, а не заявляємо про неперевершену якість пошуку:

• Ембединги використовують комерційне сімейство моделей (voyage-4-large станом на знімок блогу за червень 2026 року), обране відносно публічних рейтингів якості пошуку на момент ухвалення рішення
• Вектори бінарно квантуються заради зберігання та вартості; це свідомо жертвує частиною точності пошуку заради дешевшого та швидшого пошуку Геммінга без окремої векторної бази даних
• Маршрутизація за наміром і ваги злиття — це спроєктовані евристики. У пропозиції від грудня 2025 року початкову частку запитів без результатів оцінювали приблизно у 15%, а цільове значення встановили нижче 5%; ми не надали набору запитів або протоколу вимірювань, що підтверджує таке зниження. Запис із підтвердними матеріалами виправляє попереднє твердження про досягнуте поліпшення.
• Дописи блогу містять розділи «що все ще недосконале» — недосконалі сигнали є частиною запису, а не виносками для приховування

5. Твердження про вартість

Мова вартості в Maguyva стосується структури ціноутворення та операційної прозорості, а не формального дослідження TCO, сертифікованого третьою стороною.

• Ціноутворення робочого простору: рахунок виставляється за репозиторіями, проіндексованими рядками та частотою перезбирання, а не за місце людини чи агента. FAQ і текст тарифів докладно описують ці виміри.
• Приклад ціни порівнює 25 платних місць за ілюстративною ціною $19–$59 за місце з Crew за $49/місяць. Економія залежить від розміру команди й альтернативного продукту; це не порівняння однакових функцій і не незалежний конкурентний бенчмарк.
• Чесність операційних витрат: сторінка /team публікує реальну помісячну розбивку витрат на ПЗ (підписки, інструменти MCP/пошуку, витрати, залежні від використання). Це прозорість «клієнта номер нуль», а не аудійована фінансова звітність.
• Витрати на ембединги та інфраструктуру — це прийняті продуктові витрати (преміальні ембединги, зберігання, перезбирання графа). Ми несемо їх навмисно і говоримо про це в дописі про voyage-4-large та в описі ціноутворення.

6. Чого ми не заявляємо

Ця сторінка також є переліком того, чого ми не заявляємо. Якщо чогось немає на дошці вимірювань, не сприймайте маркетинговий тон як доказ.

• Жодної всеосяжної гарантії абсолютної точності для кожної мови. Пороги для тестових наборів застосовуються для кожної мови до відомих випадків; залишкові помилки в реальному коді очікувані, і ми постійно працюємо над їх усуненням.
• Жодного твердження, що overall_green дорівнює ідеальному в продакшені вилученню для кожної ідіоми репозиторію
• Жодного пакета сертифікації відповідності від третьої сторони, заявленого як методологічний артефакт на цій сторінці (факти про обробку даних див. у розділі «Безпека», а не значки відповідності)
• Жодного незалежного багатопостачальницького порівняння на спільних корпусах, опублікованого як постійна оцінна таблиця
• Результати пошуку та аналізу надаються з докладанням усіх зусиль, але без гарантій згідно з Умовами обслуговування — Maguyva не замінює рев'ю коду, тестування чи аудит безпеки

7. Як перевірити самостійно

Передбачуваний сценарій покупця досі такий: проіндексуйте репозиторій, який ви вже розумієте, поставте одне реальне запитання і вивчіть посилання на джерела.

• Почніть безкоштовно: невеликі репрезентативні репозиторії першого ж дня кращі, ніж індекс усієї компанії
• Використовуйте інструменти MCP (intelligent_search, find_symbol, dependency_search) і відкривайте процитовані шляхи
• Прочитайте «Як це працює», щоб зрозуміти архітектуру завантаження даних та пошуку
• Прочитайте «Сумісність» і «Посібники з мов», щоб дізнатися рівні можливостей, а не лише розмір каталогу
• Прочитайте «Безпека» і «Конфіденційність» про обробку даних; ця сторінка їх не замінює