Gayunman, bagama’t marami ang nakagamit ng malalimang pananaliksik para sa indibidwal na pangangailangan—paghahanap at pagbubuod ng impormasyon online—kakaunti ang nakinabang dito sa konteksto ng enterprise. Hindi ito dahil hindi ito magiging kapaki-pakinabang—kabaligtaran pa nga—kundi dahil sa mas malawak na alalahanin tungkol sa pagiging maaasahan, magkakahiwalay na source ng data, at/o kakayahan ng modelo na pangasiwaan ang napakaraming context, gaya ng napakaraming iba’t ibang uri ng file.
Ipinakita ng aming karanasan sa pagbuo ng enterprise-grade na mga tool para sa malalimang pananaliksik nitong nakaraang 12 buwan na lalong nalulutas ang mga alalahaning iyon sa pamamagitan ng maingat na engineering. Sa blog na ito, tinatalakay namin ang mga pangunahing hadlang sa epektibong enterprise application ng malalimang pananaliksik, kung paano namin malalampasan ang mga ito, at kung paano namin nakikitang uunlad ang larangan sa 2026.
Kapansin-pansing tumaas ang hangganan ng kakayahang magsagawa. Ang pagdating ng gpt-5 noong Agosto 2025 ay naging mahalagang yugto para sa enterprise AI. Sa aming mga production system, kabilang ang isang platform para sa pagtukoy ng target ng gamot para sa isa sa pinakamalalaking pharmaceutical company sa mundo, nakita naming bumaba mula 3–4% tungo sa halos zero ang mga imbentong source. Pagdating ng Disyembre, lalo pang pinalawak ng gpt-5.2 ang epektibong haba ng context. Ang praktikal na resulta: kaya na nating palawakin mula daan-daan tungo sa libo-libong source sa bawat research run nang hindi isinasakripisyo ang pagiging maaasahan. Mula sa kakayahan ng modelo, bumalik ang bottleneck sa nararapat nitong kinalalagyan—sa inyong data, mga eval, at disenyo ng programa.
Diskarte sa data: mas mahalagang naaabot kaysa pinag-iisa. Nauunawaan ang kagawiang ituring ang enterprise AI bilang problema sa pagsasama ng data, ngunit madalas itong hindi nakatutulong. Mabagal at politikal ang ganap na pag-iisa, at pinipilit kayong magpasya nang maaga bago malaman kung aling mga tanong ang talagang mahalaga. Ang praktikal na hakbang sa 2026 ay sparse connectivity. Gawing naaabot ang data sa pamamagitan ng mga high-signal anchor—mga spec, patakaran, SKU, at clause ng kontrata—sa halip na maghintay nang ilang taon upang mapag-isa ang lahat. Kaya na ngayong mag-‘soft-join’ ng mga frontier na modelo sa iba’t ibang system habang nag-i-inference, na pinagdurugtong ang magkakaugnay na termino nang walang pormal na mapping. Napananatili ninyo ang bilis ng deployment at ang kakayahang umangkop upang magdagdag ng mga source sa hinaharap.
Pinipigilan ng mahusay na navigation ang pagkaligaw. Hindi tulad ng web ang enterprise data. Kal sparse ito, puno ng mga lokal na kumbensiyon, at madalas ay iisa lamang ang tamang source para sa isang partikular na impormasyon. Kung walang gabay, maaaring paulit-ulit na magsagawa ng walang katapusang query ang mga modelo para makahanap pa ng isa pang source, habang inuubos ang oras at pasensiya ng user. Ang magaan na semantic layer—mga hash map, entity lookup, at payak na relationship graph—ay nagbibigay sa system ng mabilis at murang mga hakbang upang mahusay na maabot ang tamang context. Isipin ito bilang payo ng isang beteranong kasamahan sa bagong empleyado: “I-bookmark ang mga site na ito; kausapin si Ross kung may problema ka sa AWS.” Hindi ito kailangang maging komplikado. Kailangan lang nitong tulungan ang system na mabilis na mahanap ang kailangan nito.
Mekanikal (patakbuhin sa bawat query): Kalagayan ng citation, wastong paggamit ng tool, latency, at gastos. Ito ang inyong mga guardrail—karaniwan ngunit napakahalaga.
Analitikal (patakbuhin pana-panahon): Pinipili ba ng system ang tamang mga tool, sumusunod sa makatuwirang direksiyon ng pananaliksik, pumipili ng mapagkakatiwalaang source, at nakaaalam kung kailan titigil? Karaniwang binibigyan ng score gamit ang LLM-as-judge laban sa mga halimbawang may label.
User (tuloy-tuloy): Mga rate ng pagkumpleto ng gawain, kwalitatibong feedback mula sa mga power user, at analytics ng paggamit. Ang pinakahuling pagsubok. Nakagawa ba tayo ng bagay na kapaki-pakinabang sa mga tao?
Nagmumula ang ROI sa mahihirap na problema, hindi sa mga ligtas. Kasunod ng mga ulat na nagsasabing hindi nakakamit ng karamihan sa mga enterprise AI project ang ROI, nawala na ang pagtanggap sa mga kahanga-hangang demo na hindi naman nade-deploy. Gusto ng mga executive ng patunay, at gusto nila ito agad. Sa kabalintunaan, maaaring itulak ng pressure na iyon ang mga team sa maling pagpili. Nakatutuksong magsimula sa mga gawaing mababa ang panganib dahil madaling i-deploy ang mga ito at malabong makagulo. Ngunit bihirang sapat ang epekto ng mga use case na ito upang bigyang-katwiran ang patuloy na pamumuhunan. Mainam ang posisyon ng mga enterprise system para sa malalimang pananaliksik upang patunayan ang halaga dahil nakatuon ang mga ito sa trabahong mahal na: masalimuot at kritikal na workflow kung saan malinaw ang halaga ng kasalukuyang paraan. Ang pinakamahuhusay na use case na nakita namin ay nasa pagbuo ng RFP at bid, pagsusuri sa larangang siyentipiko, at investment research—mga domain kung saan sinusukat ang epekto sa win rate, mas mabilis na pag-usad tungo sa trial, at bilis ng pagkakaroon ng matibay na pasya, hindi lamang sa natipid na oras.
Ang pagbabago sa UX: mula pakikipag-chat tungo sa pag-aatas, at mula mga sagot tungo sa mga artefact. Sa tingin namin, isa ito sa mga pagbabago sa karanasan ng user na magbibigay-hugis sa 2026. Kapag tinitingnan namin ang mga build na pinakamalawak ang pagtanggap kamakailan, may ilang bagay na kapansin-pansin. Habang nagiging mas maaasahan ang mga system na ito, mas hindi na sila itinuturing ng mga user bilang chatbot na tinatanong at mas bilang analyst na maaaring atasan. Dalawang bagay ang nagbibigay-daan dito: pagbibigay sa mga team ng kakayahang i-customize ang mga template at pamantayan sa paghinto ayon sa kanilang workflow, at pagpapahintulot na direktang mag-export sa format na talagang kailangan nila—memo, deck, brief, at iba pa—sa halip na pagbuuhin sila ng tapos na deliverable mula sa isang chat thread. Kapag parehong naipatupad ang mga ito, hindi na lamang reference tool ang system; nagiging paraan na ito ng paggawa.
Noong nakaraang taon, nagsulat kami tungkol sa pagdadala ng malalimang pananaliksik sa enterprise. Dito, kinuha namin ang paradigm ng malalimang pananaliksik na nakasentro sa web at unang pinasikat ng OpenAI, at pinalawak ito sa mga proprietary na source ng data ng mga kumpanya nang hindi nawawala ang provenance o kontrol. Binigyang-diin din namin na hindi dapat ituring ang mga system para sa malalimang pananaliksik bilang pagtalikod sa mas klasikong RAG system, kundi bilang ebolusyon ng mga ito.
Sa pagpasok ng 2026, hindi gaanong nagbago ang konsepto ng malalimang pananaliksik; ang higit na nagbago ay ang hangganan ng posible nitong maisagawa.
Nang simulan naming buuin ang mga system na ito noong unang bahagi ng 2025, kabilang sa mga frontier na modelo ang o1, gpt-4o, at claude-3.5-sonnet—napakalayo na nga ng narating natin sa loob lamang ng 12 buwan—at dumating ang malalaking pagsulong mula sa mga modelong gaya ng o3 at gemini-2.5-pro sa unang ilang buwan ng taon. Mahuhusay ang mga ito para sa panahong iyon, at tiyak na makabubuo gamit ang mga ito ng matatag na application para sa malalimang pananaliksik—hanggang sa isang hangganan. Karaniwang nasa ilang daang source ang hangganang iyon. Paglampas dito, kailangan nang agresibong bawasan ang context; kung hindi, maaaring malugi sa impormasyong sagot, masira ang pagsunod sa tagubilin, o magkaroon ng tahasang hallucination.
Kung nakagawa na kayo ng mga system na ito, pamilyar sa inyo ang ilan sa mga ganitong uri ng pagkabigo.
Bilang kongkretong halimbawa: Noong kalagitnaan ng 2025, nagsimula kaming bumuo ng enterprise solution para sa malalimang pananaliksik kasama ang isa sa pinakamalalaking pharmaceutical company sa mundo. Isa itong system na nagpapabilis sa pagtukoy ng target ng gamot—proseso kung saan naghahanap ang mga researcher ng mga gene, hormone, o iba pang bahagi ng katawan ng tao na maaaring i-target upang gamutin ang isang kondisyon. Noon, o3 ang pinakamalakas na modelong available. Bagama’t mahusay ang performance nito, 3–4% ng mga tugon ng modelong ito ang naglalaman ng mga source na hindi ibinigay sa modelo sa pamamagitan ng mga tool call mula sa proprietary na source ng data ng client. Binawasan namin ito sa pamamagitan ng mga pagsusuri sa citation pagkatapos buuin ang sagot, na nagfa-flag sa mga bahaging hindi sinusuportahan ng ibinigay na context. Nakatulong ito upang magkaroon ng tiwala ang mga stakeholder sa tool habang nasa maagang yugto pa ng PoC ang proyekto, at upang mabilis kaming makausad. Ngunit ipinagpatuloy namin ang pagpapababa sa mga error na ito, habang binabawasan ang mga limitasyon ng mga modelo at tinutugunan ang kahilingan ng mga stakeholder na magdagdag pa ng mga source sa system.
Dumating ang mahalagang yugto sa pagbuo ng mga frontier na solution para sa malalimang pananaliksik—at mas pangkalahatang agentic na solution—nang ilabas ang gpt-5 noong Agosto. Nang palitan namin ang o3 ng gpt-5, ipinakita agad ng aming mga evaluation na bumaba sa 0% ang rate ng source hallucination.
Upang maging tumpak tungkol sa sukatang ito: mahigpit nitong sinusubaybayan kung nagbanggit ang modelo ng document ID o URL na wala sa nakuhang context. Sa panahon ng o3 at bago nito, kung minsan ay nag-iimbento ang mga modelo ng kapani-paniwalang filename o paper upang punan ang kakulangan sa kanilang kaalaman. Dahil sa gpt-5, halos lubos naming naalis ang partikular na problemang ito.
Tandaan na naiiba ito sa mga error sa faithfulness—tamang dokumento ang binanggit ngunit mali ang interpretasyon sa teksto—na nananatiling hamon at pinangangasiwaan namin sa pamamagitan ng mga pagsusuring nabanggit sa itaas.
Napakalaking oportunidad ang binuksan nito. Dahil dito, sinimulan naming subukan kung hanggang saan namin maitutulak ang system gamit ang bagong henerasyon ng mga modelo. Natuklasan naming halos 10 beses naming mapalalaki ang bilang ng source na maaaring isaalang-alang sa isang run ng malalimang pananaliksik—hanggang humigit-kumulang 3,000–5,000. Ang huling limitasyong nakaharap namin ay hindi pagkasira ng pagsunod sa tagubilin kundi performance sa mahabang context. Madalas na mas maikli ang epektibong haba ng context ng mga modelo kaysa sa iniulat, lalo na sa siksik na pharmaceutical data.
Bahagyang nabawasan ang limitasyong ito nang ilabas ang gpt-5.2 noong kalagitnaan ng Disyembre. Ipinakita ng aming internal benchmark sa mahabang context ang malaking pagbuti sa epektibong long-context performance, kaya lalo pa naming naitulak ang aming mga frontier system para sa malalimang pananaliksik. Mahalaga ito dahil nagawa naming dagdagan ang bilang ng mga token na direktang maipapasa sa modelong gumagawa ng output para sa user, kaya mas mayaman ang sagot. Gayunman, nais pa rin naming patuloy na humaba ang epektibong context ng mga frontier na modelo sa 2026.
Dahil sa mga pagsulong na ito sa pangunahing kakayahan ng modelo, sa maraming paraan ay bumalik ang mga bottleneck sa pagbuo ng mahusay na system para sa malalimang pananaliksik sa dapat sana nitong kinalalagyan noon pa man: sa inyong data, mga eval, at paraan ng pagbuo ng programa para sa malalimang pananaliksik sa inyong negosyo. Sa bawat hakbang, kailangan ninyong gumawa ng mga praktikal na pasya tungkol sa kung ano ang makapagdudulot ng makabuluhang pag-unlad sa isang build para sa malalimang pananaliksik.
Inilalahad sa natitirang bahagi ng artikulong ito kung paano namin pinag-iisipan ang mga pasyang iyon.
Nakatutuksong ituring ang mga enterprise research project bilang problema sa pagsasama ng data. Pag-isahin ang mga source, i-normalize ang schema, at hayaang gamitin ng mga modelo ang mga ito.
At para maging malinaw: kung minsan, iyon mismo ang tamang hakbang. Kung nasa domain kayo kung saan matatag ang mga pangunahing entity, nauulit ang mga query, at layunin ninyong gawing pangmalakihan at sistematiko ang workflow, maaaring maghatid ng malaking pakinabang ang pag-iisa. Kabilang sa mga klasikong halimbawa ang pagsasama ng data ng customer at kita, data ng presyo sa merkado, o anumang nangangailangan ng maaasahang reporting sa iba’t ibang system.
Gayunman, sa praktika, iba ang hinahanap ng mga makabagong lider ngayon sa mga enterprise system para sa malalimang pananaliksik.
Habang higit na binibigyang-pansin ang ROI mula sa paggastos sa AI, pangunahing layunin ng mga nagpapasya na mabilis na patunayan ang halaga sa magulong realidad ng aktuwal na pagpapatakbo ng negosyo. At ang ganap na pag-iisa ng mga source ng data ay isa sa pinakamabagal na paraan upang makuha ang unang patunay na iyon. Mabigat ito. Nagiging politikal ito. At madalas, pinipilit kayo nitong pumili ng direksiyon bago ninyo malaman kung aling mga tanong ang talagang mahalaga.
Kaya naniniwala kaming karaniwang ito ang praktikal na simula sa pagbuo ng mga frontier system para sa malalimang pananaliksik sa 2026: gawing naaabot muna ang inyong data bago ito pagandahin.
Kung makatotohanang makapagdagdag kayo ng mga source sa paglipas ng panahon—gaya ng karamihan sa mga enterprise—hindi sapat na napahahalagahan ang mas sparse na connectivity. Maaari ninyong ilantad ang dose-dosenang source sa likod ng iisang pare-parehong retrieval contract. Gagana pa rin ang system at, higit na mahalaga, mapananatili ninyo ang kakayahang mabilis na maghatid. Kapag magdaragdag na kayo ng mga source, hindi ninyo kailangang baguhin ang lahat. Magkakabit lamang kayo ng bagong connector, ipaliliwanag sa pangunahing system kung ano ito at paano gamitin, at hahayaan ang mga modelong magpatuloy mula roon. Gumagana ito dahil kayang mag-soft-join ng mga frontier na modelo ngayon ng dalawa o higit pang source ng data habang nag-i-inference, na pinagdurugtong ang “Customer ID” sa isang system at “Client Reference” sa iba nang walang gumagawa ng pormal na mapping. Hindi lamang kami ang team na ganito mag-isip. Hindi lamang kami ang team na ganito mag-isip: idinisenyo ang internal na data agent ng OpenAI upang makapangatuwiran ang mga modelo sa 70,000 magkakaibang dataset sa pamamagitan ng paggawa sa context at mga koneksiyon na naaabot sa oras ng query, sa halip na pilitin ang ganap na pag-iisa sa simula.
Isang mahalagang paglilinaw: hindi kailangang mangahulugang mababaw ang sparse.
Pinakamahusay ang sparse integration kapag makabuluhan ang mga koneksiyong ginagawa ninyo at ipinapahayag ang mga ito sa paraang madaling magamit ng system. Mainam na ituring ang ilang impormasyon bilang mga anchor—mga specification, patakaran, depinisyon ng produkto, SKU, clause ng kontrata, at iba pa. Hindi kailangang pag-isahin ang bawat dataset upang maging makapangyarihan ang mga anchor na ito; kailangan lamang ng matatag na identifier na may ilang high-signal edge.
Halimbawa, isipin na naghahanap ng isang specification ang modelo o user. Sa isang payak na system, doon nagtatapos ang interaksiyon. Kinukuha ninyo ang spec, binubuod ito, at marahil ay nilalagyan ng citation. Ngunit sa pagbuo ng kapaki-pakinabang na data structure, gusto nating gawing simula ng kontroladong pagpapalawak ang lookup na iyon. Halimbawa, maaari nating i-link ang record ng specification na iyon sa mga artefact na may kaugnayan dito batay sa kasaysayan. Maaaring mangahulugan ng iba’t ibang bagay ang “may kaugnayan,” ngunit karaniwan itong nakabatay sa gawaing isinasagawa ng system. Maaaring kabilang dito ang mga RFP na tumukoy sa spec, dating tugong nanalo ng bid para rito, mga redline kung saan tinutulan ito ng legal team, at iba pa. Malaki ang maitutulong ng paraang ito sa kalidad ng sagot at latency dahil mabilis nitong inilalantad sa system para sa malalimang pananaliksik ang pinakamahahalagang insight sa oras ng query.
Humahantong ito sa susunod na tanong: kapag mayroon na kayong mundo ng mga source ng data na sparse ang pagkakaugnay at may iilang high-signal edge, paano ninyo mapipigilan ang system para sa malalimang pananaliksik na gumala na parang bata sa tindahan ng kendi at sa halip ay mag-navigate na parang beteranong analyst?
Hindi gumagana tulad ng web ang mga source ng enterprise data. Sparse ang mga ito, puno ng mga lokal na kumbensiyon, at madalas ay iisa lamang ang “tamang” source para sa isang impormasyon—kung mahahanap ninyo ito. Bukod dito, likas sa mga modelo ngayon na laging subukang i-maximize ang recall sa mga tanong sa paghahanap, kaya paulit-ulit silang nagpapatakbo ng mga query upang makahanap ng isa pang source habang inuubos ang oras at pasensiya ng user. Maaari itong mabawasan sa maingat na prompting.
Ang pinakamabisang solusyon dito ay isang magaan na tool na tumutulong sa modelong maunawaan ang magulong landscape ng enterprise data. Tinatawag ito ng ilang team na ontology. Tinatawag naman ito ng iba na semantic layer, lookup service, graph, o concept store. Hindi mahalaga ang tawag.
Ang mahalaga ay mabigyan nito ang system ng mabilis at murang mga hakbang upang mahusay na makalipat ang modelo sa tamang mga bahagi ng context sa halip na tila walang katapusang mangapa.
Isang simpleng metapora rito ang pagsali ninyo sa bagong kumpanya o proyekto at pagsabi ng mga bagong kasamahan: “You must bookmark these sites, you’ll use them all the time,” or “any time you have an issue with AWS just speak to Ross, he’ll get you the info you need,” at iba pa. Gayundin, tinutulungan lang natin dito ang system para sa malalimang pananaliksik na mabilis na mahanap ang kailangan nito.
Sa praktika, hindi kailangang komplikado o mano-manong minementena ang system na ito. Ang pinakamahuhusay na implementasyong nakita namin ay ginagawa ng mga LLM sa ingestion pipeline—awtomatikong kumukuha ng mga entity upang punan ang graph—o simpleng ipinapasa sa mga umiiral na system of record, gaya ng lookup sa Salesforce API. Kabilang sa mga karaniwang halimbawa ang:
Mga hash map lookup, halimbawa, mag-query gamit ang pangalan ng produkto at ibalik ang paglalarawan nito
Payak na lookup ng mga “karaniwang” ugnayan, halimbawa, ang gene na ito ang pinakamadalas na nauugnay sa mga sakit na ito sa aming graph ng mga sanhi at ugnayan ng gene
Mga modelo para sa named-entity recognition, na pangunahing kapaki-pakinabang sa mga larangang may masalimuot na problema sa pagtukoy ng entity, gaya ng pharmaceuticals
Para sa may pinakamakukumplikadong ugnayan ng data, makapagbibigay ang magagaang RDF graph ng pinakamadaling palawaking solusyon para sa ontology
… at iba pa
Kapag naipatupad ito, mahusay nang makakakilos ang system sa inyong mga source ng data. Simple ang susunod na tanong: paano ninyo malalaman na palagi nitong ginagawa ang tama sa aktuwal na paggamit?
Ngayong naaabot na ang inyong data at ibinibigay ng navigation layer ang mapa, kaya na ng inyong system na gawin ang trabaho. Ngunit sa konteksto ng enterprise, walang saysay ang kakayahan kung hindi maaasahan.
Dito matatagpuan ang pinakamalaking libingan ng mga AI project. Maraming team ang nahulog sa bitag ng mga evaluation na batay lamang sa “pakiramdam.” Nagpapatakbo sila ng query, binabasa ang output, sumasang-ayon, at saka ito inilalabas. Hindi gumagana ang paraang ito kapag bumubuo ng system para sa malalimang pananaliksik na maaaring awtonomong magsuri ng 5,000 dokumento upang magrekomenda para sa desisyon sa supply chain na nagkakahalaga ng milyun-milyong dolyar.
Ang mahalagang pagbabago rito ay hindi na modelo ang sinusuri ninyo kundi isang system. Ang pag-unawa sa tanong, pagpaplano, tool calling, interpretasyon, pagbabawas ng context, reranking, at kahit tila nakakabagot na detalye ng connector gaya ng mga timestamp ay pawang nakikita sa karanasan ng user.
Tinutulungan tayo ng mga structured at nauulit na eval na lutasin ang mga problemang ito.
Sa pagbuo ng mga eval, malawak na mahahati natin ang mga ito sa tatlong kategorya, mula mekanikal hanggang subhetibo.
Ito ang bahaging pinakamalapit sa mga unit test at dito madalas pinakamabilis umusad ang mga team sa simula. Karaniwang ito rin ang pinakamatatag sa paglipas ng panahon; kapag na-set up na, patuloy itong naghahatid ng benepisyo sa buong buhay ng proyekto.
Ang “mga mekanikal na eval” ay karaniwang mga pagsusuring maaaring patakbuhin sa bawat query nang walang taong kailangang mamagitan. Tinutulungan tayo ng mga ito na matiyak na predictable at ligtas ang kilos ng system sa aktuwal na dami ng mga user.
Kabilang sa ilang halimbawa ang:
Kalagayan ng citation: Nakaturo ba ang lahat ng citation sa mga siping talagang nakuha? May mga pahayag bang walang citation? May mga pahayag bang hindi sinusuportahan ng source material? Masyado bang pangkalahatan ang mga citation, halimbawa, isang buong dokumento ang binanggit para sa iisang pahayag?
Wastong paggamit ng tool: Ginamit ba ng system ang lahat ng tool na sinabi nitong ginamit nito? Ginamit ba nito nang tama ang mga navigation tool? May mga kahilingan ba ito sa tool na mali ang format? Makatwiran ba ang pag-ulit nito nang magkaroon ng error?
Mga budget sa latency at gastos: Napanatili ba nito ang target na time-to-first-token? Lumampas ba ito sa inaasahang dami ng tool call o budget? Gumamit ba ito ng napakaraming oras at compute para sa maliit na pakinabang?
Maaaring karaniwan ang tunog ng mga ito, ngunit ito mismo ang mga pagsusuring pumipigil sa pagkabulok ng isang enterprise system.
Bilang aktuwal na halimbawa, gumamit kami ng dalawang layer ng pagsusuri sa citation na tumatakbo sa bawat query sa proyekto ng malalimang pananaliksik para sa pagtukoy ng target ng gamot. Una, kapag bumubuo ng sagot, inuutusan namin ang modelo na maglagay ng madalas na inline citation. Kamakailan lamang din naging maaasahan ang mga LLM sa gawaing ito, bandang unang kalahati ng 2025. Mauunawaan ng sinumang sumubok nito noon sa makabuluhang dami ng data kung gaano ito kahirap dati. Dahil dito, makapagsasagawa kami ng mga simpleng regex check upang makita, halimbawa, kung may binanggit na link ng artikulong wala sa mga ibinigay na source.
Isinasagawa ang pangalawang layer ng pagsusuri pagkatapos i-stream ang sagot. Una, hinahati sa mga chunk ang sagot at saka sinusuri ang bawat isa, habang naghahanap ang system sa nakuhang data ng mga source na sumusuporta sa mga pahayag sa chunk na iyon. Kapag walang makitang sumusuportang ebidensiya, minamarkahan ito bilang posibleng hallucination.
Kung mga unit test ang mekanikal na eval, code review naman ang analitikal na eval.
Dito, sinusubukan nating unawain kung mahusay na natatapos ng system ang gawain. Karaniwang nais naming malaman kung gumagamit ito ng tamang mga tool, sumusunod sa tamang direksiyon ng pananaliksik, pumipili ng pinakamapagtitiwalaang source, at nakaaalam kung kailan titigil, bukod sa iba pa.
Sa praktika, karaniwan itong anyong serye ng mga pares ng tanong at sagot (Q-A), kung saan alam, halimbawa, ang makatuwirang pagkakasunod-sunod ng mga tool call o ang tamang pasya batay sa pananaliksik mula sa unang tool. Mahalagang tandaan na hindi kailangang tumugma nang 1:1 ang mga pares na Q-A sa input at output ng buong system para sa malalimang pananaliksik; maaari ring subukan ang mga subprocess sa ganitong paraan. Gamit ang mga label na ito—na maaaring gawin ng tao o ng mahusay na labeling model, bagama’t relatibo rito ang “mahusay”—magagamit natin ang LLM-as-judge upang bigyan ng score at suriin ang performance ng mga research run. Sa pagsubaybay sa mga score na ito sa paglipas ng panahon, malalaman natin kung nakapagpapabuti sa system ang ating mga pagbabago o kung nakapagdulot tayo ng pagbaba ng performance.
Dahil mas mataas ang halaga ng mga run na ito sa pera at oras, karaniwang dapat isagawa ang mga ito pana-panahon, ayon sa takdang iskedyul o bago ang mga update ng bersyon.
May maganda rin itong pangalawang benepisyo: direktang magagamit ang ganitong mga analitikal na evaluation upang gabayan ang pagpapahusay sa mga sparse connection na tinalakay natin kanina. Kung paulit-ulit ninyong nakikitang gumagawa ang modelo ng parehong mahusay na pagtalon—halimbawa, “spec → historically relevant RFP examples”—kahit hindi pa tahasang pinag-uugnay ng mga tao ang mga artefact na iyon, kapaki-pakinabang iyon. Maaari ninyong gawing pangunahing edge o shortcut ang ugnayang iyon upang makinabang ang mga susunod na run sa mas mababang latency at mas mataas na consistency.
Dito rin natutukoy ang isa sa pinakamagastos na problema sa mga system para sa malalimang pananaliksik: ang likas na pagkiling na i-maximize ang recall. Palaging makakahanap ang isang modelo ng isa pang source. Ang tanong ay kung dapat ba itong gawin. Maaari nating i-adjust ang modelo upang palakasin ang makatuwirang paghinto: kinikilala ng system na malabong baguhin ng karagdagang retrieval ang konklusyon at pinipili nitong maghatid ng sagot na mahusay ang suporta at tumutugon sa tanong ng user.
Ipinapakita ng mga mekanikal na eval na ligtas ang system. Ipinapakita ng mga analitikal na eval na mahusay ito. Ipinapakita ng mga eval ng user kung talagang kapaki-pakinabang ito.
Isa pa itong larangan kung saan maraming team ang nagkakamali. Gumagawa sila ng kahanga-hanga sa teknikal na aspeto ngunit walang gustong gumamit nito nang pangalawang beses. Sa konteksto ng enterprise, ito ang pagkakaiba ng matagumpay na deployment at magastos na research project.
Sa pinakapundasyon, layunin ng mga evaluation ng user na maunawaan kung nilulutas ng system ang tamang problema sa tamang paraan. Nangangahulugan itong lumampas sa “nakuha ba nito ang tamang sagot?” at itanong ang “may ibinigay ba itong maaari kong aksiyunan?”
Sa praktika, karaniwang may ilang anyo ang mga eval ng user:
Mga pag-aaral sa pagkumpleto ng gawain: Talaga bang mas mabilis o mas mahusay na natatapos ng mga user ang kanilang aktuwal na trabaho gamit ang system? Hindi ito tungkol sa kung kayang sagutin ng modelo ang isang tanong, kundi kung nakuha ng totoong user ang kailangan niya sa aktuwal niyang workflow.
Mga kwalitatibong feedback loop: Regular at structured na pag-uusap sa mga power user. Aling mga query ang paulit-ulit nilang pinapatakbo? Saan nawawala ang tiwala nila? Kailan sila sumusuko at bumabalik sa lumang paraan? Madalas na inilalantad ng mga sesyong ito ang mga uri ng pagkabigong hindi lumilitaw sa inyong mga test set, dahil nagtatanong ang mga user sa mga paraang hindi ninyo inaasahan o may ipinapalagay silang pamantayan sa kalidad na hindi ninyo alam.
Analytics ng paggamit: Aling mga query ang inuulit? Aling mga sagot ang kinokopya at ginagamit sa ibang lugar? Saan nagki-click ng thumbs down ang mga user? Hindi palaging kabiguan ang bumababang paggamit—kung minsan ay nakuha na ng mga user ang sagot at nagpatuloy na sila—ngunit maraming maipakikita ang mga pattern kung kailan at paano nila iniiwan ang mga query tungkol sa mga bahaging hindi natutugunan ng system ang inaasahan.
Kapag pinagsama-sama, nagbibigay ang mga ito ng paraan upang sukatin ang pakinabang nang hindi nanghuhula, at tumutulong na matukoy ang mga problema bago masira ang tiwala ng user.
Gayunman, kahit ang system na may perpektong score sa mekanikal na accuracy at kinagigiliwan ng mga unang user nito ay maaari pa ring bumagsak sa pinakahuling pagsubok: pagpapataas ng pangunahing kita ng negosyo. Mga pangunahing kailangan lamang dito ang pagiging maaasahan at kasiyahan ng user. Upang matawid ang agwat mula matagumpay na pilot tungo sa enterprise asset na nagdudulot ng malawakang pagbabago, kailangan ninyong tumingin nang higit pa sa paraan ng paggana ng system at tumuon sa kung saan ito ginagamit.
Tinalakay natin kung paano gagawing kapaki-pakinabang sa system ang inyong data, at pagkatapos ay kung paano gagawing kapaki-pakinabang sa mga user ang inyong system. Ngayon, kailangan nating talakayin kung paano gagawing kapaki-pakinabang sa inyong negosyo ang system na ito.
Matindi ang naging pagtuon dito ng mga lider ng negosyo kamakailan, at tama lamang iyon. Kasunod ng mga ulat gaya ng pahayag ng MIT na 95% ng mga enterprise AI project ay hindi nakakamit ang ROI, nawala na ang pagtanggap sa mga kahanga-hangang demo na hindi naman nade-deploy. Handa na ang mga modelo. Napatunayan na ang mga architecture. Ang tanong ngayon ay: maide-deploy ba ninyo talaga ito sa paraang lumilikha ng halaga para sa inyong negosyo?
Ang magandang balita: ang mga frontier system para sa malalimang pananaliksik na binuo ayon sa mga prinsipyong nasa itaas ay nasa magandang posisyon upang maabot ang pamantayang ito. Hindi nila sinusubukang i-automate ang lahat o palitan ang buong tungkulin ng mga empleyado. Layunin nilang gawing higit na epektibo ang pinakamahuhusay ninyong tao sa trabahong may mataas na halaga na ginagawa na nila.
Ngunit upang umusad mula “gumagana sa teknikal na aspeto” tungo sa “naghahatid ng ROI,” kailangan ang ilang karagdagang susi: mga pagpili sa organisasyon, karanasan ng user (UX), at pagsukat na magpapasya kung magiging pang-araw-araw na tool ito o malilimot na tab.
Sa aming karanasan, dalawa ang mga ito.
Madalas nakatutuksong magsimula sa mga internal na gawaing mababa ang panganib gaya ng “summarise this meeting.” Bagama’t ligtas, bihirang makapagpatunay ang mga use case na ito ng sapat na halaga para bigyang-katwiran ang gastos.
Pinakamahusay ang resulta ng mga system para sa malalimang pananaliksik kapag inilalapat sa malalaki at mahihirap na gawain—magagastos na problemang ang pagbuti sa kalidad o bilis ay nagdudulot ng mapatutunayang pagtaas ng kita o estratehikong bentahe.
Nakikita namin ang pinakamataas na ROI kapag nakatuon ang mga kumpanya sa mga larangang gaya ng:
Masalimuot na Pagbuo ng Bid & RFP: Makakatulong ang mga system para sa malalimang pananaliksik sa awtomatikong pagkuha ng pinakamalapit na dating panalo at talo, pagtukoy sa iilang clause na laging nagdudulot ng redline, paghahanap ng pinakamatibay na patunay para sa isang requirement, at iba pa, bago pagsama-samahin ang lahat sa malinaw at matibay na positioning para sa tender. Hindi natipid na oras ang sukatan dito kundi win rate, pagpapanatili ng margin, at mas kaunting huling-yugtong sorpresa sa legal o komersiyal na usapin.
Pagsusuri sa Larangang Siyentipiko: Sa mga organisasyong nakatuon sa R&D—pharma, biotech, at semiconductor—ang panimulang larangan ay ang pagpapaikli sa ilang linggong pagsusuri ng literatura at internal na kaalaman tungo sa magagamit na direksiyon ng pananaliksik. Makababasa ang isang system para sa malalimang pananaliksik ng libo-libong paper, patent, internal na ulat, lab note, at dating pagsusuri ng programa upang imapa ang mga nalalaman at pinagtatalunan, at makabuo ng landscape na suportado ng ebidensiya. Sa gayon, makapaghahatid ito ng mas mabilis na iteration cycle, mas kaunting pagsubok na nauuwi sa wala, at higit sa lahat, mas maikling panahon bago ang unang human trial.
Insight sa Merkado: Para sa mga bangko at hedge fund, nagmumula ang halaga sa pagbabago ng hiwa-hiwalay na internal research—mga note, modelo, transcript, at komento ng broker—kasama ng mga external signal—filing, earnings, macro print, at balita—tungo sa suporta sa trade na sapat para sa pagpapasya. Patuloy na makabubuo at makapag-a-update ang system para sa malalimang pananaliksik ng pananaw tungkol sa isang kumpanya, tema, o macro question—ilalantad ang mahahalagang pagbabago mula noong nakaraang linggo, pagtutugmain ang magkakasalungat na source, at gagawa ng investment memo o trade packet na may kumpletong provenance.
Ang pagkakatulad ng mga ito ay hindi sila mga chat. Masalimuot silang workflow na karaniwang nangangailangan ng magagastos na external consultant o ilang linggo ng oras ng senior staff. Kapag inilapat ninyo sa mga problemang ito ang system para sa malalimang pananaliksik, hindi maikakaila ang halaga.
Isa ito sa mga pagbabago sa karanasan ng user na magbibigay-hugis sa 2026.
Kung chatbot lamang ang inyong system para sa malalimang pananaliksik na tinatanong ng mga user upang makahanap ng impormasyon, maaari itong mabilis na mauwi sa paminsan-minsang paggamit. Nananatili itong reference tool, at ang mga user pa rin ang kailangang magsama-sama ng mga output upang makuha ang nais nilang huling resulta. Ngunit kung para itong analyst na laging available at maaaring atasan, maaari nitong lubos na baguhin ang operating model ng team.
Nakikita namin ang paglayo mula sa “pakikipag-chat”—maiikli at salit-salitang usapan—tungo sa pag-aatas: pagtatakda ng saklaw, template, at layunin, at pagpapahintulot sa system na gawin ang trabaho.
Tatlong partikular na pagbabago ang nagbibigay-daan dito:
Mga Output bilang Artefact: Bihirang nasa chat window ang trabahong may mataas na halaga; nasa mga dokumento, memo, at slide deck ito. Dapat lampasan ng mga modernong system para sa malalimang pananaliksik ang yugto ng chat at direktang buuin ang pinal na artefact ng negosyo. Kapag makahihiling ang user ng “3-page investment memo in our corporate format” at makatatanggap ng nada-download na file sa halip na sunod-sunod na teksto, biglang umiikli ang panahon bago makuha ang halaga. Karaniwan din itong pinalalawak sa nakaiskedyul na pagbuo, kung saan maaaring humiling ang mga user na awtomatikong gumawa ng mga email o ulat na may mga bagong insight at ipamahagi ang mga ito sa mga nauugnay na partido habang may lumilitaw na bagong data.
Lokal na Optimization sa pamamagitan ng Custom Template: Sapat na ang tibay ng mga modelo upang hayaan nating hubugin ng mga business unit o indibidwal na user ang sarili nilang prompt at gawi nang hindi sinisira ang system. Magkaiba ang hitsura ng risk report sa London at New York. Sa pagpapahintulot sa mga team na mag-upload o magdisenyo ng sarili nilang structural template at magtakda ng sariling pamantayan sa paghinto—halimbawa, “always check these three specific internal databases”—o format ng output, mas malaki ang mapapakinabangan ng mga user sa system at makagagawa sila ng bagay na lalo nilang gugustuhing gamitin.
Tiwala bilang Interface: Kapag nag-aatas ang user ng gawaing tumatagal nang mahigit 20 minuto, nagiging pangunahing usapin ang tiwala. Hindi kayo maaaring magpakita ng black box. Dapat ilantad ng interface ang pangangatwiran at mga pagpili ng system, ipinapakita sa user kung aling mga tool ang ginagamit, gumagawa ng mga citation, at iba pa. Madalas naming makita na sa pinakamagandang UX para sa mga system na ito, default na ipinapakita ang pangkalahatang insight tungkol sa progreso ng pananaliksik at binibigyan ang user ng opsiyong magsuri nang mas malalim sa pamamagitan ng pagpapalawak ng sidebar o katulad na bahagi para sa higit pang impormasyon.
Nakikita namin ang hinaharap kung saan may iniangkop na system para sa malalimang pananaliksik ang bawat nangungunang enterprise sa likod ng pinakamahahalagang workflow nito. Magkakaroon ito ng anyo ng serye ng mga analyst na laging available, maaasahang makapagsusuri ng libo-libong internal na artefact, at makagagawa ng mga pasya at deliverable na maaaring aksiyunan ng mga tao. Habang itinataas ng mga frontier na modelo ang hangganan ng kakayahang magsagawa, lumilipat ang kaibahan sa mga pundasyon: gawing naaabot ang data, bigyan ng mapa ang system, at gawing bahagi ng operasyon ang pagiging maaasahan sa pamamagitan ng mga eval.
Ang mga pag-unlad sa kakayahan ng modelo nitong nakaraang taon ang pinakamalinaw na palatandaan kung saan ito patungo. Ang pagkakataon para sa mga lider sa 2026 ay kumilos nang maaga. Pumili ng panimulang larangan kung saan malinaw ang halaga, bumuo ng tiwala sa pamamagitan ng provenance at mga guardrail, at gawing patuloy na lumalakas na kakayahang ginagamit araw-araw ng negosyo ang inyong enterprise solution para sa malalimang pananaliksik—mula sa pagiging pilot lamang.