2025 შეიძლება იყოს ხელოვნური ინტელექტის აგენტების წელი, თუ ისინი გადარჩებიან საწარმოს ჯოჯოხეთს

ათწლეულების განმავლობაში, ბიზნესი ცდილობდა ავტომატიზირებას უკან ოფისის ამოცანების, მონაცემთა შეყვანის, ბილინგის პროცესებისა და სხვა განმეორებადი სამუშაო ნაკადების ავტომატიზაციას. მიუხედავად იმისა, რომ პროგრამული უზრუნველყოფა განვითარდა, ჭეშმარიტი ბოლომდე ავტომატიზაცია საწარმოების უმეტესობისთვის მიუწვდომელია. ახლა, დიდი ენობრივი მოდელების (LLMs) სწრაფი ზრდასთან ერთად და „AI აგენტების“ გაჩენით, რომლებსაც შეუძლიათ მსჯელობა და ავტონომიური მოქმედება, იზრდება რწმენა, რომ 2025 შეიძლება იყოს წელი, როდესაც საბოლოოდ ვიხილავთ მნიშვნელოვან წინსვლას საწარმოს ავტომატიზაციაში.

სემ ალტმანმა საჯაროდ განაცხადა , რომ „2025 წელს ჩვენ შეიძლება ვიხილოთ პირველი AI აგენტები, რომლებიც შეუერთდებიან სამუშაო ძალას და არსებითად შეცვლიან კომპანიების პროდუქციას“, ხოლო მარკ ბენიოფი აბრუნებს Salesforce-ს „AgentForce“-ზე მომავლის მოლოდინში, სადაც მრავალი ორგანიზაციული პროცესია დელეგირებული. სპეციალიზებულ აგენტებს. ეს პროგნოზები ბადებს მთავარ კითხვას: შეუძლიათ თუ არა ხელოვნური ინტელექტის აგენტებს გადალახონ რეალური საწარმოთა სისტემების რთული დაბრკოლებები? ამ სტატიაში ჩვენ განვიხილავთ საწარმოს ავტომატიზაციის უნიკალურ სირთულეებს და გამოვიკვლევთ დღევანდელი პერსპექტიული (მაგრამ ჯერ კიდევ მომწიფებული) გადაწყვეტილებებს. ჩვენ ასევე გაგიზიარებთ პრაქტიკულ ტესტებს Salesforce-ში (SFDC) ერთი შეხედვით მარტივი სამუშაო პროცესით - ახალი ანგარიშისთვის გადამყიდველის შეკვეთის შექმნა - რაც ავლენს კულისებში დამალულ სირთულეს.

რატომ არის საწარმოს ავტომატიზაცია ასე რთული?

ქაღალდზე, საწარმოს ამოცანების ავტომატიზაცია მარტივი ჟღერს: დაატრიალეთ სკრიპტი სისტემაში შესასვლელად, შეავსეთ ფორმები და დააწკაპუნეთ „გაგზავნაზე“. პრაქტიკაში, სირთულე შემაძრწუნებელია. საწარმოები ეყრდნობა ჩანაწერების უამრავ სისტემას, როგორიცაა Salesforce, SAP, Oracle და უამრავი ადგილობრივი გადაწყვეტილებები. თითოეულ სისტემას აქვს ნებართვების საკუთარი ქსელი, ავთენტიფიკაციის ნაკადები და ინდივიდუალური ბიზნეს ლოგიკა. უფრო მეტიც, ეს სისტემები ხშირად ძლიერ მორგებულია. ხშირია სპეციალიზებული UI-ების, დამატებითი მონაცემთა ველების და შეკვეთილი სამუშაო ნაკადების ნახვა, რომლებიც განსხვავდება ბიზნესიდან ბიზნესამდე.

MuleSoft-ისა და Deloitte-ის ერთობლივი გამოკითხვის თანახმად, მსხვილ საწარმოებს შეუძლიათ გამოიყენონ საშუალოდ 976 სხვადასხვა სისტემა ყოველდღიური ოპერაციების მხარდასაჭერად ( წყარო ). ეს ფრაგმენტაცია ნიშნავს, რომ ავტომატიზაციის ხელსაწყო უნდა ესაუბროს მრავალ სისტემას, თითოეულს თავისი ნიუანსი; ზოგი ძლიერი API-ით, ზოგი კი საერთოდ არ აქვს. ხშირად, უმარტივესი ამოცანები გულისხმობს მონაცემთა გადაკვეთას ძველ, მოძველებულ აპლიკაციებსა და ღრუბელზე დაფუძნებულ ახალ სერვისებს შორის. მაშინაც კი, სტანდარტული პლატფორმები, როგორიცაა Salesforce, შეიძლება გახდეს ლაბირინთული მას შემდეგ, რაც პერსონალური სამუშაო ნაკადები და მესამე მხარის ინტეგრაცია მოხდება.

ამ ფონზე, LLM-ზე მომუშავე აგენტები გვპირდებიან უფრო მოქნილ მიდგომას: მათ შეუძლიათ მონაცემების გაანალიზება, მსჯელობა შემდეგი ნაბიჯების შესახებ და თუნდაც რთული GUI-ებში ნავიგაცია - ყოველ შემთხვევაში, თეორიულად. მაგრამ როგორც შემდეგ მაგალითში დაინახავთ, რეალობა იმისა, რომ ხელოვნური ინტელექტის აგენტმა განახორციელოს Salesforce-ის ძირითადი სამუშაო პროცესიც კი, ადამიანის დახმარების გარეშე, უფრო რთულია, ვიდრე ბევრს ესმის.

პრაქტიკული მაგალითი: პერსონალური გადამყიდველის შეკვეთის შექმნა Salesforce-ში

ამოცანა

წარმოიდგინეთ, რომ თქვენ ხართ გაყიდვების პარტნიორი ველოსიპედის მწარმოებელ კომპანიაში, რომელიც იყენებს Salesforce-ს. თქვენ ახლახან მიყიდეთ 1 დიდი Dynamo X1 ველოსიპედი 5000 დოლარად ახალ გადამყიდველს სახელად "Northern Trail Cycling". თქვენი ამოცანაა:

1 - ავთენტიფიკაცია Salesforce-ში (მოწოდებული რწმუნებით).

2 - შექმენით ახალი ანგარიში გადამყიდველისთვის.

3 - შექმენით გადამყიდველის შეკვეთა და დაამატეთ ხაზის ელემენტი (ველოსიპედი).

4 - წარუდგინეთ ეს შეკვეთა წარმოებას დასამტკიცებლად.

წარმატებული შესრულებისთვის, ჩვენ ველოდებით, რომ საბოლოო შედეგი ასე გამოიყურება:

როგორც ჩანს, საკმაოდ მარტივია, მაგრამ ეშმაკი დეტალებშია. კომპანიის Salesforce ინსტანცია მორგებულია: ის იყენებს მორგებულ „გადამყიდველის შეკვეთის“ ობიექტს და ნაკადს, სპეციალურ გადათრევის ფუნქციას პროდუქტების დასამატებლად და ფარული ნაბიჯის „წარმოებაზე წარდგენა“ მკაფიო ეტიკეტირების გარეშე. მე გამოვცადე ეს სცენარი AI-ზე ორიენტირებული ავტომატიზაციის რამდენიმე განვითარებული მიდგომის გამოყენებით, რათა მენახა, როგორ აფასებენ ისინი.

კლოდ კომპიუტერის გამოყენება

რა არის ეს?

Claude Computer Use არის Anthropic-ის ახალი ფუნქცია, რომელიც დაინერგა Claude 3.5 Sonnet v2-ით . ის სტანდარტული LLM ფუნქციის გამოძახების პარადიგმას კიდევ ერთი ნაბიჯით აწვდის კლოდს მთელი კონტეინერირებული დესკტოპის გარემოს „ნახვისთვის“ და „გაკონტროლებისთვის“. მას შეუძლია სკრინშოტების გადაღება, მათი ინტერპრეტაცია ვიზუალური/სივრცითი მსჯელობით და ოპერაციული სისტემის დონის მოქმედებების შესრულება, როგორიცაა მაუსის დაწკაპუნება, გადახვევა და კლავიშების დაჭერა.

მომხმარებლის პერსპექტივიდან, თქვენ აძლევთ კლოდს მაღალი დონის დავალებას („შედით Salesforce-ში და შექმენით ეს გადამყიდველი შეკვეთა“) და კლოდ ზუსტად ამის გაკეთებას ცდილობს. ის მოძრაობს თანმიმდევრობით:

1. სკრინშოტის გადაღება და მისი ინტერპრეტაცია.
2. UI მოქმედებების გაცემა (მაუსის დაწკაპუნება, კლავიშების დაჭერა, bash ბრძანებები).
3. გაიმეორეთ დავალების დასრულებამდე (ან არ დათმობს).

გამოცდაზე დაყენება

დავიწყოთ Anthropic-ის მითითების განხორციელების უმარტივესი მიდგომით, სისტემის მოთხოვნის ცვლილების გარეშე. აქ არის ურთიერთქმედების დასაწყისი, რომელიც აჩვენებს თავდაპირველ მოთხოვნას, კლოდის შემოთავაზებულ გეგმას და დესკტოპს, რომლითაც ის იწყებს ურთიერთქმედებას.

კლოდის კონტეინერულ სამუშაო მაგიდაზე დაკვირვება თავდაპირველად შთამბეჭდავი იყო. მან გახსნა ბრაუზერი, ეწვია Salesforce URL-ს, შევიდა სისტემაში მოწოდებული რწმუნებათა სიგელებით და გადავიდა "ანგარიშებზე". მან უნაკლოდ შექმნა ახალი ანგარიში Bike Production Company- სთვის, შეიტანა სწორი დეტალები ფორმაში, შემდეგ სცადა ახალი გადამყიდველის შეკვეთის შექმნა. საქმეები შეუფერხებლად მიდიოდა მანამ, სანამ ველოსიპედის დასამატებლად მორგებულ ინტერფეისს არ შეხვდა. სისტემა გაიჭედა პიქსელზე დაფუძნებული გადაადგილების მცდელობისას.

რამდენიმე წარუმატებლობის შემდეგ, ის ცდილობდა ეპოვა ალტერნატიული მეთოდი (როგორიცაა ფარული ღილაკი "დამატება ელემენტი"). პირველი მცდელობა ღილაკით „რედაქტირება“ წარუმატებელი აღმოჩნდა.

„მე შევამჩნიე, რომ რედაქტირების დიალოგში არ არსებობს პროდუქტების დამატების მკაფიო გზა. ნება მომეცით ვცადო განსხვავებული მიდგომა, გადამყიდველის შეკვეთების ჩამოსაშლელ სიაზე დაწკაპუნებით, რომ ვნახო არის თუ არა სხვა ვარიანტები“.

საბოლოოდ მან გზა იპოვა ახალი ელემენტების დამატების ხერხის აღმოჩენით „დაკავშირებული“ ჩანართით - მხოლოდ მაშინ, როდესაც აპლიკაციის დინამიური ტრიგერები ავტომატურად არ განაახლებს შეკვეთის მთლიანობას. SFDC აპლიკაციის შემქმნელებმა არ დაასრულეს ამ კოდის ბილიკის შემუშავება და ელოდნენ, რომ ადამიანი უბრალოდ მიჰყვებოდა გადათრევისა და ჩამოშვების მეთოდს. მოკლედ, ნაკადი განკუთვნილი იყო ადამიანებისთვის და არა ხელოვნური ინტელექტის აგენტისთვის.

შემდეგ კლოდმა სცადა ეპოვა ღილაკი „წარმოებაზე წარდგენა“, რომელიც დაკრძალული იყო საბაჟო ჩანართის ქვეშ. ამ ნაბიჯის შესახებ წინასწარი ცოდნის ნაკლებობის გამო, ის კიდევ რამდენიმე წუთის განმავლობაში გაჩერდა. საბოლოოდ, მე მომიწია ჩარევა, ხელით დავამატე ველოსიპედი შეკვეთაში და მივუთითე კლოდს შესაბამის ღილაკზე. დაახლოებით 10 წუთის შემდეგ და დაახლოებით $0.80 გამოყენების ხარჯების შემდეგ, პროცესი ჯერ კიდევ არ იყო სრულად ავტომატიზირებული. ადვილი იყო იმის დანახვა, თუ რატომ უწოდებს Anthropic ამ ფუნქციას ექსპერიმენტულს: საჭიროა მრავალი რეალური სამყაროს დამცავი მოაჯირები და გაუმჯობესება, სანამ კომპიუტერის გამოყენება ნამდვილად მზად იქნება წარმოებისთვის.

შეიძლება უკეთესი გახდეს?

მიუხედავად მისი უხეში კიდეებისა, კონცეფცია საინტერესოა. ხედვაზე დაფუძნებული AI GUI ინტერაქციისთვის სწრაფად იხვეწება და დასკვნის ხარჯების მრუდი სწრაფად იკლებს. ბოლოდროინდელი a16z კვლევა ვარაუდობს, რომ იგივე შესრულებისთვის, LLM ხარჯები წელიწადში დაახლოებით 10-ჯერ მცირდება. პრინციპში, Claude-ის მომავალი ვერსიები შეიძლება გახდეს უფრო სწრაფი, იაფი და უფრო ზუსტი ვიზუალური/სივრცითი ამოცანებისთვის, როგორიცაა drag-and-drop.

თუმცა ფუნდამენტური პრობლემა რჩება ის, რომ საწარმოს UI-ები, განსაკუთრებით ძველი ან ძლიერად მორგებული, იშვიათად არის აგებული ავტომატიზაციის გათვალისწინებით. პიქსელების დონის ურთიერთქმედება მყიფეა. განლაგების მცირე ცვლილებებმა ან დინამიურმა ამომხტარმა ფანჯრებმა შეიძლება დაარღვიოს მთელი ნაკადი. ასევე მზარდი კვლევა მიმდინარეობს ვიზუალურად დასაბუთებული GUI ჩარჩოების ირგვლივ, მაგრამ ამ წარმოების კლასის ასობით სხვადასხვა სამუშაო ნაკადისთვის მთავარი ამოცანაა.

უთავო ბრაუზერები: GUI-ს საერთოდ გამოტოვება

ერთ-ერთი ალტერნატიული მიდგომა არის „ვიზუალური შეზღუდვის ყუთების“ მთლიანად იგნორირება. თუ თქვენი სამიზნე აპლიკაცია მუშაობს ვებ ბრაუზერში, შეგიძლიათ ავტომატიზირება DOM დონეზე, გამოტოვოთ ეკრანის ანაბეჭდები და პიქსელებზე დაფუძნებული ურთიერთქმედება. მიუხედავად იმისა, რომ ტრადიციული უთავო ბრაუზერები, როგორიცაა Playwright და Selenium, ხშირად ასოცირდება ტესტირების ჩარჩოებთან, ჩნდება ხელოვნური ინტელექტის გამოყენებაზე ორიენტირებული უთავო ბრაუზერების ახალი თაობა. ეს უფრო ახალი პლატფორმები ეფუძნება დრამატურგსა და სელენს, რათა უფრო დინამიური, LLM-ზე დამყარებული ურთიერთქმედება.

BrowserBase

BrowserBase არის ერთ-ერთი ასეთი მაგალითი. ის ფუნქციონირებს, როგორც ინფრასტრუქტურული პლატფორმა, რომელიც მასპინძლობს და ადიდებს ბრაუზერის სესიებს, დეველოპერებს კონტეინერების მართვის მოთხოვნის გარეშე. ურთიერთქმედების ნიმუში ტრიალებს გვერდის HTML შიგთავსის კომპონენტებად (მაგ., ფორმებს, ღილაკებად) განაწილებას მათ xPaths-ზე და ამ სტრუქტურის გადაცემას თქვენს მიერ არჩეულ LLM-ზე. შემდეგ LLM წარმოქმნის დრამატურგის კოდის მომდევნო კომპლექტს შესასრულებლად, რაც DOM-თან ურთიერთქმედების საშუალებას იძლევა კოდის მეშვეობით და არა ტრადიციული GUI დაწკაპუნების საშუალებით. იმის გამო, რომ ის სრულიად უთავოა, ის იყენებს ნაკლებ ან საერთოდ არ ასახავს ეკრანის სურათს, ინარჩუნებს კონტექსტის სიგრძეს მოკლე და შეყოვნებას უფრო დაბალი ვიდრე სრული „დესკტოპის გარემო“ მიდგომა.

ცოტა ხნის წინ, BrowserBase-მა გაგზავნა თავისი StageHand ღია კოდის ბიბლიოთეკა, რათა დეველოპერებს საქმე გაუადვილოთ. თავდაპირველ მოდელში, ურთიერთქმედება ჯერ კიდევ ძალიან მექანიკური იყო, რაც დეველოპერებს სთხოვდა უთავო ბრაუზერის დაბალი დონის დეტალებთან მუშაობას, მათ შორის უშუალოდ Playwright-ის კოდის დაწერას და HTML-ის ხელით ანალიზს. StageHand-ის საშუალებით, BrowserBase უზრუნველყოფს აბსტრაქციის უფრო მაღალ დონეს, რაც დეველოპერებს საშუალებას აძლევს გამოიყენონ განზრახვაზე დაფუძნებული ბუნებრივი ენის ბრძანებები, როგორიცაა „ნავიგაცია“ ან „ექსტრაქტი“. ეს მიდგომა ასევე ამუშავებს გარკვეულ დამუშავებას ნედლი HTML-ის კომპონენტებად გადაქცევისთვის, რაც აადვილებს LLM-ს ამოცანების შესრულებას. თუმცა, მომხმარებლებმა მაინც უნდა შექმნან საკუთარი საორკესტრო ფენები სამუშაო ნაკადების დასაკავშირებლად და სამართავად, რადგან თავად StageHand არ გვთავაზობს ჩაშენებულ ორკესტრაციას.

BrowserBase-ის შესამოწმებლად მე გამოვიყენე მათი დეველოპერის სათამაშო მოედანი, რომელიც უზრუნველყოფს კონსოლს Playwright-ის კოდის დასაწერად და LLM-ის მოთხოვნის დამწერს ამ სკრიპტების ავტომატურად წარმოებისთვის. იდეა არის მრავალსაფეხურიანი ნავიგაციის გაკეთება - შედით სისტემაში, შექმენით ანგარიში, შექმენით გადამყიდველის შეკვეთა. მაგრამ პლატფორმა მოელის, რომ თქვენ თვითონ მოაწყოთ ნაბიჯები. კლოდისთვის მიცემული იგივე მოთხოვნით დაწყებული, BrowserBase წააწყდა, რადგან მას არ შეეძლო მრავალსაფეხურიანი მსჯელობა. ასე რომ, მე გავაგრძელე ბუნებრივი ენის მოწოდების მიწოდება ყოველი ნაბიჯისთვის და ვაკვირდებოდი, ასრულებდა თუ არა გენერირებული დრამატურგის კოდი იმას, რაც იყო განკუთვნილი. ქვემოთ მოცემულ ეკრანის სურათზე შეგიძლიათ იხილოთ მოთხოვნების სერია და მათი გენერირებული დრამატურგის კოდი.

პრაქტიკაში, მე წავაწყდი პერიოდულ შეუსაბამობას Playground-ის ბრაუზერის გარემოსა და HTML ფორმებს შორის, რომლებიც უნდა შეავსოთ. უცნაურად გამოსახული ღილაკები, ლოდინის დრო გახანგრძლივდა და ფორმის ველები ზუსტად ისე არ ჩაიტვირთა, როგორც მოსალოდნელი იყო. მიუხედავად ამ ხარვეზებისა, LLM-ის მიერ გენერირებული დრამატურგის კოდმა მოახერხა შესვლა, ანგარიშის შექმნა და გადამყიდველის შეკვეთის ფორმის ნაწილობრივ შევსება. თუმცა, ნივთის დასამატებლად გადაათრიეთ და ჩამოაგდეთ ისევ დაბრკოლება იყო. დანებებამდე დაახლოებით შვიდი წუთი გავატარე მასთან მუშაობაში. ნათელი იყო, რომ პლატფორმა ჯერ არ არის შესაფერისი ასეთი ტიპის ავტომატიზაციისთვის. ის, სავარაუდოდ, საუკეთესოდ მუშაობს ვებ სკრაპინგის გამოყენების შემთხვევებისთვის.

Skyvern

Skyvern არის უფრო ერთში უთავო მიდგომა, რომელიც ნაგულისხმევად ამატებს ორკესტრაციას. BrowserBase-სგან განსხვავებით, რომელიც მომხმარებლებს სთხოვს ნაბიჯების ხელით განსაზღვრას და მართვას, Skyvern ცდილობს ორკესტრირებას გარედან. ქუდის ქვეშ, ის მუშაობს BrowserBase-ის მსგავსად - როგორც ჩანს მათ ღია კოდის მიხედვით - მაგრამ ასევე ამატებს ვებ აგენტს, რომელსაც შეუძლია ორკესტრირება და მსჯელობა ნაბიჯების შესახებ. ეს მოიცავს არასავალდებულო ხედვის რეჟიმს, რომელიც აგზავნის ეკრანის სურათებს LLM-ში ამოღებულ კომპონენტებთან და მათ xPaths-თან ერთად, რათა დაეხმაროს გადაწყვეტილების მიღებაში.

BrowserBase-ში ხელით ნაბიჯების შექმნის შეზღუდვების გადასაჭრელად, გადავწყვიტე Skyvern-ის ტესტირება მისი მართული სერვისის გამოყენებით, კონკრეტულად Workflow რეჟიმში. ეს რეჟიმი შექმნილია მრავალსაფეხურიანი პროცესებისთვის და მე მინდოდა შემეფასებინა, რამდენად კარგად მუშაობს ის ჩვენი Salesforce სამუშაო ნაკადით. სამწუხაროდ, პერსპექტივამ დაიხარჯა 15-ზე მეტი მსჯელობის ნაბიჯი და $1 კრედიტი, რომელიც დარჩა ორფაქტორიანი ავთენტიფიკაციის (2FA) პროცესში. Skyvern-ის ჰოსტირებული IP დროშით იყო მონიშნული, ამოქმედდა 2FA და არ არსებობდა კოდის ხელით მიწოდების ან ქუქი-ფაილის გაზიარების საშუალება სიტუაციის გვერდის ავლით. ეს ხაზს უსვამს ავთენტიფიკაციის მიმდინარე გამოწვევას საწარმოს პარამეტრებში და ხაზს უსვამს იმას, თუ რატომ ჩნდებიან სტარტაპები, როგორიცაა Anon , რათა ფოკუსირდნენ მხოლოდ AI აგენტებისთვის ავტორიზაციის გადაწყვეტილებებზე.

Skyvern-ის გუნდი პოზიციონირებს პლატფორმას, როგორც უფრო მარტივ, მცირე ამოცანებისთვის შესაფერისი, საკონტაქტო ფორმის ავტომატიზაცია არის ძირითადი მხარდაჭერილი გამოყენების შემთხვევა. სხვა პოტენციური გამოყენების შემთხვევები (მაგ. სამუშაოები, ინვოისები) კვლავ ჩამოთვლილია, როგორც "ტრენინგში", რაც მიუთითებს იმაზე, რომ პლატფორმა იწყება მარტივი გამოყენების შემთხვევაში ორიენტირებული ავტომატიზაციით და არა საწარმოს სამუშაო პროცესების უფრო რთული საჭიროებებით. პერსპექტივის მიუხედავად, აშკარაა, რომ Skyvern უფრო მეტად შეეფერება ნაკლებად რთულ სცენარებს მისი განვითარების ამ ეტაპზე.

გარიგებები

უთავო ბრაუზერები გამოტოვებენ პიქსელის დონის გამოცნობას, რაც ხშირად იწვევს ნაკლებ შეცდომებს და უფრო სწრაფ შესრულებას. მაგრამ როგორც კი მოხვდებით მოწინავე ფუნქციებზე, როგორიცაა გადათრევა და ჩამოშვება ან რთული ერთგვერდიანი აპები, შეიძლება დაგჭირდეთ ნაწილობრივი ეკრანის ანალიზზე ან სპეციალიზებულ კოდზე დაბრუნება. ბრაუზერები ასევე შეიძლება მოხვდნენ 2FA და IP შავ სიაში. მრავალბინიანი საწარმოს აპლიკაციებისთვის, მხოლოდ ავთენტიფიკაცია შეიძლება იყოს სახიფათო და შეიძლება მაინც დაგჭირდეთ მორგებული ორკესტრირების ფენები.

კიდევ ერთი შეზღუდვა არის ის, რომ ეს პლატფორმები ეყრდნობა კოდის დინამიურად გენერირებას LLM-ების საშუალებით ყოველ ჯერზე სამუშაო ნაკადის შესრულებისას. ვინაიდან LLM-ები არსებითად არადეტერმინისტულია, გამომავალი კოდი შეიძლება განსხვავდებოდეს გაშვებებში, რაც რთულს ხდის აუდიტის ან თანმიმდევრულობის შემოწმებას. ამ არაპროგნოზირებადობამ შეიძლება გამოიწვიოს პრობლემები, განსაკუთრებით მგრძნობიარე სამუშაო პროცესებში. მიუხედავად იმისა, რომ გენერირებული კოდის ქეშირება ზოგიერთი პლატფორმის საგზაო რუკაზე ჩანს, ის მნიშვნელოვან გამოწვევებს უქმნის LLM-ებს. დასკვნის დროს სწრაფი ან სერიული დამუშავების უმნიშვნელო ცვლილებებმაც კი შეიძლება გამოიწვიოს სრულიად განსხვავებული შედეგები, რაც გაართულებს ქეშირების პროცესს.

მთლიანობაში, უთავო ბრაუზერი შეიძლება იყოს უფრო იაფი და სტაბილური, ვიდრე სრული GUI მანიპულირება, მაგრამ ეს შორს არის ჯადოსნური გამოსწორებისგან. ბევრი გადაწყვეტა, როგორიცაა BrowserBase და Skyvern, ფოკუსირებულია უფრო ვიწრო გამოყენების შემთხვევებზე (მაგ., ფორმები, მონაცემთა ამოღება) და არა „ერთ პლატფორმაზე ყველაფრის ავტომატიზაციისთვის“.

Reverse Engineering შიდა APIs

მესამე მიდგომა არის ვებ გვერდის მთლიანად გვერდის ავლით ქსელის ზარების ჩარევით, რომლებიც ხდება, როდესაც თქვენ ირგვლივ დააწკაპუნებთ. თუ თქვენ შეგიძლიათ თქვენი ბრაუზერის მიერ გაგზავნილი მოთხოვნების აღბეჭდვა, შეგიძლიათ აღადგინოთ ეს ზარები კოდით. პრინციპში, ეს თავიდან აიცილებს UI-ზე დაფუძნებულ ბინძურ ნაბიჯებს და უზრუნველყოფს, რომ თქვენ იყენებთ იმავე ლოგიკას, რომელსაც თქვენი აპლიკაცია იყენებს. ეს ტენდენცია არ არის სრულიად ახალი, რადგან საპირისპირო ინჟინერიის API-ები დიდი ხანია არსებობს. თუმცა, ახალი დამატება მოიცავს AI აგენტს, რომელიც მსჯელობს ქსელის მოთხოვნების შესახებ, რაც პროცესს უფრო ინტელექტუალურ და ადაპტირებულს ხდის.

რამდენიმე თვის წინ, პროდუქტი სახელად Integuru გამოვიდა Hackernews-ზე და მიიპყრო ყურადღება ღია კოდის მიდგომით და ახალი მეთოდოლოგიით. მისი პოტენციალით დაინტერესებულმა, გადავწყვიტე მისი გამოცდა, მისი საინტერესო გრაფიკზე დაფუძნებული მიდგომით და AI აგენტების ინტეგრირებით, რათა მსჯელობდნენ ქსელის მოთხოვნების შესახებ. ავტომატიზაციის დროისა და ღირებულების მკვეთრი შემცირების დაპირებამ იგი შესწავლის მიმზიდველ ვარიანტად აქცია.

Integuru-ს საცავი შედარებით ახალია, მაგრამ გვპირდება. თავის არსში, ის ჩაწერს მთელ ქსელურ ტრაფიკს და ქუქი-ფაილებს Chromium-ში დავალების დროს. შემდეგ ის ქმნის მოთხოვნების გრაფიკულ წარმოდგენას, ასახავს რომელ გვერდებს ეძახიან რომელ ბოლო წერტილებს. ამ გრაფის გამოყენებით, ის ახორციელებს გადაკვეთას, გადასცემს მას LLM-ში, რათა გენერირდეს კოდი თითოეული კვანძისთვის, რომელიც იმეორებს იმავე მოთხოვნებს, საჭიროებისამებრ შეაქვს თქვენი დინამიური პარამეტრები (როგორიცაა „ველოსიპედის წარმოების კომპანია“) და აერთიანებს მათ დამოკიდებულებებზე დაყრდნობით. ამ მიდგომამ შეიძლება თეორიულად მნიშვნელოვნად გაამარტივოს ავტომატიზაციის პროცესი.

თუმცა, პრაქტიკაში ის კარგად არ მუშაობდა ჩვენი გამოყენების შემთხვევაში, ძირითადად კონტექსტური ფანჯრის შეზღუდვების გამო. ნაკადი შესაძლოა ძალიან გრძელი ყოფილიყო იმისთვის, რომ LLM ეფექტურად გაუმკლავდეს. პროცესის მოკლე ჩართვის მცდელობაც კი, პირდაპირ შესვლის ქუქი-ფაილების ჩაშენებით და საწყისი გვერდიდან დაწყებით, წარუმატებელი აღმოჩნდა. მიუხედავად იმისა, რომ ეჭვი მაქვს, რომ ჩემმა დაბალი დონის OpenAI API კლავიშმა ხელი შეუწყო ამ საკითხებს, ცხადია, რომ Integuru ჯერ კიდევ ადრეულ დღეებშია. პოტენციალი არსებობს, მაგრამ პროდუქტი საჭიროებს დამატებით დახვეწას. მისი დემო ვერსია (როგორიცაა Robinhood-დან საგადასახადო დოკუმენტების ჩამოტვირთვა) საუკეთესოდ მუშაობდა თანამედროვე ვებ ჩარჩოებზე, უფრო მარტივი ნაკადებით. Salesforce-მა, თავისი რთული წინა ნაწილით და ლაბირინთული საბაჟო ობიექტებით, დაუშვა შეცდომები.

ამის თქმით, ეს მეთოდი ჯერ კიდევ არ არის უნივერსალური გადაწყვეტა. ყველა ნაბიჯის ჩაწერის საჭიროება ზღუდავს მის მოქნილობას და ის იხრება უფრო სტატიკური მიდგომისკენ კონკრეტული ნაკადებისთვის კოდის გამომუშავების უფრო სტატიკური მიდგომისკენ, რაც მოგვაგონებს წესებზე დაფუძნებულ RPA ინსტრუმენტებს, რომლებიც პოპულარული იყო ათი წლის წინ. ეს ხაზს უსვამს ფუნდამენტურ შეზღუდვას: მიუხედავად იმისა, რომ AI მსჯელობის დამატება ქსელის მოთხოვნებზე საინტერესოა და შეუძლია გააღოს კარი ინტეგრაციისთვის იმ სისტემებთან, რომლებსაც არ აქვთ API, ის მაინც უფრო მეტად შეეფერება უფრო კონტროლირებად ან განმეორებით ამოცანებს, ვიდრე დინამიურ, მრავალფეროვან სამუშაო ნაკადებს. საწარმოს გარემო.

AgentForce: Salesforce's Native Solution

Salesforce-ში ხელოვნური ინტელექტის დაფუძნებული ავტომატიზაციის შესახებ არანაირი საუბარი არ იქნება სრული AgentForce-ის ხსენების გარეშე, მარკ ბენიოფის დიდი ფსონი Salesforce-ის ეკოსისტემაში „აგენტების“ შექმნაზე. სხვა გადაწყვეტილებებისგან განსხვავებით, რომლებიც ჩვენ ზემოთ გამოვცადეთ, რომლებიც ორიენტირებულია დეველოპერებზე და მიზნად ისახავს სამუშაო ნაკადების ავტომატიზაციას სხვადასხვა სისტემაში, AgentForce პოზიციონირებულია, როგორც დაბალი კოდის, ჩაშენებული გადაწყვეტა სპეციალურად Salesforce-ისთვის. ის აერთიანებს ბევრ კომპონენტს ერთად და ფოკუსირებულია Salesforce პლატფორმის მთელ ნაკადზე.

იდეა არის აგენტების შექმნა, რომლებიც სრულად ცხოვრობენ Salesforce-ში და დაეყრდნონ თქვენს პერსონალიზაციას. მომხმარებლები განსაზღვრავენ აგენტის ზოგად აღწერას, ანიჭებენ თემებს და აკავშირებენ ასოცირებულ მოქმედებებს, რომლებიც წინასწარ აშენებული ნაკადებია განსაზღვრული კოდით ან Salesforce UI-ის მეშვეობით. ნებართვები, მომხმარებლის როლები და ინსტრუქციები იქმნება აგენტის ფუნქციონირებისთვის. ეს კონცეფცია თეორიულად საშუალებას აძლევს ბიზნესს გამოიყენონ არსებული Salesforce მონაცემები და სამუშაო ნაკადები ავტომატიზაციის გასატარებლად ვრცელი კოდირების გარეშე.

მე მინდოდა AgentForce-ის პირდაპირ ტესტირება ჩვენი eBikes გადამყიდველის შეკვეთის მაგალითით. სამწუხაროდ, საჭიროა წვდომა აინშტაინზე (AI ფუნქციებზე), რაც არ არის ხელმისაწვდომი დეველოპერის უფასო ანგარიშში. ამის ნაცვლად, მე გამოვიკვლიე მათი 30 წუთიანი სათამაშო მოედანი გამოგონილი "Coral Beach Resort" აპლიკაციით. სატესტო ამოცანა იყო აგენტის კონფიგურაცია ჯავშნის შექმნის ავტომატიზირებისთვის, პროცესი, რომელიც გარკვეულწილად ანალოგიურია გადამყიდველის შეკვეთის ჩვენს eBikes სცენარში.

დაყენება საკმაოდ ჩართული იყო, მოითხოვდა მრავალ ნაბიჯს: ნებართვების განსაზღვრა, თემების ჩართვა, წინასწარ ჩაშენებულ მოქმედებებთან დაკავშირება, მონაცემთა რუკების ველები და ინსტრუქციების გარკვევა. ბაზარზე, როგორც დაბალი კოდის გადაწყვეტა, ცხადი გახდა, რომ აუცილებელია Salesforce-ის სირთულეების მნიშვნელოვანი ცოდნა. თუ კომპანიის Salesforce მაგალითს არ გააჩნია კარგად დოკუმენტირებული მორგებული ველები და წინასწარ კონფიგურირებული მოქმედებების ნაკადები, საწყისი აწევა შეიძლება იყოს მნიშვნელოვანი. რეალურად, ბიზნესის უმეტესობას სავარაუდოდ დასჭირდება სისტემის ინტეგრატორების ან კონსულტანტების მოყვანა ამ აგენტების სრულად დანერგვისა და ოპტიმიზაციისთვის.

AgentForce-ის წესებზე დაფუძნებული ბუნებაც გამოირჩეოდა. მომხმარებლებმა გულდასმით უნდა გაარკვიონ, თუ რომელი ველებია შევსებული ან გადაცემული, რომ ავტომატიზაციამ ზუსტად იმუშაოს, რაც მას უფრო პრაქტიკულს გახდის, ვიდრე ხელოვნური ინტელექტის მქონე ზოგიერთ პლატფორმას. მიუხედავად იმისა, რომ ეს მიდგომა უზრუნველყოფს სიზუსტეს, ის აძლიერებს Salesforce-ის ძლიერ გამოცდილებასა და არსებულ ინფრასტრუქტურაზე დამოკიდებულებას.

მიუხედავად იმისა, რომ AgentForce შემოიფარგლება Salesforce-ის ეკოსისტემით, ამას აქვს როგორც დადებითი, ასევე უარყოფითი მხარეები. ერთის მხრივ, ეს არის შეფუთული გადაწყვეტა, რომელიც აერთიანებს ავთენტიფიკაციას, მომხმარებლის ნებართვებს, ხელსაწყოების განმარტებებს და ორკესტრირების ლოგიკას ერთ პლატფორმაში. მეორეს მხრივ, ბევრი საწარმოს სამუშაო ნაკადი მოიცავს მრავალ სისტემას და AgentForce-ის მოდუნებული ბუნება ზღუდავს მის გამოყენებადობას უფრო ფართო ავტომატიზაციის საჭიროებებისთვის. მარკ ბენიოფმა განაცხადა, რომ ასობით მომხმარებელმა უკვე გააფორმა გარიგება AgentForce-ის გამოსაყენებლად, ამიტომ მისი ევოლუცია მონიტორინგის ღირსი იქნება.

ასე რომ… ჩვენ ჯერ კიდევ იქ ვართ?

ამ ექსპერიმენტებიდან ირკვევა, რომ ხელოვნური ინტელექტის აგენტის ამჟამინდელ გადაწყვეტილებებს შეუძლია ღირსეული სამუშაოს შესრულება მრავალსაფეხურიანი ამოცანების შესახებ მსჯელობისა და გეგმის შემუშავებაში. რეალური გამოწვევა არის შესრულება ბინძურ, რეალურ სამყაროში, ტომობრივი ცოდნით, თუ როგორ იქცევიან ეს სისტემები ნამდვილად. გრაფიკული ინტერფეისები შეიქმნა ადამიანური ურთიერთქმედებისთვის და თითოეული საწარმოს მორგებული ლოგიკა სირთულის მინი შავი ხვრელია. მაშინაც კი, თუ თქვენ გამოტოვებთ GUI-ს უთავო მიდგომისთვის ან შექმნით უკანა ინჟინერიას backend-ის API-ებს, თქვენ მაინც შეხვდებით ზღვრულ შემთხვევებს, ავთენტიფიკაციის დაბრკოლებებს, განაკვეთის შეზღუდვებს ან დინამიურ სამუშაო პროცესებს, რომლებიც აგდებენ საუკეთესო LLM-ებს.

დარჩენილი გამოწვევები ძირითადად საინჟინრო პრობლემებია: ძლიერი ხელსაწყოების აშენება, საწარმოს სისტემებთან ღრმა ინტეგრაცია, დამცავი რელსების დაყენება და საიმედო მონიტორინგისა და ორკესტრირების ჩარჩოების შექმნა. მათი მოგვარება შესაძლებელია თავდადებული ძალისხმევით და სპეციალიზაციით. დღევანდელი LLM-ები უკვე აჩვენებენ მსჯელობის შესაძლებლობებს ბევრად აღემატება იმას, რაც ხელმისაწვდომი იყო თუნდაც ერთი წლის წინ, და მათი ღირებულება სწრაფად იკლებს. აქცენტი ახლა უნდა გადაიტანოს ინფრასტრუქტურისა და პროცესების მშენებლობაზე, რომლებიც საჭიროა ამ შესაძლებლობების ეფექტურად გამოსაყენებლად.

თუმცა ამ სირთულეებმა არ უნდა დაჩრდილოს სტაბილური პროგრესი. ჩვენ უკვე ვხედავთ სპეციალიზებულ, ვერტიკალურად ორიენტირებულ AI ავტომატიზაციას (მაგ. SDR ან მომხმარებელთა დახმარების აგენტები), რომლებსაც შეუძლიათ მაღალი სიზუსტის მიწოდება კონტროლირებად დომენში. როდესაც თითოეული ეს ერთჯერადი ავტომატიზაცია მომწიფდება, ჩვენ შეიძლება დავინახოთ ისინი ერთმანეთთან მიჯაჭვული უფრო ფართო სამუშაო პროცესებში. ეს შეიძლება საბოლოოდ იყოს ის, თუ როგორ ვარღვევთ ბოლომდე ავტომატიზაციას დიდ საწარმოებში: რამდენიმე სპეციალიზებული აგენტის კომბინაციით, ვიდრე ერთი ზოგადი დანიშნულების აგენტის მოლოდინით, რომ ყველაფერს გააკეთებს. ამ დროისთვის, საწყისი აგენტის შექმნის ROI შეიძლება არ იყოს გამოსახული ყველა, გარდა უმაღლესი მოცულობის ამოცანებისთვის.

სპეციალიზაცია და გზა წინ

ერთი გაკვეთილი ამ ტესტებიდან არის სპეციალიზაციის მნიშვნელობა. თითქმის სრულყოფილი საიმედოობის მიღწევა ერთ დომენში (მაგალითად, ინვოისების შექმნა NetSuite-ში) მნიშვნელოვან დაზუსტებას მოითხოვს. სტარტაპებს ან შიდა გუნდებს, რომლებიც ფოკუსირდებიან ერთ სპეციალიზებულ სამუშაო პროცესზე, შეუძლიათ უკეთესი გამოცდილების მიწოდება, ვიდრე ფართო, ზოგადი გადაწყვეტა. ჩვენ უკვე ვხედავთ „ვერტიკალური აგენტების“ ტალღას, რომლებიც აგვარებენ მიზანმიმართულ ამოცანებს ფინანსებში, ლოჯისტიკაში, HR ან მიწოდების ჯაჭვში. თითოეული აგენტი ღრმად იქნება ინტეგრირებული, შესაძლოა, საჭიროების შემთხვევაში, აერთიანებს UI ავტომატიზაციას პირდაპირ API ზარებთან, როდესაც ეს შესაძლებელია, პლუს დომენის სპეციფიკური სარეზერვო ლოგიკა და დამცავი რელსები.

რჩება დიდი კითხვა: ნამდვილად იქნება 2025 წელი, როდესაც ეს აგენტები მეინსტრიმში გადადიან, თუ ჩვენ უფრო გრძელ ასაფრენ ბილიკს ვუყურებთ? ტექნოლოგია სწრაფად ვითარდება და ოპტიმიზმი უხვადაა. მაგრამ ისევე, როგორც პროგრამული უზრუნველყოფის ინჟინრები არ გაქრნენ, როდესაც კოდის გენერაცია გაუმჯობესდა, ჩვენ ალბათ ვერ ვიხილავთ „ხელისუფალ“ საწარმოს ავტომატიზაციას ყველა პროცესისთვის. სამაგიეროდ, ჩვენ ვიხილავთ განმეორებით გაუმჯობესებებს სპეციალიზებულ ჯიბეებში, საბოლოოდ მათი შეკერვით, როგორც ნაწილობრივი ავტომატიზაციის მოზაიკა.

დასკვნა

ავტონომიური AI აგენტების კონცეფცია უდავოდ დამაჯერებელია, განსაკუთრებით საწარმოს გარემოში, სადაც მრავლადაა განმეორებადი ამოცანები. პოტენციური სარგებელი - დროის დაზოგვა, შეცდომების შემცირება და თანამშრომლების შესაძლებლობა, ფოკუსირება მოახდინონ უფრო კრეატიულ და სტრატეგიულ სამუშაოზე - უზარმაზარია. თუმცა, მიუხედავად იმისა, რომ ხელოვნური ინტელექტის აგენტების ფუნდამენტური შესაძლებლობები ძლიერია, ფართოდ გავრცელების გზა დამოკიდებულია საინჟინრო გამოწვევების გადალახვაზე, გარდა ძირითადი კვლევის წინსვლისა.

სწორი ინფრასტრუქტურის შექმნა საკვანძოა: ძლიერი ხელსაწყოები, საიმედო ინტეგრაციები და დომენის სპეციფიკური გადაწყვეტილებები კარგად განსაზღვრული დამცავი რელსებითა და ორკესტრირების ფენებით. რეალურ სამყაროში საწარმოთა სისტემების სირთულე მოითხოვს სპეციალიზებულ გადაწყვეტილებებს და ეს არის ის, სადაც ვერტიკალური აგენტები შეიძლება გამოირჩეოდნენ. ვიწრო, კარგად განსაზღვრულ სამუშაო პროცესებზე კონცენტრირება საშუალებას აძლევს გუნდებს დახვეწონ თავიანთი გადაწყვეტილებები მაღალი სიზუსტით და საიმედოობით, თითოეული დომენის უნიკალური გამოწვევების გათვალისწინებით. დროთა განმავლობაში, ამ სპეციალიზებულ აგენტებს შეეძლოთ ურთიერთდაკავშირება, ავტომატიზაციის უფრო ფართო ქსელის შექმნა.

2025 წელს შესაძლოა შთამბეჭდავი წინსვლა და საპილოტე პროგრამების მზარდი რაოდენობა მოიტანოს. ავტოპილოტზე გაშვებული სამყაროს ნაცვლად, ჩვენ უფრო სავარაუდოა, რომ დავინახოთ მიზანმიმართული, მაღალეფექტური ავტომატიზაცია, რომელიც აგვარებს კონკრეტულ პრობლემებს. საწარმოს სრული ავტომატიზაციისკენ მიმავალი მოგზაურობა განმეორებადი იქნება, სპეციალიზაციითა და თანამშრომლობით. იმპულსი იქმნება და ამ საინჟინრო გამოწვევების გადაჭრა გზას გაუხსნის საწარმოს ინოვაციების მომდევნო ტალღას.

(აჩვენეთ სურათი DALL-E-ს)