Perplexity vs ChatGPT Search vs Gemini: як обрати AI-пошук

Perplexity, ChatGPT Search і Gemini з Google Search можуть знаходити актуальні вебджерела та синтезувати відповідь із посиланнями. Але однакова форма чату приховує різні продукти: готовий пошуковий інтерфейс, універсальний асистент із пошуком і developer pipeline з керованим grounding. Тому універсального переможця немає — є відповідність конкретній задачі, вимогам до джерел і способу перевірки.

Для швидкого дослідження з явним фокусом на web results варто перевірити Perplexity; для пошуку всередині ширшої розмови й робочого контексту — ChatGPT Search; для застосунку, де команда вже використовує Gemini API і потребує Google Search grounding metadata, — Gemini. Це стартові гіпотези, а не твердження про точність: функції, моделі та доступність змінюються, а кожна система може дати переконливу, але непідтриману джерелом відповідь.

Розділіть AI-пошук на три шари. Retrieval формує запити, знаходить сторінки й вирішує, які фрагменти прочитати. Synthesis поєднує знайдене у відповідь. Evidence interface показує citations, список джерел і, в API-сценарії, metadata для власного UI. Помилка на будь-якому шарі має іншу причину: важливу сторінку не знайдено, знайдений текст неправильно інтерпретовано або правильне твердження прив’язано до нерелевантного URL.

ChatGPT може сам вирішити, коли шукати, або користувач може явно ввімкнути search; відповідь показує inline citations і панель Sources. Gemini API з Google Search повертає grounding metadata, search queries, джерела та сегменти, потрібні для відображення посилань. Perplexity Search API відокремлює raw ranked results від LLM-generated summary: для контролю власного retrieval беруть Search API, а для готового синтезу — Agent API або Sonar. Не переносіть властивості API автоматично на consumer UI і навпаки.

Для одноразового запиту користувачеві важливі швидкість переходу до першоджерела, зрозумілі citations і зручні follow-up questions. Для повторюваного командного research потрібні збережений brief, однакові правила джерел, експорт evidence та аудит змін. Для вбудованого пошуку в продукті головними стають API contract, фільтри, metadata, latency, помилки, вартість успішної задачі й можливість замінити provider без переписування доменної логіки.

Не порівнюйте лише кількість citations. Десять другорядних переповідей можуть бути гіршими за один нормативний документ. Перевірте, чи дозволяє вибраний режим обмежити пошук доменами, мовою, регіоном або датою; чи повертається текстовий фрагмент, який реально підтримує claim; чи можна відрізнити відсутність доказу від помилки пошуку; чи зберігається точний query і час виконання.

• Швидка актуальна відповідь у чаті → тестуйте consumer search на реальних запитах.
• Пошук як частина тривалої роботи з файлами → оцінюйте весь workspace, а не search окремо.
• Власний продукт із керованими джерелами → порівнюйте API, filters і grounding metadata.
• Регульований або high-stakes сценарій → allowlist першоджерел, журнал evidence і human review.
• Кілька різних типів запитів → застосуйте routing лише після сегментованого eval.

Наявність посилання підтверджує лише те, що система показала URL поруч із відповіддю. Reviewer має відкрити сторінку, знайти підтримувальний passage і перевірити чотири речі: source authority, entailment, freshness та scope. Сторінка виробника є доречною для специфікації власного продукту, але не доводить, що продукт об’єктивно кращий. Новина може підтвердити подію, але не чинний правовий статус. Search snippet не замінює повний документ.

Розбивайте складну відповідь на atomic claims. Для кожного запишіть supporting URL, точний passage, дату або версію й verdict: supported, partially supported, contradicted чи unsupported. Якщо одна citation стоїть після абзацу з п’ятьма твердженнями, не припускайте, що вона підтримує всі п’ять. Для чисел перевірте одиниці, denominator, період і те, хто вимірював результат.

Створіть набір із 20–30 запитів щонайменше п’яти типів: свіжий факт, exact lookup, порівняння, multi-source synthesis і запит без надійної відповіді. Додайте пастки: застарілу популярну сторінку, конфлікт версій, SEO-агрегатор поруч із першоджерелом і хибну передумову. Запускайте сервіси в близький час, з однаковою мовою, локацією та інструкцією; збережіть повний output, citations і timestamp.

Оцінюйте retrieval coverage, частку atomic claims із коректною підтримкою, citation entailment, freshness, виявлення конфлікту, доречність abstention, час людської перевірки та task success. Сегментуйте результат за типом запиту: середнє може приховати, що один сервіс добре знаходить свіжі факти, але пропускає нормативні першоджерела. Не публікуйте рейтинг після одного запуску — search index, query expansion і сторінки змінюються.

У власному застосунку source policy має бути окремою від prompt. Вона визначає дозволені домени, recency window, мову, регіон, мінімальну кількість незалежних джерел і правила для primary evidence. Perplexity документує domain, date, language та region filters; Gemini повертає grounding metadata для побудови citations. Незалежно від provider застосунок має логувати normalized query, policy version, retrieved URLs, response ID і рішення reviewer без збереження зайвих персональних даних.

Перед генерацією відхиляйте недозволені джерела, після генерації запускайте claim-to-source check. Якщо evidence недостатньо, відповідь має звузити висновок або утриматися, а не компенсувати прогалину впевненим текстом. Provider fallback дозволений лише якщо друга гілка виконує ту саму source policy. Rollback повертає останню перевірену конфігурацію пошуку, а не просто попередню назву моделі.

Проведіть pilot на двох фіналістах і призначте blind review: оцінювач бачить відповідь та evidence, але не бренд. Окремо перевірте privacy, retention, identity, sharing, admin controls і контрактні умови для потрібного плану — consumer experience не доводить enterprise readiness. Рахуйте повну вартість прийнятного результату: ліцензію або API, час research, час перевірки, повторні запити й виправлення.

Зафіксуйте decision record: дозволені use cases, заборонені дані, основний інструмент, fallback, потрібний human review, owner і критерії переоцінки. Переглядайте рішення після суттєвої зміни продукту, policy або workload. Так команда купує не абстрактний «найкращий AI-пошук», а контрольований процес отримання й перевірки evidence.

Почніть не з трьох вільних чатів, а з versioned query manifest. Для кожного case зафіксуйте canonical question, мову, країну або jurisdiction, cutoff date, дозволені типи джерел, очікуваний клас відповіді та умову abstention. Окремо запишіть product surface: звичайний ChatGPT Search, consumer Gemini із вебджерелами чи конкретний режим Perplexity. Не змішуйте Search, Pro Search і Deep Research в один scored bucket: додаткові пошукові цикли, source controls і час виконання змінюють саму задачу.

До запуску створіть target-source set там, де істина відома: офіційний release note, нормативний акт, сторінка документації потрібної версії або первинна наукова робота. Це не повний список усіх допустимих джерел, а контроль retrieval coverage. Для відкритого synthesis case замість однієї gold answer задайте required facets, незалежність джерел, часовий горизонт і unacceptable inference. Зберігайте prompt, timestamp, plan/account class та видимі search settings; назва моделі без product configuration не дає відтворюваного сліду.

Запускайте кандидатів у вузькому часовому вікні та чергуйте порядок, щоб нова публікація або навчання reviewer не давали систематичної переваги останньому сервісу. Не виправляйте один prompt після слабкої відповіді лише для одного кандидата. Якщо уточнення потрібне, або повторіть його для всіх, або винесіть conversational recovery в окремий case. Так pilot відповідає на конкретне питання про робочий маршрут, а не створює нестабільний загальний рейтинг брендів.

• Case identity → незмінний ID, query revision, locale, cutoff і risk class.
• Surface fingerprint → продукт, режим, план, source settings і час запуску.
• Expected evidence → target sources або required facets, не заготовлений красивий текст.
• Failure contract → unsupported, stale, wrong-jurisdiction і should-abstain оцінюються окремо.
• Fair rerun → однакова зміна prompt або policy застосовується до всіх кандидатів.

Перенесіть кожне матеріальне твердження відповіді в claim-source ledger. Один рядок містить atomic claim, cited URL, релевантний passage, publisher class, published/updated date, applicable version або jurisdiction і verdict reviewer. Citation precision відповідає на питання, чи справді наведене джерело підтримує claim; citation coverage — яка частка матеріальних claims узагалі має підтримку. Retrieval coverage вимірюється окремо, бо система може знайти правильний документ, але не використати його у висновку.

OpenAI прямо попереджає, що search results і citations можуть бути неповними, застарілими або неправильними. Gemini може показувати inline sources чи related links, але Google зауважує, що related link не обов’язково був джерелом генерації. Perplexity у 2026 році додав domain-level Government, Academic і Trusted labels та окремо пояснює, що label оцінює домен, а не точність конкретної сторінки або claim. Отже жодна UI-позначка не скасовує відкриття першоджерела й entailment review.

Застосуйте source hierarchy до конкретного твердження. Документація vendor є первинною для його feature behavior, але не для порівняльної переваги; regulator — для чинної вимоги в межах своєї юрисдикції; paper — для описаного experiment, але не автоматично для production workload. Якщо два авторитетні джерела розходяться, ledger зберігає обидва, scope конфлікту й обережний висновок. Система отримує бал за правильне виявлення невизначеності, а не штраф за відмову вигадати однозначність.

• Entailment → passage підтримує саме цей atomic claim.
• Authority → publisher компетентний щодо цього типу твердження.
• Freshness → дата й версія відповідають cutoff case.
• Scope → країна, план, продукт і population не були розширені без доказу.
• Conflict handling → суперечність показана, а не прихована синтезом.

AI-пошук змінюється навіть без зміни вашого prompt: індекс оновлюється, сторінки редагуються, product mode або source UI змінює поведінку, а план може відкривати інший набір controls. Збережіть мінімальний regression pack із критичними exact lookup, current fact, conflicting-source, wrong-premise і no-answer cases. Повторюйте його після material product change та за визначеним cadence для залежних від свіжості workflows. Порівнюйте не дослівний output, а evidence contract: знайдений authoritative source, підтримані claims, коректний cutoff, abstention і reviewer effort.

Відрізняйте content drift від system drift. Якщо офіційний документ справді змінився, нова відповідь може бути правильною; якщо документ той самий, але citation зникла або claim більше не підтримується, це regression. Зберігайте hash або revision контрольних сторінок, коли це юридично й технічно доречно, та screenshot/metadata evidence без копіювання зайвого захищеного контенту. Недоступна сторінка отримує окремий статус, а не автоматичний verdict про помилку моделі.

Promotion rule має бути route-specific. Інструмент може стати primary для low-risk market scan і лишитися забороненим для legal або medical decision. Якщо hard-stop rate, unsupported material claims чи reviewer time виходять за попередньо визначену межу, affected route повертається до manual search або known-good provider configuration. Публікація цього протоколу не є Search Console, GA4, crawl, rendered-HTML, launch чи indexing evidence AI Magister і не змінює відповідних зовнішніх gates.

• Regression pack → малий, стабільний і ризик-сегментований набір cases.
• Revision evidence → відрізняє зміну джерела від зміни пошукової системи.
• Material trigger → новий mode, source control, plan boundary або incident запускає rerun.
• Route decision → promotion і rollback діють лише для перевіреного use case.
• Audit trail → manifest, outputs, ledger, reviewer verdict і decision record зберігаються разом.

Однаковий текст запиту не означає однаковий retrieval context. ChatGPT Search може враховувати приблизну локацію з IP, точнішу device location за дозволом і релевантні saved memories під час переписування search query. Gemini Apps може персоналізувати відповіді за минулими чатами, підключеними Google apps та інструкціями для eligible personal accounts. Perplexity profile також може містити мову, локацію, інтереси й постійні instructions. Це корисні product capabilities, але в порівняльному тесті вони стають confounders: результат може відрізнятися через накопичений контекст, а не через кращий пошук або synthesis.

Проведіть два окремі прогони. Clean-room lane використовує нову розмову, узгоджену locale, явно вказану geography, однаковий cutoff і мінімально персоналізований test account; зафіксуйте sign-in state, memory, connected apps, location permission, profile instructions та режим пошуку. Real-context lane відтворює справжній workflow із дозволеними пам'яттю, історією або connected sources. Не оголошуйте incognito чи новий chat повною анонімністю: мережеве місце, account state, plan і server-side product configuration все одно можуть відрізнятися, тому записуйте відомі та невідомі фактори.

Порівнюйте lanes окремо. Clean-room показує базову придатність до заданого source policy, а real-context — корисність і ризики персоналізації для конкретної ролі. Якщо персоналізований результат кращий, reviewer має назвати, який дозволений context додав цінність; якщо він звузив джерела, змінив jurisdiction або розкрив небажаний профільний сигнал, це окремий finding. Для командного procurement не переносіть поведінку personal account на managed workspace: availability і data boundary перевіряються на тому плані та identity, які реально купуються.

• Clean-room lane → нова сесія, явні locale/geography/cutoff і мінімум профільного контексту.
• Real-context lane → тільки дозволені memory, history, apps і location для справжньої ролі.
• Context manifest → account class, search mode, sign-in, memory, apps, instructions, location і відомі unknowns.
• Separate verdicts → baseline retrieval quality не усереднюється з personalization utility.
• Workspace boundary → consumer-account результат не є доказом enterprise або school configuration.

Коли clean-room і real-context lane повертають різні джерела або висновки, не обирайте приємнішу відповідь. Спочатку класифікуйте divergence: query rewrite, geography, time cutoff, source availability, account entitlement, personalized preference, connected private source або synthesis difference. Потім повторіть мінімальну пару, змінюючи лише один фактор. Наприклад, додайте однакове місто до обох prompts, вимкніть одну memory або приберіть connected app; не змінюйте одночасно модель, режим і формулювання.

Для матеріального claim відкрийте citations і побудуйте source diff: URL, publisher, publication/update time, jurisdiction, passage і verdict. OpenAI прямо попереджає, що search results та citations можуть бути неповними, застарілими або неправильними; Google також зазначає, що related link не обов'язково був джерелом генерації. Отже збіг відповідей не доводить правильність, а розбіжність не доводить помилку одного vendor. Висновок може бути `context-explained`, `source-drift`, `unsupported`, `unresolved` або `not-comparable`.

Зафіксуйте promotion rule до тесту. Для локальних рекомендацій дозволена персоналізація може бути частиною acceptance criteria; для policy lookup або регуляторної вимоги профільні уподобання не повинні змінювати authoritative source set. Нерозв'язана divergence у high-stakes route зупиняє автоматичний synthesis і передає evidence reviewer. Rollback вимикає конкретний context input або повертає known-good search configuration, не стираючи журнал, потрібний для пояснення рішення.

• Classify → rewrite, locale, cutoff, entitlement, private source, preference або synthesis.
• Isolate → один змінений фактор на paired rerun.
• Diff evidence → URL, passage, date, jurisdiction і claim-level support.
• Decide → context-explained, source-drift, unsupported, unresolved або not-comparable.
• Fail closed → unresolved high-stakes divergence переходить до human review.