Acasă/Metode

Cercetare · Metodă

Trei cercetări adânci, contopite într-o singură foaie de parcurs

La începutul fiecărui proiect, și din nou înaintea fiecărei versiuni mari, trecem aceeași întrebare prin trei motoare AI de deep research și contopim rapoartele într-o singură foaie de parcurs. Valoarea vine din dezacordurile dintre motoare și din verificarea la sursă a fiecărei afirmații importante; rapoartele în sine sunt ciorne, nu constatări.

Actualizat 2026-10-11

La ce folosește

O primă specificație descrie versiunea evidentă a unui produs. Ritualul există ca să cartografiem tot spațiul de funcții înainte să ne legăm de o arhitectură: ce livrează cei mai buni concurenți, ce fac industriile vecine și n-a copiat încă nimeni pe platforma noastră, ce ar conține o versiune mult mai bună și care dintre idei chiar îi țin pe utilizatori.

Îl rulăm la pornire, după ce prima versiune e live și înaintea fiecărei versiuni mari, pentru că o aplicație live schimbă ce merită construit în continuare. Pe una dintre aplicațiile noastre Shopify, cercetarea contopită a adus editorul de text bogat și toată faza a treia a foii de parcurs, nimic din ele nefiind în specificația inițială. Am folosit același ritual și pe propriul proces de construcție și lansare, nu doar pe produse.

Pasul 1: promptul se scrie ca un dosar

Același prompt merge la toate trei motoarele. Cere cinci lucruri: tot ce livrează concurenții de top, cu trimiteri la paginile lor; ce fac uneltele din domenii învecinate și n-a copiat nicio aplicație de pe platformă; ce ar include o versiune mult mai bună; fiecare idee ordonată după valoare față de efortul de construcție; și ce e supraevaluat față de ce îi păstrează efectiv pe utilizatori.

Când întrebarea e de strategie, nu o hartă de funcții, promptul conține datele noastre, și acolo apare prima greșeală. O ciornă de prompt de strategie avea cinci cifre greșite, dintre care patru importante. Una era o valoare dată pe săptămână, măsurată de fapt pe 28 de zile. Alta era prezentată drept retenție și era de fapt rata de finalizare a instalării. Așa că fiecare cifră pe care se sprijină argumentul o recitim din sursa primară în ziua în care trimitem promptul, cu fereastra de timp și unitatea scrise lângă ea.

Apoi atacăm ciorna cu șase critici independenți: un verificator de fapte cu acces la surse, un cititor care caută întrebări tendențioase, un consultant care enumeră ce lipsește, un cititor fără context, un avocat al diavolului pe narațiune și unul care răspunde la prompt și apoi își judecă propriul răspuns. Păstrăm ce au găsit cel puțin doi, plus orice greșeală dovedită de unul singur, și rescriem. Ultimul critic e mereu cel mai util: de la el am aflat că șase întrebări deschise produc șase eseuri, la o adâncime la care nimic nu poate fi greșit.

Pasul 2: trei motoare, în paralel

Deep research-ul din ChatGPT și cel din Gemini le rulează un om, care aduce înapoi rapoartele. În același timp, Claude face propria trecere pe mai multe surse, citind direct paginile concurenților, documentația și recenziile.

Fiecare motor găsește constant lucruri pe care celelalte le ratează. În rulările noastre, ChatGPT a dat cea mai mare acoperire pe funcțiile concurenților, Gemini cele mai bune unghiuri pe ecosistemul Google și pe căutare, iar Claude fezabilitatea implementării și poziționarea onestă. În cercetarea despre procesul nostru de construcție, trei goluri au fost ratate de ambele motoare externe și au venit doar din a treia ramură. Rostul celor trei motoare nu e de trei ori mai mult conținut. E faptul că dezacordul dintre ele scoate la suprafață invențiile pe care un singur raport le-ar prezenta cu toată încrederea.

Pasul 3: contopim, nu stivuim

Dacă pui trei rapoarte unul peste altul, obții un document lung, cu trei variante ale fiecărei idei. A contopi înseamnă: eliminăm dublurile, grupăm ce rămâne pe teme, apoi rulăm o critică adversarială pe tot setul. Ce au ratat toate trei? Ce e doar zgomot? Ce ne-ar strica permisiunile pe platformă sau nivelul de protecție a datelor? Rezultatul e o singură foaie de parcurs în repository-ul aplicației, împărțită în faze care pot fi lansate fiecare separat.

Marcăm fiecare punct după câte surse au ajuns la el. Într-o contopire am combinat cinci treceri și am etichetat punctele după acordul a cinci, patru sau trei dintre ele. Convergența spune ceva despre prioritate, nu dovedește adevărul: cinci rapoarte pot repeta aceeași greșeală dacă au citit aceeași sursă slabă.

Pasul 4: verificăm la sursă înainte să depindă ceva de afirmație

Rapoartele de deep research sunt bune la structură și slabe la detalii. Am măsurat asta. Din șase rapoarte Gemini despre aceeași piață, trei n-au livrat niciun identificator de aplicație, deși promptul îi cerea explicit, deci jumătate din livrabil nu putea fi verificat; iar 2 din 37 de identificatori erau inventați. Într-o rundă mai mare, am dus la surse primare 171 de afirmații din nouă rapoarte și 46% n-au rezistat: 40% infirmate, 6% imposibil de verificat. Cifrele brute copiate din registre oficiale erau în general corecte. Stratul de interpretare construit peste ele era locul unde stăteau cele mai multe erori.

Erorile aveau o direcție. Cifrele erau umflate constant în sus, o confuzie de monedă a transformat o marjă obișnuită într-una extraordinară, iar orice afirmație de tip „spațiu liber”, adică „nu oferă nimeni asta”, a căzut de fiecare dată când am testat-o. Așa că fiecare nume, cifră și mecanism de care depinde un punct din foaia de parcurs se verifică în marketplace, în documentația oficială sau în registrul public înainte ca punctul să fie programat.

Capcanele în care am căzut și cum le prindem acum

Lista de fapte propagă și erorile. Ca să nu inventeze agenții, le dăm un gard de fapte confirmate. Gardul poartă și greșelile noastre, cu aceeași autoritate. La construirea unei bănci de întrebări s-a întâmplat de patru ori; un fapt inversat a produs o întrebare fără niciun răspuns corect, iar explicația repeta inversiunea, deci verificatorul generatorului n-avea cum s-o prindă din interior. Trei verificatori independenți au găsit-o doar pentru că au citit textul oficial integral, nu lista noastră. Acum faptele stau într-un fișier versionat, fiecare cu sursa și data la care a fost citit, iar verificatorii primesc instrucțiunea să conteste lista, nu doar rezultatul.

Un verificator comun anulează unghiul diferit. Într-o căutare am rulat cinci unghiuri independente, fiecare urmat de un verificator adversarial. Verificatorul era un singur prompt, scris pentru întrebarea principală. Al cincilea unghi întreba altceva, deci constatările lui aveau altă formă, iar verificatorul le-a respins pe toate: 3 constatări brute, 0 confirmate. Una dintre cele respinse era reală și mai urgentă decât întrebarea de la care pornisem. Acum fiecare unghi are propriul criteriu de respingere și raportăm constatările brute lângă cele confirmate, pentru că un zero produs de mecanism arată exact ca un zero produs de realitate.

Propunerile numesc mecanisme care nu există. Din zece idei de aplicații propuse de cercetarea AI pentru o platformă de dezvoltatori, patru depindeau de un modul, un câmp, un eveniment sau un endpoint pe care platforma nu-l are sau nu-l permite aplicațiilor. Fiecare dintre ele eșuează în tăcere după publicare. Niciun punct al foii de parcurs care depinde de un mecanism al platformei nu e acceptat până nu putem lipi propoziția din documentație care spune că mecanismul face acțiunea respectivă.

Validarea circulară. Un raport ne-a returnat o cifră din propriul nostru prompt ca pe o constatare independentă și a construit patru secțiuni pe ea. Nu mai punem în prompt cifre pe care vrem să le verifice cercetarea. Dăm întrebarea, nu răspunsul.

Unde am greșit

N-am rulat întotdeauna toate trei ramurile. O dată, ramura Claude a fost limitată de serviciul de căutare și a întors un rezultat gol fals, așa că secțiunile ei au fost scrise din ce știam deja despre cod. Altă dată s-a terminat cota de ChatGPT și toate cele șase rapoarte au venit de la un singur motor. Verificarea la sursă a rămas singura apărare și a fost suficientă doar pentru că marketplace-ul acela putea fi scanat. Pe un canal pe care nu-l putem scana, un set de rapoarte de la un singur motor n-ar trebui să conducă o decizie.

Am cheltuit și prea mult pe proces. Un workflow generic de cercetare, cu vot adversarial, a consumat o dată în jur de un milion de tokeni și a întors zero surse, pentru că toate citirile fuseseră limitate. Acum testăm limita cu o căutare și o citire înainte să pornim ceva scump, iar pentru întrebări tehnice înguste o trecere țintită, cu căutări paralele, e mai ieftină și mai bună.

Limite

Ritualul lărgește spațiul de opțiuni și îl ordonează. Nu stabilește cererea; aceea e un test separat, pe datele marketplace-ului. Nu dovedește că o funcție va păstra pe cineva, iar convergența dintre motoare poate fi o eroare comună. O foaie de parcurs contopită e un plan care se reia când se încheie o fază, nu o prognoză.

Lista de verificare

1. Adună întâi faptele, din surse primare, cu date, ferestre de timp și unități. Abia apoi scrie promptul.

2. Trece ciorna prin șase critici; păstrează ce au găsit doi și fiecare greșeală dovedită.

3. Trimite același prompt la toate trei motoarele. Nu sări peste o ramură pentru că un motor știe să caute.

4. Elimină dublurile, grupează, critică și scrie o singură foaie de parcurs pe faze.

5. Verifică fiecare nume, cifră și mecanism de care depinde un punct, înainte să fie programat.

6. Dă fiecărui unghi de verificare propriul criteriu; raportează împreună constatările brute și cele confirmate.

7. Reia ritualul când se lansează o fază.

Întrebări și răspunsuri

De ce merită folosite mai multe unelte AI de deep research în loc de una?

Mai multe unelte AI de deep research merită folosite pentru că fiecare motor găsește constant lucruri pe care celelalte le ratează, iar dezacordul dintre ele scoate la iveală afirmațiile pe care un singur raport le-ar prezenta sigur pe el. Un motor a dat cea mai mare acoperire pe funcțiile concurenților, altul cele mai bune unghiuri pe căutare, iar al treilea fezabilitatea implementării. Scopul nu e mai mult conținut, ci prinderea invențiilor.

Cât de corecte sunt rapoartele de deep research făcute cu AI?

Rapoartele de deep research făcute cu AI sunt bune la structură și slabe la detalii. Din 171 de afirmații duse la surse primare, 46% n-au rezistat. Cifrele brute copiate din registre oficiale erau în general corecte, iar erorile stăteau mai ales în interpretarea construită peste ele. Erorile aveau și o direcție: cifre umflate în sus și afirmații de tip „nu oferă nimeni asta” care au căzut la fiecare test.

Cum contopești mai multe rapoarte de cercetare într-o singură foaie de parcurs?

Mai multe rapoarte de cercetare se contopesc, nu se stivuiesc. Elimini dublurile, grupezi ce rămâne pe teme, apoi rulezi o critică adversarială pe tot setul: ce au ratat toate rapoartele, ce e doar zgomot și ce ar strica permisiunile pe platformă sau protecția datelor. Rezultatul e o singură foaie de parcurs, împărțită în faze care se pot lansa separat, cu fiecare punct marcat după câte surse au ajuns la el.

Cum se pregătește un prompt pentru deep research cu AI?

Un prompt pentru deep research cu AI se scrie ca un dosar: fiecare cifră pe care se sprijină argumentul se recitește din sursa primară în ziua trimiterii, cu fereastra de timp și unitatea scrise lângă ea. Ciorna e atacată apoi de mai mulți critici independenți și se păstrează ce au găsit cel puțin doi, plus orice greșeală dovedită de unul. Cifrele pe care cercetarea trebuie să le verifice rămân în afara promptului.

De ce poate un singur verificator să respingă greșit constatări valide?

Un singur verificator poate respinge greșit constatări valide când a fost scris pentru întrebarea principală și e aplicat unui unghi care întreabă altceva. Constatările acelui unghi au altă formă, așa că verificatorul le refuză pe toate, deși una dintre ele poate fi reală și urgentă. Fiecare unghi are nevoie de propriul criteriu de respingere, iar constatările brute trebuie raportate lângă cele confirmate.

Toate metodele