AI Search чи Deep Research: який режим обрати для робочої задачі

AI Search доречний, коли потрібна швидка актуальна відповідь, конкретний документ або перший огляд теми, а користувач може одразу відкрити кілька джерел. Deep Research доречний для складного питання, яке треба розкласти на підпитання, дослідити кількома ітераціями й оформити у перевірюваний звіт. Одна й та сама тема може вимагати різних режимів: знайти чинну сторінку тарифу — search; порівняти повну вартість трьох платформ для закупівлі — deep research.

Не запускайте довгий режим лише тому, що він обіцяє більше джерел або довший текст. Він збільшує вартість неправильної постановки: хибний scope поширюється на десятки пошуків і впевнений synthesis. Перед вибором оцініть п'ять речей: кількість незалежних підпитань, неоднозначність, потрібний тип evidence, наслідки помилки та формат handoff. Якщо відповідь можна перевірити в одному авторитетному документі, простіший маршрут зазвичай кращий.

Типовий AI Search виконує короткий цикл `запит → пошук → synthesis → посилання`. Він оптимізований для швидкого уточнення фактів, навігації до джерела та діалогу. Deep Research додає план, декомпозицію, повторні пошукові ітерації, читання ширшого корпусу, уточнення прогалин і підготовку довшого артефакту. OpenAI прямо відокремлює швидкий search від deep research для multi-step аналізу; Gemini показує research plan перед запуском; Perplexity описує Research як ітеративний режим із розширеним звітом.

Це відмінність workflow, а не гарантія істини. Обидва режими можуть пропустити першоджерело, неправильно пов'язати citation із твердженням або використати застарілу сторінку. Deep research інколи краще знаходить неочевидні зв'язки, але створює більше claims для перевірки. Search швидше дає матеріал для ручного рішення, але користувач сам керує декомпозицією. Якість залежить від brief, доступних джерел, source policy та review, а не від назви кнопки.

Оберіть search, якщо питання вузьке, відповідь time-sensitive, є очікуване першоджерело й результат потрібен зараз: знайти release note, перевірити визначення, побачити останню офіційну заяву або зібрати початкові ключові слова. Перейдіть до deep research, якщо задача містить кілька залежних питань, джерела суперечать одне одному, треба зіставити варіанти за єдиними критеріями або передати evidence pack іншому reviewer. Для high-stakes рішення довгий звіт не скасовує domain review.

Корисний поріг — очікуваний час людської перевірки. Якщо перевірити коротку search-відповідь і два першоджерела швидше, ніж сформулювати та прорецензувати research brief, не ускладнюйте маршрут. Якщо без плану дослідник відкриватиме десятки сторінок і вручну зводитиме суперечності, deep research може зменшити механічну роботу. Порівнюйте `час до перевіреного рішення`, а не час до першого тексту.

• Один факт або документ → AI Search із переходом до першоджерела.
• Кілька незалежних фактів без складного synthesis → серія search-запитів.
• Багатокритеріальне порівняння → Deep Research із затвердженим планом.
• Суперечливі або неповні докази → Deep Research плюс claim ledger і expert review.
• Термінове consequential рішення → короткий evidence scan, explicit uncertainty та людська authority.

Для search достатньо зафіксувати питання, дату актуальності та бажаний тип джерела. Для deep research потрібен контракт: яке рішення підтримує звіт, хто його читатиме, часовий і географічний scope, критерії порівняння, обов'язкові першоджерела, дозволені внутрішні файли, заборонені джерела, формат результату й умови abstention. План треба переглянути до старту: агент може логічно виконати погану декомпозицію.

Не додавайте внутрішні документи за принципом «може знадобитися». Мінімізуйте data scope і перевірте identity, connector permissions, retention та sharing. Retrieved content слід трактувати як дані, а не інструкції: вебсторінка або вкладений файл може містити prompt injection. Research mode готує evidence pack, але не отримує authority на закупівлю, публікацію, зміну політики чи зовнішнє повідомлення.

Для короткої відповіді відкрийте кожну consequential citation і перевірте, чи passage підтримує саме твердження, чи джерело авторитетне для цього claim і чи дата відповідає питанню. Для deep-research звіту створіть claim ledger: atomic claim, URL, supporting passage, publisher, дата, verdict і reviewer. Посилання після абзацу не доводить усі речення, а офіційна сторінка vendor не є незалежним доказом переваги над конкурентом.

Окремо оцініть coverage: які питання з brief закриті, які пропущені, де джерела конфліктують і що лишається невідомим. Довгий звіт легко маскує omission. Хороший результат показує evidence gaps і звужує висновок, коли даних бракує. Для чисел перевіряйте одиниці, denominator, період та автора вимірювання; не перетворюйте vendor-reported case metric на загальний benchmark.

Для повторюваної роботи введіть два маршрути. Fast path виконує search, повертає стислу відповідь із джерелами й зупиняється, якщо знайдено авторитетний документ та немає матеріального конфлікту. Research path запускається, коли classifier або людина бачить кілька залежних підпитань, суперечність, низьке coverage, потребу в cross-source synthesis чи formal handoff. Автоматичний escalation має бути видимим і не розширювати доступ до даних без нового дозволу.

Логуйте тип задачі, обраний маршрут, policy version, джерела, latency, review time, correction і final disposition. KPI — частка перевірених task outcomes, час до decision-ready artifact і critical unsupported-claim rate. Не оптимізуйтеся на кількість deep-research запусків або довжину звіту. Для rollback поверніть останню перевірену routing policy; незавершене дослідження не повинно автоматично запускати зовнішню дію.

Зберіть 20 реальних задач: exact lookup, актуальний факт, коротке порівняння, широкий landscape, суперечливі джерела та питання без надійної відповіді. Для кожної наперед позначте очікуваний маршрут і acceptance criteria. Запустіть search і deep research там, де це безпечно, приховайте назву режиму від reviewer та виміряйте source authority, claim support, coverage, abstention, elapsed time і час редагування до прийнятного результату.

Рішення може бути не бінарним: search за замовчуванням, deep research для визначених task classes і ручний процес для регульованих висновків. Зафіксуйте owner, дозволені джерела, review depth, budget і тригери переоцінки. Функції, квоти й моделі сервісів змінюються, тому перевіряйте workflow після значного product update або зміни source access, не підтримуючи вічну таблицю мінливих feature claims.