Поўны стэк агентнага AI узровень за ўзроўнем: ад фронтэнду да назіральнасці
Дзесяць узроўняў прадакшн-агента: фронтэнд, загрузка, разбіўка, эмбедынгі, вектарны пошук, пошук кантэксту, промптынг, LLM, разгортванне і ацэнка.
Крыніцы: The Full Stack of Agentic AI: From User Interface to Production-Grade Intelligence
Штучныя інтэлекты ўжо давно перасілі тыя моменты, калі хтось пісаў запіт і чытаў адпаведзь. Сучасныя продукты на базе ШЫ — гэта цэлыя програмныя сістэмы. Яны прыймаюць дакументы, ператвараюць хаотычны, неструктураваны матэрыял у корыстныя знанні, ствараюць ембеддынгі, запошчаюць кантэкст, ведуць дыялогі з большымі мовнымі мадэлямі, запускаюць інструменты, працуюць у інфраструктурэ воблака і сочаць за сваёй працэздатнасцю. Гэта ўдвойна стосуецца агентных сістэм ШЫ. Агент — гэта не проста LLM, які знаходзіцца ў вікні чату. Продакшн-гатовая агентная прыкладка патрабуе цэлаг тэхналогічнаг комплексу навакол мадэлі, пры чым сама мадэль ёсць толькі аднім з яе слоёў.
Дыяграма рэферэнсной архітэктуры такога комплексу ўтварае зручную карточку, якая паказвае шлях ад фронтэнду праз прыемку, запошчанне і формуванне запытаў да модэляў, ўпрацоўкі і монітарынгу. У наступных раздзелах прадстаўлены кожны з слоёў, ў чым яго прызначэння, чаму ён існуе і як інструменты взаімаўзаімаюцца між сабою.
Слойвы за моман
У пэўнай спраўнасці стак работае так: фронтэнд, прыемка дакументаў, разбіўка на часткі і прадзеянне, эмбеддынгі, база дадзеных вектараў, адзыскванне інфармацыі, інжыніерыя запросаў, LLM, інфраструктура і развёртванне, а ў канцы — абзірнасць і ацэнка.
Гэтыя элементы не ўтвараюць строгай ланцоўкі. У рэальных агентных сістэмах ўсе часткі стаячы адно з іншымі взаімаюцца. Агент можа адзыскваць інфармацыю колькіразоў, вызываць званыя засобы, прыкладваць разныя мадэлі, оцэніваць сваія адпаведзі і запускаць дадатковыя працэсы пры вырабоце канечнага рэзультата. Стак лепей розумець як тэхналогічную экасістэму, якая абслужвае інтэлігэнцію, чым як простую ланцоўку запрос-адпаведзь.
Слой 1: фронтэнд
Кожная сістэма AI патрабуе месца, дзе людзі можаць з яю сустрэцца. Фронтэнд стварае аператывы выкарыстоўвання — будзь то чат-бот, корпаратыўны портал, панель аналізу, внутрашній інструмент чы рабочая прастора з дапамогай AI. Тыповыя тэхналогіі включаюць React, Next.js, Streamlit і Azure App Service. React стварае інтэрактыўныя інтэрфейсы, а Next.js — больш ўсепрацоўваны фрэймворк для веб-дзеянаў у прымэтным выкарыстоўванні. Streamlit падходзіць для шырокага стварэння аплікацый на базе AI і дадзэнняў без традыцыйнага набора інструментаў фронтэнда. Azure App Service адказвае за кераванае хоставанне веб-дзеянаў і API.
У корпаратыўной схеме з агентамі фронтэнд — гэта не проста палатка для чату. Ён можа паказваць прыбыль агента, джэрыкі дадзэнняў, статус рабочага прайсупутку, рэзультаты інструментаў, запыты на затверджэння, створаныя дакументы і взаімадзеянні з людзьмі. Самэль гэтае месца AI стае доступным для бізнес-выкарыстоўвальніка.
Слой 2: абсарбаванне дакументаў
Спроможная сістэма патрабуе доступу да рэлевантных мяркаваў, а корпаратыўныя знанні рэдка бываюць у аднам апранутым фармаце. Яны распадзяляюцца між PDF-файламі, файламі Word, прэзентаціямі, сканамі, веб-старонкамі, базамі дадзенаў, электранаўпісамі і іншым. Працэс абсарбавання збірае і выкалывае контэнт з усіх гэтых джэрэл.
Інструменты, якія відпавядаюць гэтай функцыі, — гэта Azure AI Content Understanding, Apache Tika, Microsoft Fabric, LangChain і двыжкі OCR. OCR мае важнае значэнне, калі мяркавы знаходзяцца ў сканах або зображэннях. Apache Tika выкалывае тэкст і метаданы з вельмі шырокага спектру фарматаў. Microsoft Fabric спрыяе розвіццю болей шырокіх корпаратыўных працэсаў апрацоўкі дадзенаў, а такія фрэймворкі, як LangChain, могу з’яеднаць компаненты абсарбавання з трубопрацесамі ІІ.
Мета проста: ператворыць рассеяную інфармацыю падпрыемства ў контэнт, які можа обрабоцваць машына. Без надзеянага слоя падачы дадзеных, нават найсуперфіцыязаваныя мадэлі будуць страждзець, калі йдзе праця над дачайя значымых адказоў пра вашу організацыю.
Слой 3: разбіўка на часткі і падготовка дадзеных
Выяўленне тэксту — толькі пачатак. Дакумент на 200 сторонак не можа быць цэлым паданым у кожны запіт да мадэлі, таму большыя дакументы трэба разбіваць на меньшыя, значымыя елементы. Часткі гэтыя можу быць абзацамі, раздзеламі, старонкамі або семантычнымі елементамі, а LangChain і падобныя фрэймворкі прысвячаюць кілька стратэгій разбіўкі на часткі.
Хораша скалкавання — гэта не проста розбій на часткі кожні кілька сотэнь сімвалів, аджэ паскудна скалкавання разрушае кантэкст. Калі адзначэнне аддзеляецца ад абяснення, якое надае ў яго значэння, працэс выкарыстоўвання можа даць нецэлы рэзультат. Часткі, якія занадта вялікія, робяць выкарыстоўвання неточным, а часткі, якія занадта маленькія, втрачаюць важлівыя зв’язкі. Таму гэтая стратэгія безпасэчна вплывае на якасць усьго, што выкарыстоўваецца пасля.
Прадзеянне включае чысткаванне, адключэнне непатрэбнага кантэнту, нормалізацыю фарматаў, выкарыстоўвання метаданых, выявленне структуры дакумента і падзбагачэнне частак дадатковай інфармацыяй. Насколькі добра пасля гэтага будзе выкарыстоўвання, часта вялічыцца саме тут.
Слой 4: эмбеддынгі
Калі дакументы ужо скалкаваны, сістэме патрэбны способы, каб зафіксаваць ўсё, што яны значаць. Мадэль эмбеддынга ператварае тэкст у чысловы вектар, і падобныя паняці ў просторэ эмбеддынга апынуцца падалей адзін ад другога.
Поручыце прыклад запыткі пра перазначэнне пароля працавальніка і запыткі пра тое, як змяніць даныя для заходжання на працу. Фразавершэнне разныя, але намерэння схожыя, і хорашыя мадэлі эмбедынгу гэта разумеюць. Серэд паслуг, якія выкорыстоўваюцца для гэтага слоя, — OpenAI, Cohere і AI-сервісы на базе Azure. Рэзультатыўныя вектары служаюць адной з аснов семантычнага пошуку, што робіць гэтае адным з найзначнейшых пераходаў у структуры: людскі язык стае матэматычным выражэнням, а гэтае выражэнне дапамагае адлічваць семантычную схожасць.
Слой 5: база дадзэння вектараў
Эмбедынгі павінны быць зберагнутыя там, дзе можлівы быстрыя пошукі за схожасцю, і гэта ўласна задача базы дадзэння вектараў. У дыяграме паказаны Milvus, FAISS, Azure AI Search, Azure Cosmos DB і Azure Database для PostgreSQL. Яны сільна разныя за можлівасцямі і мадэлямі размешчэння, але всі яны спрамованы на эфектыўны пошук за дапамогою семантычнай схожасці.
Калі корыстнік ставіць запыт, сам запыт ператвараецца ў эмбедынг, і сістэма шукае найбліжэйшыя вектары. Пасля чаго падобныя фрагменты перадаюцца да наступных слоёў. Гэта ёсць аднойчынай базай большасці сістэм генеравання з дапамогай адзысквання інфармацыі.
Слоё 6: слой адзысквання
База дадзеных у вектарнай форме зберагае інфармацыю, але слой адзысквання вяршыць рашэнне, што самэе будзе паказана модэлю. Гэта разлік часта застаецца непазначаным. Адзысквання можа выкарыстоўваць сэмантычную супадзімоść, пошук па ключоўых словах, фільтрацыю метададзеных, гібрыдны пошук, перыякораванне і іншыя тэхнікі; а таксама інструменты на кшталт Azure AI Search, LangChain і LlamaIndex дапамагаюць у гэтым задачах.
Зрэлыя рашыткі спалучаюць разныя стратэгіі. Сэмантычны пошук знаходзіць матэрыялы, якія ўзаемна асоціююцца па сэнсе, тады калі пошук па ключоўых словах дбае пра тое, каб не працягнуцься точныя ідэнтыфікаторы, назвы продуктав, номеры полісаў чы тэхнічныя тэрміны. Гэта ўжыточны спосаб знаходжэння інформацыі, а сістэмы RAG у корпаратыўных установах все чырэз больш дадаюць фільтры метаданных, механізмы пераранжавання, графы знанняў і іншыя атрыбуты.
Мета не ў тым, каб знайсці як можна больш інформацыі, а ў тым, каб знайсці самую правільную інформацыю.
Слой 7: інжыніерыя запрошэнняў
Пасля знаходжэння інформацыі сістэма должна састаляць адпаведныя інструкцыі для мовнага модэля. Продакшн-запрошэнне — гэта не проста запыт корыстніка; ёно можа включаць інструкцыі для сістэмы, знайдзены кантэкст, історыю размовы, бізнес-правіла, трэбаванні да фармата выходных даных, абмежэнні безпекі, прыклады, апісанні інструментаў і метаданныя. LangChain, Promptify і DSPy — гэта прыклады інструментаў, якія дапамагаюць структуруваць і налаштаваць такія запрошэнні.
Інжыніерыя запыткаў таксама выходзіць за межы ручнага стварэння хытрых фраз. Увага пераключаецца на інжыніерыю кантэксту, якая ставіць шырэйшыя запытанні: што должна прымець мадэль, у якай структуры і на якім этапе робочага працэсу? Гэта ўжо болей важліва для агентаў, якія можаць дынамічна ствараць кантэкст на аднойчынку з пакананых ранейшых дзеянняў, запрашанага матэрыялу, рэзультатаў інструментаў і проміжных рэзультатаў.
Слой 8: LLM
У цэнтры знаходзіцца большая мовная мадэль, дзе відбываецца розумеўненне мовы, разумовыя вычысленні, генераванне тэксту і выпалненне інструкцый. Серэд платформ і модэляў, якія згадваюцца, — Azure, OpenAI, LLaMA і Mistral AI. Мадэль прымець запыт разам з рэтэльна падготававаным кантэкстам і інструкцыямі.
Ёсць адзін прынцып, які варта падтвердзіць: LLM — гэта не весь аплікэнт. Гэта адна з складовых у значна большайшай сістэме, а аплікэнт для прыменення на практычных задачах патрабуе прыему дадзейнаў, оркестрацыю, абэрненне, ацэнку, манітарынг, інфраструктуру і бізнес-логіку, якія працуюць уз яго. Гэта становіцца ўсё бол выразным, калі пераходзіць ад пратотыпа да аплікэнта для вялікіх падпрыемств.
Ад аплікэнтав на базе LLM да агентаў
Дапамагае разлічэнне звычайнага аплікэнта на базе LLM ад аплікэнта з агентамі. Базовы аплікэнт включае корыстніка, запіт, LLM і адпаведны адпаведзень. Аплікэнт на базе RAG включае корыстніка, прыем дадзейнаў, кантэкст, LLM і адпаведзень. Сістэма з агентамі ўсё бол дынамічная: корыстнік, агент, планаванне, прыем дадзейнаў, інструменты, LLM, ацэнка, дальнейшыя дзеянні, фінальны адпаведзень. Агент сам адлучае, што робіць далей, і не проста следуе за фіксаваным порадкам.
Падзеймім, калі хтось запытае, чаму не выйшла сэрвісная практыка вчора і што з тым рабіць. Агент можа выкарыстоўваць історыю выканання, аналізаваць лог-файлы, запытваць базы дадзэнняў, аналізаваць паведамленні пра аберанні, кансультавацца з правіламі керавання, выявіць верагодную прычыну і, можа, запропанаваць або запусціць затверджаны спосаб прыняцтва заходаў. Гэта прынцыпова адрозніцца ад стварэння працоўнага абаротка тэксту.
Слой 9: інфраструктура і развяртанне
Гладкая прататыпа не робіць продукт гатовым да выкарыстоўвання ў працоўнай сэрвісной сістэме. Для запуску неабходна масштабавальная інфраструктура, сеткавая арганізацыя, абарона, аўтаматызацыя развяртання, кераванне рэсурсамі і стойкасць. Назвы архітэктуры — Azure Container Apps, Azure Kubernetes Service, Docker і Kubernetes.
Docker перакладае аплікацыі ў портатыбныя контэйнеры. Kubernetes керуе контэйнернымі завадамі ў розпакаваных срэдах. Azure Kubernetes Service — гэта адмініструемая версія Kubernetes, а Azure Container Apps спрыяе прыступнам развяртванню контэйнероў без неабходнасці керування всім сераўерным сераўісам Kubernetes.
Эты слой мае важнае значэнне, калі сістэма должна справляцца з вялікім трафікам корыстувачаў, большым колікствам паралельных процэсаў, навантажэнням ад працы модэляў, фоновай апрацоўкай, практыкамі працэсування дакументаў, дзейнасцямі, якія работаюць дзяўно, інтэграцыяй з зовнішнімі інструментамі і вімогамі па абэрэнцыі падпрыемства. Модэль можа быць выдаюшчымся, але інфраструктура вялікі чыннік таго, чы рэалізавацыя яго можліва надзеямо на вялікіх масштабах.
Слой 10: стварэнне можлівасцяў аналізу і ацэнкі
Возможнае стварэнне адказоў ў сістэмах AI ўваходзіць у чысло найбольш занедбаных аспектаў іх інжынерыі. Традыцыйныя прыкладнікі можна сочыць за ўжыццём CPU, памяці, часам адпаведзення, памылкамі і частотай запытанняў. Прыкладнікі AI выклікаюць больш дакладных даных. Командам неабходна бачыць, што саме прыняў мадэль, што было выкарыстоўвана, якія інструменты працавалі, якія рашэнні былі выданы, трываласць кожнага крока, колькісць токэнаў і чы роўная адпаведзь была корыстная.
У гэтым кантэксце выкорыстоўваюцца Azure AI Foundry, OpenTelemetry і Grafana. OpenTelemetry збірае даны з розпакетаваных прыкладнікаў, а Grafana візуалізуе паметры, адносныя да працы сістэмы і самага прыкладніка.
Ешча аднам важлівым аспектам ёсць ацэнка. Сістэмы, якія працуюць у працэсе, можуць патрабаваць оцэнкі за рэлевантнасцю, правдопадобнасцю, якосцю выкарыстоўваных дадзенняў, часам адпаведзення, косцю, безпекай і задоволеннем корыстувача. Агенты паднімаюць стандарты, адколькі ўжо ўжыццё іх дзеянняў таксаваецца разам з фінальной адпаведзью:
- Чы ён выбраў правы інструмент?
- Чы гэта апранула правыя даны?
- Чы гэта выконвала непатрэбныя вызовы інструментаў?
- Чы гэта следавала правільнаму алгорытму работы?
- Чы гэта зупінілася пасля завершэння задання?
- Чы гэта належным чынам перадала задачу, калі была патрэбна дапомога чалавека?
Этыя запытанні робяць стварэнне можлівасці назірання і ацэнкі невыдваленным элементам у працы AI у прымэтных умовах.
Чаму важны весь комплекс элементаў
Паўзучая хыбная думка гласі, што стварэнне AI-зялёння значыць выбір моцнага LLM і дадзенне інтэрфейса для корыстніка. Гэта можа падыходзіць для дэманстрацыі. Аднак гэта рэдкая разваўка таго, што трэба для практычнай AI-платформы для падпрыемстваў.
Разглянем сітуацыю, калі працавальнік запытае асістэнта пра правілы організацыі ў разы выявлення певных проблем у кліентаў. Сістэма должна зрозумець запіт, знайсці правыя документы з правіламі, выбраць неабходныя часткі, перэдаць іх модэлі, стварыць обоснованы адказ, можаць паводзіцца да выканаў, саблюдаваць правілы безпекі, сочыць за взаімадзеяннем і ацэніць, чы рэспанс быў корыстны. Кожны слой выпалюе свою ролю: фронтэнд забезпечвае взаімадзеянне, працэс прыемкі дадзеных даўа знанні, прадзеянне дадзеных робіць іх прыдатнымі для вікорыстання, эмбеддынгі фіксуюць значэнне, векторныя базы дадзеных зберагаюць дадзеныя, якія можна шукаты, механізмы пошуку знаходзяць кантэкст, інструкцыі структуруюць адказ, LLM стварае адказ, інфраструктура забезпечвае масштабаванне і надзею, а механізмы адзорвання даюць можлівасць бачыць працэс і атрыбуцыю адказаў. Саврэменныя AI-сістэмы ў гэтым сэнсе ўжо ўсепакетныя.
Выбір інструментаў
Тэхналогіі, якія выкліканыя ў архітэктурэ, не ўтвараюць спісу для абсалютнага застосоўвання. Кожная з іх — гэта адна з можлівасцей для свайго слоя. Компанія можа спачатку выбраць React і Next.js, Azure AI Content Understanding для апрацоўкі дакументаў, LangChain для керавання, хоставаныя мадэль амбеддынгу, Azure AI Search для пошуку, мадэль, якая працюе на Azure, і Azure Container Apps для ўсьго гэтага. Іншая компанія можа выбраць абсалютна іншы набор.
Найважлівейшы урок — гэта тое, што архітэктура выйшае раней за інструменты. Бізнес-трэбаванні формуюць архітэктуру, архітэктура вызначае можлівасці, якія патрэбны кожнаму слою, і толькі пасля гэтага следуе выбіраць конкрэтныя тэхналогіі.
Больш, чым проста LLM
Пэўны падход да аналізу таксама адказвае на пытанне, чаму праекты, якія выкарыстоўваюць агенты, быстра становяцца складнымі. Агенту можа знадобіцца спецыялізаваная інформацыя праз RAG, структураваныя даны з баз дадзеных, зовнішня інформацыя праз API, а таксама інструменты для выканання задач і сістэмы керування практыкамі. Ёму таксама неабходныя заходы безпекі: аўтэнтыфікацыя і автарызацыя, контроль прыватнасці дадзеных, захопленне ад уражэнняў праз вставку запытак, правыя на інструменты, етапы людзкай апрацоўкі, логі аўдыту і рамкі ацэнкі.
Такім чынам, агентныя AI-сістэмы з’яўляюцца ў месцы, дзе суцэльваюцца калькі разных даследжэнняў: інжынерыя програмнага забезпечэння, інжынерыя дадзеных, інжынерыя AI, інжынерыя хмарных тэхналогій, а таксама аспекты безпекі і стварэння прозрачных сістэм. Стварэнне агентаў высокага стандарта ёсць інжынерным вызамом, а не проста вправай у напісанні запытак.
Як эвалююць архітэктуры прыкладнага програмнага забезпечэння
Галузь працюе паэтапна. Першыя застосункі ШЫ былі спрамаваны на мадэлі. Пасля таго тэхналогія RAG паў’язала мадэлі з зовнішнімі данымі. Сістэмы, расшырэныя інструментамі, дазволілі мадэлям взаімадзейваць з зовнішнімі можлівасцямі. Часоўця агентных тэхналогій ШЫ спаўнаюць аднае з іншым: мадэлі, сістэмы пошуку, інструменты, памяць, планаванне, коордынацыю і ацэнку. Развіцце праходзіць ад простых LLM да RAG, да вікорыстання інструментаў, да агентаў, да багатаагентных сістэм, і чым даўжэй яно трывае, тым больш значэнне набірае супакоўваная інфраструктура.
З чаго пачаць
Не кожнаму застосоўцу патрэбна вся стак-тэхналогія. Для простага інструменту для адпаведзення на запытанні можа пасабіць базаваны на LLM рашэннік. Калі застосоўкі патрэбны прыватныя або часта змінююцыяся знанні, трэба дадаць RAG. Калі сутнасцю проблемы ёсць адносы між ентытамі, варта рассмотрзець абранне інформацыі на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчыне на аднойчы
Гэтая галузь продовжае развіватыся. Графы знанняў, векторныя базы дадзэнняў, фрэймворкі агентаў, двойнікі рабочых практык, мультымадальныя мадэлі, інструменты ацэнкі і платформы воблака, верагатна, будуць стаўціцца ўсё бліжэй адзін да аднаго. Програмы будуць прымаць не толькі тэкст, але і зображэнні, аудыя, відэа, структураваныя даны, корпоратыўныя сістэмы і рэальныя рабочыя практыкі. Назіранне за сістэмай і ўзнакаванне яе будуць такім жа важлівымы, як і выбір яе мадэлі. Тое, што чакае нас, — гэта не столькі проста розумнейшыя мадэлі, сколькі надзеяныя сістэмы, створаныя на ўснове іх.
Вывад
Агентныя AI-сістэмы — гэта не адзін тэхналагічны элемент, а цэлы комплекс. Начынаючы з фронтэнду, дзе ведаюцься з корыстнікамі, праз прыем і падготавку дадзэнняў, эмбедынгі і векторныя базы дадзэнняў, працэсы пошуку і стварэння запытанняў, аж да LLM-модэляў, ўстановкі і манітарынгу, кожны слой вплывае на розумнасць, якую ў канцы канцоў прадстаўляе сістэма. LLM ўсьмо толькі адна частка. Сістэма агентнага тыпу высокага ступеня патрэбуе правільных дадзэнняў, стратэгіі пошуку, механізмаў коордынацыі, інфраструктуры і методаў ацэнкі. Способнасць самых модэляў будзе менш значным фактам, чым якіснае праектаванне сістэм, якія іх абслужваюць.
Супаўзаемыя матэрыялы
- Веб-стак для стартапаў у эпас АІ-агентаў: Next.js, MUI і Firebase — Калькі лічуюцься, калі агенты пішуць большасць коду: Next.js, MUI, Firebase, Vercel, PostHog і мінімальная настройка агента, а таксама паслявыяскаванні кожнага з іх.
- Што знаходзіць агент для разлічэння модэляў: змяны стылю перакрываюць скромныя змяны під час фінансавага тонкага налаштавання — Аўдытар з чорнай скрынкай паўпараўняў базовы модэль з фінансавым LoRA: 82% працоў выявілі змяны у дужыне і структуры, а намераваныя змяны ў логіцы прыняцьня рашэння засталі непазначанымі.