Sa init ng paunang pagkahumaling sa ChatGPT, nakatanggap ako ng text mula sa isang dating katrabaho. Gusto niyang magbigay ng ideya sa akin. Laging ang isa na nag-e-enjoy sa brainstorming, tumatawag kami at nagsimula siya sa "Remember how you used to always ask me to pull data for you? Paano kung ikaw na lang ang gumawa nito?" At pagkatapos ay nagpatuloy siya sa pagbibigay sa akin ng ideya na libu-libo (sampu-sampung libo?) ng iba pang mga tao ang sabay na nag-iisip: Maaaring gamitin ang mga LLM para sa text-to-SQL upang matulungan ang mga hindi gaanong teknikal na tao na sagutin ang kanilang sariling mga tanong sa data.  I was hooked on the idea, but before diving in head first, I told Lei (now my CTO) that we have to do some validation. Nakipag-ugnayan kami sa mga kaibigan at dating katrabaho mula sa iba't ibang industriya. Nagkaroon ng matinding interes sa totoong "self-service analytics." Alam namin na ito ay magiging mas kumplikado kaysa sa tila, ngunit ang pagkakataon ay masyadong magandang palampasin. Kaya't umalis kami ni Lei sa The Shire at nagsimula sa aming paglalakbay upang lumikha ng aming pananaw:  .   Fabi.ai  Ang post na ito ay hindi tungkol sa aming produkto mismo (bagama't, kung mausisa ka, maaari kang magbasa nang higit pa tungkol sa kung paano ang ilan sa mga ideya sa ibaba ay nagpapaalam sa aming kamakailang produkto  ). Sa halip, gusto kong ibahagi ang mga pangunahing natutunan na aming nakolekta mula sa pakikipagtulungan sa mga LLM para sa pagsusuri ng data sa aming paglalakbay.   dito   Tandaan: Ang paglalakbay na ito ay lubhang kulang sa mga wizard at epic na labanan sa Middle-earth. 🧙  Bakit gagamit ng AI para sa self-service analytics?  Hindi kami magtatagal sa "bakit" masyadong mahaba. Kung binabasa mo ito, malamang na mapabilang ka sa isa sa dalawang grupo:  Ikaw ay isang tao na nagnanais na mayroon kang self-service analytics na available at ayaw mong palaging maghintay sa iyong data team  Ikaw ay nasa pangkat ng data at naririnig ang tungkol sa kung paano ka tutulungan ng AI na lutasin ang iyong problema sa mga kahilingan sa ad hoc.  Ang pagwawalang-bahala sa pag-aalala sa papel ng mga data analyst at scientist, ang ideya ng isang nakakaalam na AI na makakasagot sa anumang mga tanong tungkol sa data ng isang organisasyon ay mukhang maganda. O hindi bababa sa, ito ay maganda para sa organisasyon at sa mga pinuno ng negosyo nito na ang pagkamalikhain para sa mga bagong paraan ng pagtatanong ay walang hangganan. Ang AI na ito ay maaaring maging solusyon sa paglikha ng "data-driven" na organisasyon kung saan ang bawat lider ay nakasandal sa empirical na ebidensya upang makagawa ng kanilang mga madiskarteng desisyon. At lahat sa isang maliit na bahagi ng gastos na karaniwang aabutin nito. Sa wakas! Maaaring gamitin ng mga organisasyon ang "bagong langis" na narinig nila mula noong 2010.  Ngunit kung ito ay isang mahalagang problema upang malutas at ang AI ay naging napakahusay, bakit walang produkto   na nalutas ito hanggang ngayon? ang aktwal  Bakit nabigo ang AI para sa self-service analytics hanggang ngayon  Ang mga kamakailang survey sa industriya ay nagpinta ng isang kumplikadong larawan ng AI adoption sa enterprise.  ay sinusubukan ang mga ahente ng AI. Gayunpaman, marami ang nag-aalala tungkol sa pagiging maaasahan at seguridad. Sa katunayan, 21% ng mga organisasyon ay hindi gumagamit ng mga ito. Ang mga pag-aalinlangan na ito ay partikular na nararamdaman sa loob ng mga data team, kung saan ang katumpakan at pagiging mapagkakatiwalaan ay napakahalaga sa aming kakayahang gumawa ng trabaho.   61 porsiyento ng mga kumpanya  Ang mga gumagamit ng AI–lalo na sa enterprise–ay may mataas na bar pagdating sa mga inaasahan ng teknolohiya. Sa konteksto ng data analytics at ang self-serve dream, inaasahan namin ang aming AI tooling na:  Nagbibigay ng mga insight: Mahusay ang mga talahanayan at chart, ngunit iyon ay isang subset ng kung ano ang maaaring tawaging "mga insight." Ang mga insight ay "Aha!" mga sandali na nagmumula sa pagtuklas ng mga bagay sa iyong data na sumasalungat sa iyong intuwisyon at hindi sana isasaalang-alang. Minsan ang isang SQL query o isang pivot ay maaaring magbigay ng liwanag sa mga insight na ito, ngunit sa pangkalahatan ito ay parang mas katulad ng paghahanap ng karayom sa isang haystack.  Magtrabaho nang mapagkakatiwalaan halos 100% ng oras: Ang mas masahol pa sa walang data ay ang masamang data. Kung ang AI ay hindi mapagkakatiwalaan o nagha-hallucinate ng mga sagot at data, iyon ay nagpapahiwatig ng masamang balita para sa lahat. Nangangahulugan ito na kapag may data ang AI, dapat itong gamitin nang tama. Ngunit kapag kulang ito ng data, dapat itong iwasang magbigay ng sagot (isang bagay na kilalang-kilalang masama ang mga LLM).  Maging naa-access sa isang malawak na hanay ng mga teknikal na hanay ng kasanayan: Ang kagandahan ng mga LLM ay maaari kang makipag-ugnayan sa kanila tulad ng gagawin mo sa isang katrabaho sa Slack. Maaari kang gumamit ng hindi malinaw na wika. Malamang na mauunawaan ng ibang tao o bagay ang iyong kahilingan sa konteksto ng negosyo. Sa kabaligtaran, mas nangangailangan ang isang sistema ng paggamit ng mga eksaktong termino sa isang eksaktong anyo, mas hindi ito naa-access. Ang ganitong uri ng sistema ay nangangailangan ng pagsasanay at pagpapalakas, na alam nating lahat, ay maaaring maging mahirap.  Nakalulungkot, karamihan sa mga kasalukuyang solusyon ay gumagamit ng tradisyunal na monolithic AI framework, na kadalasang hindi nakakatugon sa mga inaasahan. Sa nakalipas na ilang taon, nagsumikap kami ng Fabi.ai team sa isyung ito. Gumawa kami ng mga prototype para sa enterprise at nag-explore ng maraming opsyon. Sa huli, napagtanto namin na hindi kayang ayusin ni Retrieval Augment Generation (RAG) o fine-tuning ang problemang ito sa kasalukuyang monolitikong balangkas.   Noong sinubukan namin ang diskarteng ito, naging malinaw sa amin ang ilang bagay:  Ang RAG ay marupok. Masyadong maliit na konteksto at hindi masagot ng AI ang isang tanong at nanganganib na mag-hallucinate. Masyadong maraming konteksto at ang AI ay nalilito at nawawala ang katumpakan nito.  Hindi ka dinadala ng one-shot AI kahit saan. Ang pinakamahusay na AI sa mundo ay hindi kailanman magagawang tumpak na hilahin at suriin ang data sa isang solong shot. Napakaraming mga nuances sa data at tanong. Kunin natin ang pinakasimpleng halimbawang posible: Mayroon kang field na “Uri ng account” na 95% ay puno ng 10 natatanging mga halaga. Kung hihilingin mo sa AI na mag-filter sa isang hanay ng mga uri ng account, maaaring mabigo itong makilala na may mga blangko na halaga, kaya nagdudulot ng di-wastong SQL query. "Oo naman," maaari mong sabihin, "ngunit maaari naming kalkulahin ang mga istatistika para sa bawat field at sample na mga halaga at iimbak iyon sa aming context vector store." Ang mga uri ng mga isyu ay halos walang hanggan at lahat ay natatangi sa kanilang sariling paraan.  Ang data ng negosyo ay magulo. Ito ay nauugnay sa unang dalawang punto, ngunit ito ay nagkakahalaga ng pagbibigay-diin. Kahit na sa panandaliang sandali, ang isang organisasyon ay maaaring magkaroon ng ilang gold table na may perpektong tinukoy na semantic layer, na lahat ay bumabagsak sa sandaling magpasya ang pinuno ng RevOps na ayusin ang modelo ng negosyo. Gusto kong gumuhit ng pagkakatulad ng isang bahay: Sa pangkalahatan, maaari mong panatilihing maayos ang isang bahay, ngunit palaging mayroong   na kailangang linisin o ayusin. isang bagay  Masyadong limitado ang text-to-SQL. Para sa karamihan ng mga tanong sa analytics ng data, ang pagsulat ng SQL upang makuha ang data ay ang pinakaunang hakbang lamang. Ito ang hakbang na kailangan mong gawin bago ka makapagsimulang magtanong ng mas kawili-wiling mga tanong. Hindi kayang hawakan ng SQL ang kumplikadong pagsusuri na hinihiling ng mga gumagamit ng negosyo. Ang mga LLM at Python sa kabilang banda ay ganap na angkop para sa gawain. Maaaring kunin ng mga tool na ito ang iyong SQL output at hanapin ang karayom na iyon sa haystack. Maaari din silang magpatakbo ng mga pagsusuri ng regression upang tumuklas ng mas malalaking trend.  Matapos tingnan ang mga isyung ito, naisip namin kung paano gagawing mas mahusay ang AI sa mga problema. Noon ay naglaro ang mga ahente ng AI at pinatibay ang konseptong ito para sa amin.  Ang hinaharap: Agent meshes  Sa sandaling napagmasdan namin ang mga ahenteng balangkas, alam namin na mababago nito ang laro. Bigla naming nadama na maaari naming hayaan ang AI na magpasya kung paano sasagutin ang mga tanong. Maaari itong gumana sa pamamagitan ng mga hakbang at mag-troubleshoot nang mag-isa. Kung nagsusulat ang AI ng SQL query na nawawala ang mga null value sa field na "Uri ng account," maaari nitong i-dry-run ang query, makita ang error, at ayusin ito mismo. Ngunit paano kung maaari nating gawin ito nang higit pa at hayaan ang AI na gumana sa karamihan sa Python at gamitin ang mga LLM? Ngayon, higit pa sa paghila ng data ang ginagawa ng AI. Maaari itong gumamit ng mga pakete ng Python o LLM upang makahanap ng mga outlier, trend, o natatanging insight, na karaniwang kailangan mong hanapin nang manu-mano.  Ngunit mayroon pa rin kaming isang problema: ang magulo na data ng enterprise. Naniniwala kami na malulutas ito ng mga organisasyon sa pamamagitan ng paggamit ng matitinding kasanayan sa data engineering, tulad ng a  at isang mahigpit na semantic layer. Gayunpaman, bihira kaming makakita ng mga organisasyon na talagang gumawa nito sa totoong buhay. Karamihan sa mga organisasyon ay gumagamit ng mga spreadsheet, half-baked na talahanayan, at patuloy na nagbabagong mga modelo ng data. Mula rito, nakaisip kami ng ideya ng pagbuo ng mga espesyal na ahente ng AI na maaaring mabilis na mabuo upang sagutin ang isang partikular na hanay ng mga tanong.   arkitektura ng medalyon  Habang lumalaki ang mga kumpanya, pinangangasiwaan nila ang mas maraming data at mas maraming user. Ang ideya ng agent mesh ay nakakatulong na balansehin ang mabilis na paggawa ng desisyon sa kontrol na kailangan para sa pamamahala. Tumutulong ang mga dalubhasang ahente na magtakda ng malinaw na mga hangganan at responsibilidad para sa bawat AI. Gumagawa din sila ng scalable na paraan para makipag-usap ang mga ahente. Dagdag pa, makakatulong sila sa pamamahala ng mga mapagkukunan nang mahusay sa mga koponan at kumpanya.  Mga espesyal na ahente ng AI  Ang ideya sa likod ng isang dalubhasang ahente ay ang ahente na ito ay maaari at sasagutin lamang ang mga tanong sa isang napakahigpit na tinukoy na dataset. Halimbawa, maaari kang lumikha at maglunsad ng isang ahente ng AI na sumasagot sa mga tanong tungkol sa mga kampanya sa marketing. O maaari kang bumuo ng isa pa upang sagutin ang mga tanong tungkol sa marketing pipeline, at iba pa.   , gamit ang arkitektura na ito. Ang mga maagang palatandaan ay napaka-promising. Kapag maingat na na-curate ang mga dataset at nasa tamang antas ng granularity, masasagot ng mga ahenteng ito ang isang partikular na hanay ng mga tanong nang lubos na maaasahan. Ang tagabuo ng mga ahenteng ito ay maaaring ibahagi ang mga ito sa mga hindi teknikal na user at magpahinga nang madali dahil alam na hindi sasagutin ng AI ang mga tanong na wala sa saklaw.   Inilunsad namin kamakailan ang Agent Analyst  May isang depekto lang: Kailangang malaman ng mga user kung aling ahente ang pupuntahan para sa kung anong tanong. Parang kailangan mong malaman ang tamang marketing analyst para magtanong ng isang tanong kumpara sa pagtatanong lang ng pangkalahatang tanong. Sa isang pangkalahatang tanong, maaaring idirekta ito ng isang tao sa koponan sa tamang tao. Dito pumapasok ang konsepto ng isang "agent mesh".  Pinagsasama-sama ang mga ahente  Kung mapagkakatiwalaang masasagot ng isang ahente ang mga tanong na partikular sa domain, bakit hindi hayaan ang mga ahente na makipag-usap sa isa't isa? Bakit hindi, halimbawa, ang marketing campaign agent ay direktang magtanong sa pipeline agent kung mas madali nilang masasagot ang isang tanong? Naniniwala kami na dapat itong magawa. Sa katunayan, iniisip namin na sa hinaharap ay magkakaroon ng mga network ng mga ahente na may hierarchical na istraktura. Maaari mong isipin ang isang "Agent ng GTM" na tumatawag sa "Agent sa marketing." Ang ahenteng ito pagkatapos ay parehong tinatawag na "Pipeline agent" at ang "Marketing campaign agent."  Ang ideyang ito ay parang mas pangkalahatang ideya na lumulutang sa paligid ng AI na kilala bilang "  ." Isa itong kinabukasan kung saan maayos na nakikipagtulungan ang mga ahente ng AI sa iba't ibang organisasyon. Ginagawa nila ito habang tinitiyak na mananatiling matatag ang seguridad at tiwala.    Internet ng mga Ahente  Ang mesh approach na ito ay nag-aalok ng ilang pangunahing bentahe sa isang monolitikong AI (sa isang malinis na semantic layer):  Pagmamasid: Dahil ang isang ahente ay nagbibigay ng mga sagot batay sa partikular na data, maaari mong masubaybayan ang bawat sagot pabalik sa ahente na iyon. Nakakatulong ito na matiyak ang katumpakan sa pamamagitan ng pag-audit. Upang magbigay ng isang kongkreto, kahit na sobrang simple, halimbawa, isipin na mayroon kang dalawang talahanayan ng mga kaganapan: isa para sa marketing at isa para sa produkto. Kung tatanungin ng isang user, "Aling mga kaganapan ang nakakuha ng pinakamaraming kita?" maaaring ipagpalagay ng AI na ang ibig nilang sabihin ay mga kaganapan sa produkto. Kahit na mali, makikita ng user kung aling ahente ang tumugon at maaaring magabayan ang AI.  Pagpapanatili: Tulad ng isang makina ng kotse, kung madali kang makahanap ng mga problema at mabilis na palitan ang mga bahagi, ang kotse ay nagiging mas maaasahan. Kung ang isang ahente ay nagsimulang mabigo dahil sa isang pagbabago sa modelo ng data, pagkatapos ay maaaring mabilis na makita at ang ahente ay maaaring ma-update.  Katumpakan: Sa bawat ahente na tumatakbo sa loob ng sarili nitong mga limitasyon, walang puwang para ito ay umalis sa riles. Maaaring wala itong sagot, ngunit hindi ito gagawa ng isang bagay na hindi kapani-paniwala.  Sa pagtatapos ng araw, ang ideyang ito ng isang mesh ay hindi nobela. Sinasalamin nito ang konsepto ng pinaghalong mga eksperto na ipinakita upang mapabuti ang katumpakan para sa mga LLM. Kinukuha lang nito ang parehong ideya at dinadala ito sa mga ahente ng AI.  Mga teknikal na hamon ng mga meshes ng ahente  Sa Fabi.ai, marami pa tayong mararating habang bumubuo tayo ng analyst Agent mesh. Ngunit, nalampasan na namin ang ilan sa mga malalaking hamon sa teknikal na imprastraktura sa daan.  Ang mga ahente ng data analyst ng AI ay nangangailangan ng isang natatanging arkitektura. Ang disenyong ito ay dapat magbigay-daan sa kanila na gumamit ng Python o LLM upang sagutin ang mga tanong, manatiling naka-sync sa mga pinagmumulan ng data, at magkasya sa mga collaborative na platform, habang nananatiling secure at scalable. Ang bawat ahente ay kailangang gumana sa sarili nitong kernel ng Python, na kailangang mabilis na paikutin pataas o pababa upang mabawasan ang mga gastos at manatiling naka-sync sa source data.   Ang mga arkitektura na hindi nagbibigay ng mga indibidwal na kernel sa bawat ahente ay maaaring magkaroon ng isa sa mga sumusunod na panganib:  Salungatan ng estado para sa mga variable sa pagitan ng mga ahente ng AI. Dalawang magkahiwalay na ahente ang maaaring bumuo ng variable na "foo" upang sagutin ang isang tanong, na magdulot ng salungatan. Maaaring may iba pang mga paraan upang makabuo ng mga natatanging identifier, ngunit pinapataas nito ang posibilidad ng pagbuo ng di-wastong code ng AI.  Mga panganib sa seguridad na dulot ng pagbabahagi ng data sa pagitan ng iba't ibang team o kahit na iba't ibang organisasyon.  Mga bottleneck sa pagganap kung ang isang ahente ay kumukuha ng hindi katimbang na halaga ng mga mapagkukunan ng pagkalkula.  Ang hamon ng pagbuo ng ganitong uri ng platform ay isang hamon sa AI dahil isa itong hamon sa DevOps.  Naghahanap sa hinaharap: Pagtanggap ng mga dalubhasa, pinamamahalaan na mga ahente ng AI sa data  Habang pinamamahalaan ng mga kumpanya ng enterprise ang higit pang mga AI application sa kanilang mga operasyon, kailangan nila ng mga dalubhasa at mahusay na pinamamahalaan na mga diskarte. Gumagamit ang agent mesh framework ng mga dalubhasang AI data agent bilang paraan para sa pag-scale ng AI sa data analytics. Ang diskarte na ito ay nagpapanatili ng seguridad, pagiging maaasahan, at pagganap na buo.  Maaaring inaasahan namin na ang AI ay nasa lahat ng dako sa ngayon, na sumasagot sa karamihan ng mga tanong sa data. Ngunit, kung titingnan nating mabuti, ang pag-unlad sa loob lamang ng dalawang taon mula nang ilunsad ang ChatGPT ay kahanga-hanga. Marami pa tayong dapat matutunan sa paglalakbay na ito. Sa aking isipan, gayunpaman, ang mga ahente at mga balangkas ng mesh ng ahente ay magiging susi sa enterprise AI.

This story contains new, firsthand information uncovered by the writer.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This post provides insights into new product. 

Ang audio na ito ay ginawa sa orihinal na wika ng kuwento!

Ang Text-to-SQL ay Dapat na Maging Killer App ng AI. Ito ay Hindi.

About Author

MGA KOMENTO

HANG TAGS

ANG ARTIKULONG ITO AY IPINAKITA SA

Related Stories

How I deployed my spark document classification(Logistic Regression) model/s as a standalone app…

COVID-19: We Need More Than Data, We Need Insights!

Hosting a DNS domain on the blockchain

Encrypted Instant Messaging Recommendations January 2017

How I deployed my spark document classification(Logistic Regression) model/s as a standalone app…

COVID-19: We Need More Than Data, We Need Insights!

Hosting a DNS domain on the blockchain

Encrypted Instant Messaging Recommendations January 2017

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps