TinyFish розбирає архітектуру агентного пошуку для продукційних ШІ-агентів

Пошуковий агент зі штучним інтелектом може працювати в демонстраційному режимі, але виходити з ладу під виробничими навантаженнями, коли пошук повертає неповні докази, повторні спроби відтворюють невдалі дії або виконання перевищує часові й фінансові обмеження. TinyFish, яка надає вебінфраструктуру для ШІ-агентів, опублікувала два технічні посібники, присвячені цим викликам. У першому описано архітектуру агентного пошуку для виробничого середовища, а в другому наведено уроки, отримані під час створення системи глибокого дослідження. Разом вони розглядають, як автономний пошуковий агент може планувати пошук, оцінювати докази, обробляти збої та керувати межею між міркуваннями моделі й детермінованим виконанням.

Коротко

TinyFish представила свою архітектуру агентного пошуку та ключові інженерні уроки, отримані під час створення систем глибокого дослідження. Побудована на чотирьох вебпримітивах (TinySearch, TinyFetch, TinyBrowser і TinyAgent), система працює за допомогою семифазного циклу керування навколо базової моделі. На OpenBenchmarks TinyFish досягла показника виконання 79,0% у завданнях із програмування, забезпечивши водночас найнижчу медіанну вартість завдання ($0.050) і найменший обсяг використаних токенів. Це підкреслює важливість жорстких циклів керування, повторних спроб, специфічних для типу збою, та уніфікованого міркування замість автономних планувальників.

Що таке архітектура агентного пошуку?

Архітектура агентного пошуку дає змогу ШІ-агенту планувати пошук, отримувати доступ до джерел, оцінювати докази та адаптувати свій підхід у міру надходження нової інформації. Модель забезпечує міркування, тоді як навколишній застосунок керує станом, виконанням інструментів, обробкою доказів, політиками середовища виконання та перевіркою результатів. Разом ці компоненти дають агенту змогу працювати з неповними результатами, збоями, які можна виправити, і змінними вимогами до інформації.

Архітектура TinyFish спирається на фундаментальні концепції з архітектурного препринту, опублікованого в лютому 2026 року, який розділяє міркування та виконання за допомогою типізованих інтерфейсів інструментів. У статті визначено основні системні обмеження, зокрема детальне трасування разом із жорсткими лімітами на кількість токенів, час виконання, загальну вартість і виклики інструментів.

Як працює пошук у виробничому середовищі?

TinyFish розділяє виконання на 7 фаз:

Визначення завдання: Перетворити мету на «контракт доказів»: необхідні поля, джерела, актуальність і правила завершення.
Планування пошуку: Відокремити незалежні потреби від залежних. Залежні запити очікують на попередні відповіді.
Вибір першого маршруту: Обрати інструмент на основі того, що системі відомо про докази.
Виявлення, відбір, отримання: Розглядати результати пошуку як кандидатів, доки не буде отримано вміст сторінки.
Оцінювання: Позначати докази як достатні, неповні, суперечливі, недоступні або такі, що перевищили бюджет.
Відновлення або ескалація: Переформулювати запит, повторити спробу, змінити джерела або спосіб доступу.
Зупинка та перевірка: Повернути статус: виконано, неповно, не вдалося, скасовано або потрібна перевірка людиною.

Фаза 2 усуває відому проблему. ChainRAG (ACL 2025) називає її проблемою «втрати під час пошуку», коли ключові сутності зникають під час декомпозиції багатокрокового запитання. Фаза 6 спирається на Search-R1, яка демонструє, як моделі можуть генерувати додаткові пошукові запити під час міркування, якщо попередній пошук виявився недостатнім. У 7 наборах даних для відповідей на запитання її навчений багатокроковий пошук перевершив базові показники RAG на 41% (Qwen2.5-7B) і 20% (Qwen2.5-3B).

Як пошуковий агент має маршрутизувати інструменти?

Маршрутизація має відповідати інформаційній прогалині, а не фіксованій послідовності.

Початкова умова	Примітив	Що все ще контролює застосунок
Місцезнаходження джерела невідоме	Пошук	Планування запитів, політика щодо джерел, зупинка
URL відомий і доступний для читання	Отримання	Перевірки повноти, перевірка тверджень
Застосунок має контролювати дії на сторінці	Браузер	Кожна дія, повторна спроба та контрольна точка
Рішення на основі кількох сторінок	Вебагент	Бізнес-правила, бюджети, перевірка

Ескалація не завжди є рішенням. Слабкі результати потребують кращого запиту. Суперечливі джерела потребують вагоміших доказів. Потужніший інструмент не усуне жодну з цих проблем.

Повторні спроби мають залежати від типу збою та залишатися в межах визначених лімітів. Тимчасові помилки можуть виправдовувати повторення запиту, тоді як неповні або суперечливі докази потребують іншого підходу. Повторні спроби в браузері також мають враховувати вже виконані дії, щоб уникнути небажаних наслідків, наприклад повторного надсилання тієї самої форми.

better',{'font-size':13,'font-weight':700,fill:G,'text-anchor':'start'}); D.sf.forEach(function(d){var tf=d[0]==='TinyFish',g=el('g',{},s4); var ring=el('circle',{r:tf?17:0,fill:'none',stroke:G,'stroke-opacity':.4,'stroke-width':2},g); var c=el('circle',{r:tf?10:8,fill:tf?G:'#6a6a6a',stroke:'#111','stroke-width':2},g); var t=tx(g,0,0,'',{'font-size':13,'font-weight':700,fill:tf?G:TX,'text-anchor':'start'}); pts[d[0]]={g:g,c:c,t:t,ring:ring,x:sx(d[1]),y:sy(d[2])}}); pts['Exa fast']=pts['Exa deep'];boost(s4,1.2)} var anim4=null,OFF={sf:{'TinyFish':[-16,-20,'end'],'Exa deep':[-14,-18,'end'],'Perplexity':[14,-12,'start'],'Firecrawl':[14,16,'start']}, so:{'TinyFish':[16,0,'start'],'Exa fast':[-14,0,'end'],'Perplexity':[14,0,'start'],'Firecrawl':[14,0,'start']}}; function drawScatter(fromZero){var data=D[cur],start={},t0=null; data.forEach(function(d){var p=pts[d[0]];start[d[0]]=fromZero?{x:sx(0),y:Y0}:{x:p.x,y:p.y};p.tx=sx(d[1]);p.ty=sy(d[2]); p.t.textContent=d[0]+' '+d[2].toFixed(1)+'% · $'+d[1].toFixed(3)}); anim4=function(ts){if(!t0)t0=ts;var f=Math.min(1,(ts-t0)/900),e=1-Math.pow(1-f,3); data.forEach(function(d){var p=pts[d[0]],s=start[d[0]];p.x=s.x+(p.tx-s.x)*e;p.y=s.y+(p.ty-s.y)*e;p.g.setAttribute('transform','translate('+p.x+','+p.y+')'); var o=OFF[cur][d[0]];p.t.setAttribute('x',o[0]);p.t.setAttribute('y',o[1]);p.t.setAttribute('text-anchor',o[2])}); if(f>=1)anim4=null}} build4();chips('c4','b',function(b){cur=b;drawScatter(false)});drawScatter(true); function loop(ts){if(active==='p1'&&run1)run1.tick(ts);if(active==='p3')tick3(ts);if(anim4)anim4(ts); if(pts.TinyFish)pts.TinyFish.ring.setAttribute('r',15+3*Math.sin(ts/220));requestAnimationFrame(loop)} requestAnimationFrame(loop); window.addEventListener('load',post);window.addEventListener('resize',post);setTimeout(post,300); })(); </script> </body></html> ">

Чого TinyFish навчилася під час створення глибокого дослідження?

Агент глибокого дослідження виконує пошук, переглядає вебсторінки та створює комплексні звіти з посиланнями на джерела. Більшість інженерних викликів стосувалася керування контекстом, оркестрації системи та дизайну продукту.

Урок №1: Відмова від окремого планувальника

Початкові ітерації використовували автономний планувальник, який щоразу викликався заново. До нього передавався лише структурований стан. У додаткових запитах на кшталт «зосередьтеся лише на цінових ризиках у Південно-Східній Азії» агент повертався до широкого дослідження ринку. Згодом TinyFish перенесла планування у власний уніфікований цикл міркування оркестратора.

Урок №2: Відмова від субагентів:

TinyFish спочатку призначала окремого субагента для кожного пошукового запиту, що збільшувало накладні витрати на перемикання контексту, затримку та вартість. Згодом команда замінила цих субагентів викликами інструментів для повторюваних завдань, таких як ранжування результатів пошуку, класифікація джерел та вилучення доказів. Це зменшило обсяг інформації, що передавалася оркестратору, і дало йому змогу зосередитися на плануванні дослідження та визначенні того, що досліджувати далі.

Урок №3: Відповідність дослідників:

TinyFish спочатку оптимізувала свою дослідницьку систему для охоплення джерел, але користувачі надавали більшого значення якості та релевантності підтверджувальних доказів. Команда скоригувала ранжування джерел, щоб ураховувати мету дослідження, і додала засоби керування для пріоритизації, виключення або обмеження доменів. Також було розроблено внутрішній стенд оцінювання з використанням судді-LLM для перевірки звітів на релевантність, силу доказів, надійність цитування та різноманітність джерел.

Як складаються витрати та затримка?

TinyFish планує бюджет усього завдання, а не окремих викликів:

Затримка завдання = планування + пошук + отримання + оцінювання + повторні спроби + інтерактивні кроки + постановка в чергу.
Вартість завдання = токени + виклики інструментів + використання сторінок або браузера + повторні спроби + інфраструктура.

SearchAgent-X (ICLR 2026) показує чому. Точне отримання даних збільшувало накладні витрати, а грубе отримання змушувало виконувати додаткове міркування. Запропоновані виправлення забезпечили до 3,4 раза вищу пропускну здатність і в 5 разів меншу затримку порівняно з перевіреними базовими показниками.

Як TinyFish порівнюється з іншими рішеннями для пошуку й отримання?

OpenBenchmarks фіксує модель (gpt-5.6-sol), 100 завдань і бюджети та змінює лише постачальника. Показники є середніми значеннями 3 запусків.

Метрика	TinyFish	Exa deep	Perplexity	Firecrawl
Завершення пошуку + отримання	79,0% ± 2,0	83,0% ± 1,0	77,7% ± 1,5	76,0% ± 1,0
Медіанний час завдання	24 с	37 с	22 с	34 с
Медіанна вартість завдання	$0.050	$0.127	$0.083	$0.082
Медіанна кількість токенів завдання	12 844	23 660	20 062	17 379
Завершення лише пошуку	59,3%	66,3% (Exa fast)	77,3%	70,3%
Прайс-лист лише пошуку	$0	$0.012	$0.005	$0.005

Джерело: таблиця OpenBenchmarks, оновлено 26 вересня 2026 року. Завдання охоплюють лише корпоративну документацію.

OpenBenchmarks також окремо наводить результати лише для пошуку. У цій конфігурації TinyFish досягла показника виконання завдань 59,3% порівняно з 77,3% у Perplexity, 70,3% у Firecrawl і 66,3% у Exa Fast. Ці результати не слід безпосередньо порівнювати з показниками пошуку й отримання, оскільки доступні можливості отримання даних відрізняються.

Ключові висновки

Контролюйте всю траєкторію, а не один пошуковий запит.
Маршрутизуйте за інформаційною прогалиною; ескалюйте лише тоді, коли доступ не працює.
Тримайте планування та виконання в одному циклі міркування.
Переносьте детерміновані кроки у виклики інструментів, а не до субагентів.
Ранжуйте джерела за метою дослідження, а не за єдиною оцінкою якості.

Ознайомтеся з посібником з архітектури, уроками глибокого дослідження та документацією TinyFish.

_{Дякуємо команді Tinyfish за експертні матеріали та ресурси для цієї статті. Цю статтю спонсувала TinyFish.}

Перекладено автоматично з англійської. Оригінал статті — за посиланням нижче.