ChatGPT Deep Research vs Gemini vs Perplexity Research: як обрати

ChatGPT Deep Research, Gemini Deep Research і Perplexity Research належать до одного класу продуктів: вони виконують багатокроковий пошук, читають кілька джерел і синтезують розгорнутий результат із посиланнями. Це відрізняється від звичайного AI-пошуку, де головна цінність — швидка відповідь на один запит. У deep research користувач делегує частину планування дослідження, тому помилка в scope або джерельній стратегії може масштабуватися на весь красивий звіт.

Не існує стабільного універсального переможця. Для кожного режиму перевірте, чи можна уточнити або відредагувати план, які веб- та підключені джерела він реально використовує, наскільки зручно відкрити evidence і що команда отримує після завершення: текст, citations, таблицю, файл або відтворюваний research record. Функції, квоти, моделі й доступність залежать від плану, регіону та дати, тому ця сторінка дає метод вибору, а не мінливий рейтинг.

Звичайний search flow часто виглядає як `query → retrieval → короткий synthesis → citations`. Глибоке дослідження додає декомпозицію питання, кілька пошукових ітерацій, читання повніших матеріалів, уточнення прогалин і побудову довшого артефакту. Це корисно для market landscape, огляду технічних підходів або підготовки decision brief, але збільшує ціну неправильної передумови: агент може послідовно дослідити не те питання.

Перед запуском сформулюйте research contract: рішення, яке має підтримати звіт; межі теми; країна й часовий період; обов’язкові першоджерела; заборонені або другорядні джерела; формат результату; невідомі, які треба залишити невідомими. Якщо потрібен один чинний тариф, дата релізу або визначення з документації, deep research створить зайву складність — відкрийте першоджерело або використайте звичайний AI-пошук із ручною перевіркою.

Почніть із плану. Дослідник має показати, як він розклав питання, а користувач — мати можливість виправити scope до дорогого виконання або швидко зупинити хибну гілку. Далі перевірте контекст: чи задача потребує лише відкритого вебу, чи також дозволених файлів і робочих джерел. Не вважайте наявність connector автоматичним дозволом читати всю корпоративну інформацію; identity, scope і data policy мають бути визначені окремо.

Для evidence оцінюйте не кількість посилань, а зв’язок `atomic claim → supporting passage → authoritative source`. Для handoff перевірте, чи зручно експортувати результат у робочий документ без втрати citations, чи видно дату виконання та чи може reviewer відтворити ключові пошуки. ChatGPT, Gemini й Perplexity варто пропустити через однаковий brief: назви вкладок і маркетингові feature lists не замінюють end-to-end тесту.

• План → видно декомпозицію, межі та можливість виправлення.
• Контекст → веб, файли й connectors мають явну authority boundary.
• Evidence → першоджерела, passage-level support, дата та scope.
• Handoff → редагований результат, citations і review trail.
• Operations → квоти, час виконання, повторний запуск і data controls.

Випишіть із фінального звіту твердження, які впливають на рішення: числові показники, product capabilities, юридичний scope, дати, причинні висновки та рекомендації. Для кожного збережіть URL, supporting passage, publisher, дату, тип джерела і verdict: supported, partially supported, contradicted або unsupported. Citation поруч з абзацом не доводить автоматично кожне речення в ньому.

Джерельна ієрархія залежить від claim. Офіційна документація підтримує характеристику продукту, але не vendor-independent висновок про перевагу. Customer story підтверджує лише атрибутований досвід сторін. Наукова стаття потребує перевірки дизайну, вибірки й обмежень; нормативне твердження — чинного первинного тексту та юрисдикції. Якщо джерела конфліктують, звіт має показати конфлікт, а не мовчки обрати зручну версію.

Підготуйте 12–20 задач щонайменше чотирьох типів: landscape з багатьма учасниками, технічне порівняння, time-sensitive policy scan і питання з неповними або суперечливими доказами. Додайте known-answer anchors та пастки: застарілу сторінку, SEO-агрегатор вище першоджерела, плутанину між анонсом і загальною доступністю, метрику без denominator. Запускайте сервіси в близький час з однаковим brief і дозволеним набором файлів.

Reviewer не повинен бачити бренд під час першого оцінювання. Рахуйте coverage обов’язкових питань, source-authority mix, citation entailment, freshness, conflict detection, unsupported-claim rate, час до перевіреного результату й edit distance до прийнятного документа. Окремо фіксуйте виконання, що зависло або потребувало restart. Середній бал без slices небезпечний: сервіс може добре робити широкий landscape і водночас погано знаходити точний нормативний документ.

Owner формує brief і перелік must-check sources; оператор запускає дозволений сервіс; research agent повертає звіт; reviewer проводить claim audit; domain expert перевіряє consequential conclusions; decision owner приймає або відхиляє рекомендацію. Не давайте research mode повноваження автоматично закуповувати продукт, змінювати policy, публікувати юридичний висновок або надсилати зовнішню комунікацію. Його output — evidence pack, а не authority grant.

Збережіть decision record: версію brief, дату, назву режиму й доступний план, дозволені джерела, фінальний звіт, claim ledger, невирішені прогалини та reviewer sign-off. Для чутливих даних окремо перевірте retention, training use, sharing, connector permissions і deletion. Якщо доказів недостатньо, правильний handoff — narrow conclusion або список наступних перевірок, а не впевнена рекомендація.

Оберіть два фіналісти після першого eval і проведіть двотижневий pilot на повторюваному workflow, наприклад щотижневому competitive brief. Вимірюйте не кількість сторінок, а verified decision-ready reports, median review time, критичні unsupported claims, пропущені першоджерела, restart rate і повну вартість прийнятного результату. Порогові значення команда визначає до pilot, виходячи з ризику, а не після перегляду результатів.

Зафіксуйте primary mode, fallback, дозволені use cases, заборонені дані, review owner і trigger повторної оцінки. Повторіть eval після суттєвої зміни функцій, model behavior, джерельного доступу, privacy terms або ціни, а також за регулярним vendor-review циклом. Rollback у цьому workflow означає повернення до попереднього перевіреного процесу або ручного research, а не спробу відкотити зовнішній сервіс.

Актуальні продуктови довідки показують важливу різницю в керуванні джерелами. ChatGPT Deep Research дозволяє працювати з публічним web, завантаженими файлами й увімкненими apps, а також обмежувати пошук конкретними сайтами або лише пріоритезувати їх. Gemini Deep Research за замовчуванням включає Google Search, але дозволяє додати файли, Gmail, Drive чи NotebookLM notebooks і вимкнути web search. Perplexity Research описує автономний iterative search, роботу із завантаженими документами та автоматичний вибір моделей; окремі premium sources і connectors можуть змінювати доступний corpus. Це snapshot можливостей на 2026-08-24, а не гарантія для кожного plan або регіону.

Через це чесний тест потребує двох окремих slices. У `public-web slice` кожен кандидат отримує однаковий allowlist доменів, часову межу та список must-find documents. У `mixed-context slice` кожен отримує ідентичний пакет файлів, але жодна перевага від недоступного конкуренту connector не входить у quality score: її оцінюють окремо як workflow-fit. Інакше команда назве кращим research engine сервіс, який просто мав ширший corpus.

Для кожного запуску збережіть source manifest: дозволені типи джерел, selected connectors, назви й checksums тестових файлів, web restriction mode, дату запуску та відомі недоступні джерела. Якщо інтерфейс не показує точну конфігурацію після завершення, оператор додає screenshot або ручний журнал до evidence pack. Висновок без manifest не можна точно повторити після зміни індексу, connector або product defaults.

• Web-only parity → однакові domains, date cutoff і must-find першоджерела.
• Private-context parity → однакові файли та identity/permission boundary.
• Connector advantage → окремий workflow-fit score, а не прихована перевага quality.
• Unavailable source → явна gap, а не мовчазна заміна вторинним переказом.

Живий URL не є незмінним доказом: сторінку можуть оновити, перемістити або персоналізувати, а search index — переоцінити. Після завершення consequential research створіть evidence freeze в межах дозволів і copyright policy: збережіть URL, title, publisher, publication/update date, access time, короткий supporting excerpt або точний location pointer і cryptographic hash дозволеної локальної копії. Не архівуйте матеріал, якщо ліцензія або політика цього не дозволяє; у такому разі збережіть бібліографічний запис і статус доступу.

Claim ledger повинен бути двошаровим. Перший шар — твердження дослідницького режиму з його citation. Другий — verdict reviewer-а після відкриття першоджерела: `supported`, `partial`, `contradicted`, `stale` або `unverifiable`. Окремо позначте inference, де джерело підтримує факти, але не готовий висновок. Це не дозволяє сильній цитаті в одному реченні легалізувати сусідню vendor claim або причинний висновок.

Перед handoff запустіть freshness pass лише для claims, здатних змінити рішення: ціна, plan availability, product capability, law, leadership, security advisory або current market fact. Durable definitions не потребують повторного web scan в кожному запуску. Якщо critical source змінився між research і review, старий report не переписують непомітно: створюють нову revision, фіксують delta і повторно погоджують лише залежні conclusions.

• Capture → URL, publisher, dates, access time і passage pointer.
• Verify → entailment, authority, jurisdiction, version і conflicts.
• Classify → sourced fact, attributed vendor claim, inference або unknown.
• Refresh → лише time-sensitive claims із decision impact.
• Revise → immutable prior report, explicit delta і renewed sign-off.

Звичайний golden set перевіряє, чи сервіс знаходить очікувані факти. Для deep research потрібен ще failure set: robots-blocked першоджерело, paywall, видалена сторінка, два документи з однаковою назвою, старий PDF вище нової редакції, citation на summary замість primary text, prompt injection усередині завантаженого файла та твердження, для якого публічного доказу не існує. Очікуваний результат може бути не відповідь, а чесне `не вдалося перевірити` з поясненням прогалини.

Оцінюйте source substitution: чи повідомив режим, що не дістався первинного документа; чи знайшов офіційне дзеркало; чи понизив confidence; чи видав вторинний матеріал за еквівалент першоджерела. Додайте citation mutation test: reviewer відкриває випадкову вибірку links і перевіряє, що заголовок, passage, дата та scope справді відповідають claim. Source label або авторитет домену допомагає triage, але не засвідчує конкретну сторінку — це прямо підкреслює й актуальна довідка Perplexity про labels.

Promotion gate для командного використання має включати нуль критичних fabricated citations, прийнятну частку verified consequential claims, явні gaps для недоступних джерел, відтворюваний source manifest і обмежений review time. Якщо кандидат провалює gate, rollback простий: повернути workflow до попереднього research mode або manual search, зберегти corpus і rubric та не переносити неперевірені висновки в decision record.

Deep-research products змінюються нерівномірно: новий model, connector, export format або source control може вплинути лише на один slice workflow. Тому кожен повторний bake-off починайте з change manifest: що саме змінилося, у якому plan, region і workspace policy це перевірено, які попередні assumptions стали невідомими та які consequential tasks залежать від зміни. Офіційна довідка підтверджує задокументовану capability, але не те, що вона вже доступна вашому test account або покращує decision outcome.

Зберігайте незмінний anchor set із кількох репрезентативних briefs і додавайте targeted probes для нової capability. Якщо змінився тільки export, повторіть citation preservation, formatting і reviewer handoff; якщо додався connector, перевірте permission propagation, denied document, grant revocation, stale sync та leakage між identities; якщо змінився research model, повторіть source discovery, entailment, conflict і abstention slices. Повний corpus потрібен лише тоді, коли зміна торкається planning, retrieval або synthesis загалом.

Порівнюйте candidate з останнім прийнятим snapshot, а не з пам'яттю команди. Snapshot містить brief version, capability manifest, source manifest, product surface, plan, model label якщо він показаний, raw report, claim ledger і reviewer verdict. Результат `not comparable` чесніший за числовий delta, коли corpus, permissions або evaluation rubric змінилися одночасно. Це не дає rollout створити фальшиве покращення лише через ширший доступ до джерел.

• Change manifest → documented change, observed availability і affected workflow slices.
• Anchor set → стабільні briefs для regression, а не випадкові нові prompts.
• Targeted probes → connector, export, model або source-control boundary окремо.
• Comparable snapshot → однакові corpus, permissions, rubric і reviewer protocol.
• Unknown → повторна перевірка, а не припущення про rollout або quality gain.

До запуску визначте stop conditions для самого дослідження. Зупиніть або звузьте run, якщо план вийшов за jurisdiction чи date boundary, обов'язкове першоджерело недоступне, private connector відкрив неочікуваний scope, з'явилася prompt-injection instruction у source або сервіс почав циклічно замінювати той самий доказ. Interrupt або cancel path треба протестувати на нешкідливій задачі; UI-кнопка не доводить, що вже отримані дані, report draft і audit trail оброблені відповідно до вашої policy.

Окремі acceptance stop rules застосовуйте до готового звіту. Не передавайте його decision owner-у, якщо consequential claim не має passage-level support, чинна редакція документа невідома, conflict замовчаний, citation веде на інше твердження або evidence pack неможливо відтворити. Некритичні gaps можна залишити як named unknowns, але їх не слід усереднювати з правильними відповідями у загальний бал.

Після stop зафіксуйте terminal state: `cancelled-by-scope`, `blocked-source`, `permission-boundary`, `evidence-failed` або `needs-domain-review`. Збережіть лише дозволені артефакти, відкличте тимчасові grants і передайте unresolved questions людині або manual search. Retry має новий run ID та явну причину; він не перезаписує невдалий record і не успадковує автоматично розширений source access.

• Plan drift → pause, correct scope і restart only when needed.
• Unexpected access → stop, revoke, inspect audit evidence і narrow permissions.
• Unverifiable critical claim → reject handoff, навіть якщо report виглядає завершеним.
• Unknown external state → reconcile before retry або downstream action.
• Terminal record → reason, owner, retained evidence і permitted next step.

Перед вибором primary mode проведіть один exit drill. Експортуйте звіт у доступному форматі, перенесіть claim ledger у vendor-neutral table та перевірте, чи збереглися URLs, titles, access dates, passage pointers, assumptions і unresolved claims. Красивий PDF без машиночитного зв'язку між claim і evidence слабкий для повторної перевірки; conversely, Markdown із посиланнями теж недостатній, якщо connector-only source недоступний reviewer-у.

Потім відтворіть дві критичні conclusions через manual search або іншого фіналіста, не передаючи приховану conversation history. Мета не домогтися однакового формулювання, а підтвердити, що decision залежить від доступних evidence і явних inference, а не від непрозорого стану одного продукту. Різницю класифікуйте як corpus gap, freshness delta, reasoning disagreement або unsupported conclusion.

Exit drill завершується recovery record: де зберігаються дозволені reports, хто володіє source manifest, як відкликати connectors, які records видалити за retention policy і який manual fallback підтримує наступний цикл. Така переносність не доводить рівність продуктів; вона зменшує operational lock-in і робить майбутній reevaluation дешевшим та доказовішим.

Поточні довідки підтверджують різні handoff surfaces: ChatGPT дає завантаження завершеного report у Markdown, Word і PDF; Gemini дозволяє копіювати report, поширювати Canvas або експортувати в Google Docs; Perplexity Research — експортувати PDF чи document або перетворювати результат на shared Page. Це корисні delivery formats, але сам факт export не доводить збереження source identity, supporting passage, research plan, activity history, account boundary або revision. Порівняння лише за красою PDF тому винагороджує renderer, а не перевірюваність дослідження.

Після кожного запуску перетворіть vendor output на однаковий research bundle. Мінімальний manifest містить bundle ID, brief hash, provider і mode, account/workspace class, execution time, selected source modes, file hashes, plan snapshot, незмінений exported report, claim ledger, unresolved gaps та reviewer verdict. Не редагуйте vendor export як єдину копію: нормалізований decision brief створюйте окремою revision із посиланням на original artifact.

Перевірте export-loss test. Відкрийте файл поза vendor UI, виберіть consequential claim і доведіть шлях до точного source та passage; потім звірте таблиці, footnotes, dates, links і non-Latin text. Якщо activity history, connector identity або citation anchor існує лише у product UI, зафіксуйте це як provider-bound evidence і додайте дозволений screenshot чи manual receipt. Shared link не є архівом: permissions, account activity або product lifecycle можуть змінити його доступність.

• Original export → незмінний provider artifact із hash і timestamp.
• Manifest → brief, corpus, plan, mode, account boundary і file revisions.
• Claim ledger → atomic claim, source, passage, verdict і reviewer.
• Decision brief → окрема approved revision, а не тихе редагування export.
• Loss test → citations, tables, links і provenance читаються поза vendor UI.

Фінальний report є candidate evidence, а не рішенням. Створіть decision schema з полями `decision`, `eligible options`, `hard constraints`, `supported findings`, `material unknowns`, `conflicts`, `expiry triggers`, `reviewers` і `authority owner`. Автоматичний імпорт дозволяйте лише для тексту й citations у draft; recommendation, risk acceptance, purchase amount, legal position або production action потребують окремого людського sign-off у системі, яка справді володіє цим рішенням.

Додайте contradiction gate перед approval. Reviewer шукає не тільки support для preferred option, а й disconfirming evidence: чинніші документи, іншу юрисдикцію, vendor limitation, відсутній denominator, plan-specific exception або джерело з іншим definition. Якщо два reports посилаються на різні revisions одного документа, спочатку нормалізуйте effective date і scope. Majority vote між трьома research products не вирішує конфлікт: вони можуть повторити ту саму вторинну помилку.

Для практичного handoff використовуйте статуси `draft`, `evidence-reviewed`, `domain-reviewed`, `approved`, `expired` і `rejected`. Перехід зберігає actor, timestamp, input bundle hash, policy version і rationale. Зміна consequential claim після review повертає залежне рішення в `draft`; cosmetic formatting не скидає approval. Так команда може автоматизувати підготовку та triage, не передаючи research mode приховане право купувати, публікувати або змінювати production state.

• Evidence-reviewed → citations перевірені, але business verdict ще не схвалений.
• Domain-reviewed → scope і наслідки підтвердив відповідальний фахівець.
• Approved → named authority прийняла exact revision і constraints.
• Expired → змінився critical source, plan, law, price або decision context.

Research products, web indexes і вихідні документи змінюються незалежно. Для повторної перевірки збережіть dependency map `source revision → claims → conclusion → decision`. Watchlist може відстежувати update date, canonical URL, content hash або named product event, але автоматичний сигнал лише відкриває review task. Він не повинен сам переписувати approved decision, бо зміна сторінки може бути навігаційною, а незмінний URL — приховувати суттєву редакцію.

Класифікуйте delta як `no-impact`, `supporting`, `contradicting`, `scope-changing` або `source-unavailable`. Для no-impact достатньо receipt; supporting evidence додається новою revision без стирання попереднього audit trail; contradicting або scope-changing delta повторно відкриває тільки залежні claims і conclusions. Source-unavailable вимагає дозволеного archived reference або нового authoritative source, але не мовчазної підміни блогом чи AI summary.

Regression fixture має містити попередній brief, frozen source manifest і expected decision constraints. Запустіть primary mode та fallback лише на affected questions, повторіть passage audit і порівняйте normalized bundles. Якщо provider змінив citation mapping, export або source-control behavior, перевірте також handoff contract. Rollback залишає чинним останній approved decision лише до його явного expiry; якщо critical evidence більше не підтримується, безпечний стан — `decision suspended`, а не впевнене відтворення старого report.

• Trigger → source, capability, plan, policy або decision-context change.
• Impact map → які claims і conclusions справді залежать від delta.
• Targeted rerun → affected fixtures у primary mode та fallback.
• Promotion → новий bundle, passage audit і renewed approval.
• Rollback → last valid decision або suspension за відсутності support.