ChatGPT vs Claude vs Gemini для аналізу даних: що обрати

Для разового аналізу чистого CSV почніть із продукту, який у вашій конфігурації показує виконаний код, проміжні таблиці та придатний до завантаження результат. ChatGPT документує Python-backed analysis, інтерактивні таблиці й частково інтерактивні графіки. Claude документує sandbox для code execution, аналіз CSV/XLSX і створення Excel-файлів із формулами та візуалізаціями. Gemini Apps аналізує завантажені spreadsheets, створює графіки та може формувати або експортувати Sheets-файли. Це capability map, а не доказ, що один сервіс точніший за інші.

Для workbook-centric фінансової моделі окремо перевірте Claude for Excel із cell-level citations і збереженням formula dependencies. Для процесу, де authoritative source уже живе в Google Sheets і результат має лишитися в Workspace, перевірте Gemini. Для ad hoc статистики, трансформацій і дослідження коду аналізу — ChatGPT. Остаточне рішення приймайте лише на однаковому masked dataset: доступність залежить від plan, account, region, admin settings і дати тесту.

• Чистий CSV і прозорий Python workflow → протестуйте ChatGPT та Claude.
• Складний Excel workbook із формулами → додайте окремий тест Claude for Excel.
• Google Sheets як system of record → додайте Workspace-native сценарій Gemini.
• Критичне рішення → незалежно перерахуйте ключові числа й перевірте lineage.
• Немає відтворюваного evidence package → не приймайте красивий висновок.

Один vendor може мати chat upload, project files, spreadsheet add-in, connected drive і API. Вони відрізняються доступом до файлів, інструментами, retention, можливістю запису та способом перевірки. Результат Claude у звичайному чаті не доводить поведінку add-in в Excel; Gemini Apps не тотожний side panel у Workspace; ChatGPT Data Analysis не тотожний довільному custom GPT або API notebook.

Перед тестом запишіть capability manifest: product surface, plan, model або automatic routing state, code execution, network egress, supported input, output artifact, connector scope, admin policy та дату. Стани мають бути `verified`, `restricted`, `unavailable` або `unknown`. Не заповнюйте невідоме з маркетингової сторінки іншого plan.

Створіть одну tidy-версію набору: один рядок на observation, стабільні column names, явні одиниці, timezone, currency, missing-value convention і data dictionary. Окремо збережіть messy-версію з merged cells, subtotal rows, прихованими колонками, формулами, дублями й неоднозначними датами. Чиста таблиця перевіряє аналітичний метод; messy workbook — здатність побачити ingestion risk.

До завантаження приберіть secrets і непотрібні персональні поля, замініть identifiers стабільними pseudonyms та зафіксуйте checksum dataset. Якщо точні значення містяться у скані або зображенні таблиці, спочатку зробіть контрольований extraction і field validation: жоден із асистентів не слід оцінювати так, ніби visual parsing автоматично створює надійний numeric source.

Дайте однакове бізнес-питання, dataset і acceptance criteria. Наприклад: очистити orders, пояснити exclusions, порахувати weekly conversion із правильним denominator, порівняти cohorts, побудувати графік із confidence interval і повернути таблицю винятків. Забороніть зовнішнє збагачення на першому етапі, щоб кандидати працювали з тим самим evidence.

Вимагайте machine-readable analysis manifest: вхідні файли й hashes, використані sheets/columns, transformations, assumptions, code або formulas, rows excluded, warnings, output files і reconciliation totals. Natural-language narrative має посилатися на конкретний output field чи chart series. Якщо сервіс не відкриває весь execution trace, попросіть його створити standalone script або workbook formulas, які reviewer може запустити окремо.

• Schema check → типи, keys, дублікати, nulls і одиниці.
• Reconciliation → totals до й після кожного filter або join.
• Method → формула, statistic і причина вибору.
• Evidence → code/formulas, output table та chart source range.
• Narrative → лише твердження, підтримані розрахованим artifact.

Aggregate score приховує критичні помилки. Створіть slices для decimal arithmetic, currency conversion, timezone boundary, missing values, duplicate keys, one-to-many join, Simpson’s paradox, small sample, outlier policy, confidence interval і leakage між train та test. Для кожного case підготуйте deterministic oracle або adjudicated expected range.

Statistical method не можна оцінювати лише за тим, чи запускається код. Reviewer перевіряє assumptions, population, denominator, multiple comparisons, causal language та sensitivity. Асистент має відмовитися від причинного висновку з observational correlation і позначити insufficient evidence. Різниця між двома округленими числами без uncertainty не є надійним бізнес-висновком.

Для Excel перевірте, чи результат містить formulas, а не hard-coded values; чи ranges не зсунулися; чи збережені types, locale, named ranges і dependencies; чи зміна input справді перераховує output. Cell citation корисна для навігації, але не замінює повторний розрахунок. Для Python збережіть script/notebook, package versions, random seed і stdout із reconciliation checks.

Для графіка перевірте source range, aggregation, axis origin, scale, missing periods, sorting, labels та accessibility. Просіть data table поруч із chart. Інтерактивність зручна для exploration, але для аудиту потрібен versioned static artifact і underlying data. Не оцінюйте кандидата за polish презентації, якщо інший отримав запит лише на сирий CSV.

Формули, comments, hidden sheets, external links і текстові клітинки можуть містити помилки або prompt injection. Anthropic прямо застерігає використовувати Claude for Excel лише з trusted spreadsheets. Цей принцип ширший за один продукт: зовнішній workbook треба сканувати, відкривати без macros/external refresh, показувати hidden content і запускати у мінімально привілейованому середовищі.

Code execution і network egress — різні permissions. Для confidential dataset вимкніть непотрібний network access, connector writes та автоматичний export; перевірте data controls і retention саме вашого workspace. Аналіз не повинен самостійно оновлювати system of record. Спершу створюється versioned proposal, потім reviewer звіряє totals, і лише окрема authorized дія записує затверджений результат.

Оцінюйте schema detection, calculation correctness, join correctness, method validity, reproducibility, chart integrity, supported-claim rate, abstention, reviewer corrections і time-to-accepted-artifact. Critical failure — витік поля, неправильний denominator, silent row loss, fabricated source, broken formula dependency або causal claim без дизайну. Один critical failure не можна сховати високою середньою оцінкою стилю.

TCO включає license/usage, підготовку даних, prompt iteration, людську перевірку, виправлення workbook, повторний запуск, governance і incident handling. Проведіть щонайменше два repeats для stochastic кроків і blind review без назви vendor. Не публікуйте локальний результат як універсальний рейтинг: він доказує fit лише для зафіксованого dataset, surface і acceptance contract.

Після bake-off зафіксуйте approved template: allowed sources, data classification, analysis manifest, checks, reviewer role, output location і retention. Перші запуски залиште shadow або draft-only. Promotion дозволяється лише після стабільного slice-level pass і reconciliation з чинним ручним process; оновлення model, add-in, connector або admin policy запускає targeted re-evaluation.

Rollback повертає команду до попереднього verified template або manual notebook, блокує writes і зберігає inputs, outputs, code, formulas та review verdict для розбору. Якщо candidate перестає відтворювати результат, не намагайтеся компенсувати це дедалі довшим prompt: позначте regression, звузьте scope і відновіть останню відому робочу конфігурацію.

Порівняння швидко застаріває, якщо команда зберігає лише фінальну відповідь. Для кожного запуску створіть run manifest: hash вхідного файла, schema version, product surface, plan, доступні tools, model або automatic-routing state, instructions, locale, timezone, package versions, час запуску та IDs вихідних artifacts. Окремо зафіксуйте контрольні totals і expected invariants — наприклад, унікальність order_id, суму revenue до exclusions і допустимий діапазон cohort count. Це дозволяє відрізнити зміну даних від зміни продукту або методу.

Повторний запуск оцінюйте не через буквальну тотожність prose, а через semantic і numeric diff. Спочатку порівняйте schema, row counts, exclusions, join cardinality, formulas/code, chart source data та ключові числа; потім — висновки й uncertainty. Класифікуйте розбіжність як input drift, configuration drift, method drift, stochastic variation або defect. Якщо причина невідома, результат не переходить до business decision, навіть коли новий текст звучить переконливіше.

Визначте re-evaluation triggers до rollout: новий model або routing state, зміна add-in чи connector, інший file parser, оновлення workbook template, новий data classification, зміна admin policy або critical incident. Для кожного trigger запускайте лише релевантні slices плюс невеликий regression core. Full bake-off потрібен при зміні authority boundary або коли targeted test знаходить critical failure; так команда не плутає регулярний контроль із нескінченним конкурсом демо.

• Identity → dataset hash, schema version, surface, plan, tools і run timestamp.
• Invariants → row counts, unique keys, totals, exclusions і allowed ranges.
• Diff → code/formulas, output tables, chart data, claims і uncertainty.
• Decision → accept, investigate, rollback template або rerun після виправлення.

Придатний до аудиту handoff має жити поза тимчасовою conversation surface. Мінімальний package містить masked input reference і hash, data dictionary, analysis brief, run manifest, executable script або workbook із formulas, environment lock, output tables, chart source data, reconciliation report, assumptions, warnings і reviewer verdict. Експортований CSV або XLSX є output artifact, але сам по собі не пояснює, які rows було відкинуто, який join виконано і чому narrative підтримується числами.

Reviewer починає не з перечитування відповіді, а з незалежних checks: відкриває package у чистому середовищі, повторно рахує critical totals, змінює один sentinel input і перевіряє перерахунок, звіряє chart із underlying table та простежує кожне material claim до конкретного field. Якщо сервіс приховав частину execution trace, команда додає відтворюваний replacement script або ставить evidence status `incomplete`; не можна заповнювати прогалину припущенням, що vendor виконав очевидний метод.

Завершіть handoff retention і deletion contract: де лежать inputs та outputs, хто має read/write access, коли видаляються chat files, project copies, connected-source exports і локальні downloads, та як deletion перевіряється. Для наступного аналізу використовуйте approved template й новий immutable run ID, а не редагуйте попередній evidence package. Це зберігає lineage, дозволяє rollback до останнього accepted artifact і не надає аналітичному асистенту права записувати результат у system of record.

• Package → input reference, manifest, executable method, outputs і reconciliation.
• Review → clean rerun, sentinel change, chart trace і claim-to-field mapping.
• Verdict → accepted, accepted-with-limits, rejected або evidence-incomplete.
• Lifecycle → immutable run ID, retention owner, verified deletion і rollback pointer.