რას ნიშნავს წინა ხაზზე გაგზავნილი ინჟინერი OpenAI-ში
რას ვაკეთებთ, როგორ ვმუშაობთ და როგორ ვჭრით ბიზნესის ურთულეს პრობლემებს რეალური შედეგის მისაღწევად.
ავტორი: კოლინ ჯარვისი, წინა ხაზის ინჟინერიის ხელმძღვანელი OpenAI-ში
როცა Codex გამოვიდა, გუნდის ერთმა წევრმა მკითხა: „რას ვიზამთ, როცა Codex ერთი მცდელობით გაართმევს თავს იმ სცენარებს, რომლებზეც ბოლო რამდენიმე თვე ვმუშაობდით?“
ეს კითხვა ზუსტად გამოხატავს იმას, თუ რას ნიშნავს წინა ხაზზე გაგზავნილი ინჟინერი OpenAI-ში. კლიენტების გვერდით ვმუშაობთ, რათა მათი ყველაზე რთული პრობლემები გავიგოთ და საიმედო გადაწყვეტები შევქმნათ. მიღებული ცოდნა ჩვენი პროდუქტების ჩამოყალიბებას უწყობს ხელს და კვლევით გუნდს კონკრეტულ გადასაჭრელ პრობლემებს უსახავს.
ეს არის პროგრესი. თუ ყოველ რამდენიმე თვეში ჩვენი ჩარევის საჭიროებას ვაქრობთ, ესე იგი, ჩვენი წინა ხაზზე გაგზავნილი ინჟინრების გუნდი თავის საქმეს ასრულებს.
გუნდი 2025 წლის დასაწყისში დავაარსე, რათა აღმოგვეფხვრა ის, რასაც „გაშლის ნაპრალს“ ვუწოდებთ: განსხვავება მოდელების ერთი შეხედვით შესაძლებელ უნარებსა და იმას შორის, რასაც ადამიანები თავიანთ საქმიანობაში საიმედოდ იყენებენ.
მოდელების შესაძლებლობები უფრო სწრაფად განვითარდა, ვიდრე მათი გამოყენებისთვის საჭირო სისტემები და პროცესები. ზოგჯერ სწორედ პროდუქტია ის, რაც გვაკლია. ზოგჯერ მოდელი ბენჩმარკში კარგ შედეგს აჩვენებს, თუმცა რეალური ცვლადებისა და შეზღუდვების პირობებში ამოცანას ვერ ასრულებს.
ყურადღებას კლიენტების ყველაზე რთულ პრობლემებზე ვამახვილებთ. სადაც ჩვენი მოდელები ამოცანას უკვე ასრულებს, პროდუქტის გუნდსა და კლიენტთან ერთად ვმუშაობთ, რათა გადაწყვეტა განმეორებით გამოსაყენებელი გავხადოთ. სადაც კი მათი შესაძლებლობები საკმარისი არ არის, კლიენტებსა და კვლევით გუნდთან ერთად ვადგენთ ნაკლოვანებებს და მათ აღმოფხვრაზე ვმუშაობთ. ჩვენი მიზანია, ყოველმა თანამშრომლობამ მომდევნო კლიენტს უკეთესი საწყისი პირობები შეუქმნას. თუ საბაზისო დონეს იმდენად ავამაღლებთ, რომ ამ ტიპის პრობლემის გადასაჭრელად კლიენტებს შემდეგ ჯერზე წინა ხაზზე გაგზავნილი ინჟინრები აღარ დასჭირდებათ, ესე იგი, ჩვენი საქმე კარგად შეგვისრულებია.
200-წლიანი ისტორიის მქონე სასოფლო-სამეურნეო კომპანიის, John Deere-ის, ამოცანა იყო, ინდივიდუალური რჩევები უფრო მეტი ფერმერისთვის გაეხადა ხელმისაწვდომი.
ერთ-ერთი მაგალითია See & Spray — სარეველების ზუსტი კონტროლის ტექნოლოგია, რომელიც კამერებისა და მანქანური სწავლების მეშვეობით სარეველებს ამოიცნობს და სითხეს ასხურებს, ნაცვლად მთელი მინდვრის დამუშავებისა. შედეგად, ქიმიკატების გამოყენება 70%-მდე მცირდება.
თუმცა ამ სარგებლის მისაღებად ფერმერებმა უნდა იცოდნენ, როგორ მოახდინონ ტექნოლოგიის კონფიგურირება, დაგეგმონ სეზონი და პირობების ცვლილებასთან ერთად შეცვალონ მუშაობის მეთოდები.
John Deere-მა OpenAI-ის API-ები დანერგა, რათა ასეთი მხარდაჭერა ინდივიდუალურ საჭიროებებზე მოერგო და ფართო მასშტაბით გაეწია.
AI-ს შეუძლია ფერმერების კითხვებს ბუნებრივი ენით უპასუხოს, მათზე მორგებული დაყენების ინსტრუქციები და რეკომენდაციები მიაწოდოს, დაადგინოს, როდის ვერ იყენებს აღჭურვილობა თავის სრულ პოტენციალს და დაეხმაროს ფერმერებს იმის გაგებაში, თუ რა სარგებელს იღებენ ტექნოლოგიისგან.
ეს შესაძლებლობა ერთჯერად ურთიერთობას სცდება: შესაბამისი რჩევების მიწოდება მომხმარებელთან ურთიერთობის ყველა ეტაპზე ეხმარება ფერმერებს, უკეთ გამოიყენონ აღჭურვილობა და გაზარდონ ეფექტიანობა და მდგრადობა.
სწორედ ასეთ ამოცანებზე მუშაობენ OpenAI-ის წინა ხაზზე გაგზავნილი ინჟინრები: ისინი ორგანიზაციებს ეხმარებიან, AI-ის შესაძლებლობები აქციონ სისტემებად, რომლებიც რთულ, რეალურ გარემოებში პრაქტიკულ სარგებელს ქმნის.
თუმცა პრობლემები ხშირად მკაფიოდ არც არის განსაზღვრული, შეიძლება არ არსებობდეს დადგენილი ჭეშმარიტი პასუხი და არც მზა სახელმძღვანელო გვაქვს. ყველას სურს შექმნას ის, რაც არასდროს არსებობდა. გაცილებით ნაკლებს სურს გააკეთოს ყველაფერი, რაც ამის მისაღწევადაა საჭირო.
წინა ხაზზე მომუშავე ნიჭიერი ინჟინრების პოვნა და, ამავდროულად, „საკმარისად კარგი“ სტანდარტის ამაღლება მუდმივ ექსპერიმენტებსა და პრაქტიკულ მუშაობას მოითხოვდა.
წინა ხაზზე გაგზავნილი ინჟინრების გუნდთან ყოველი შეხვედრის დასაწყისში ვაჩვენებ სლაიდს ერთი მთავარი პრინციპით: „დაიწყეთ შედეგით, წარმატებისთვის ყველაფერი საჭირო გააკეთეთ, შემდეგ კი გაზარდეთ მასშტაბი“.
შთამბეჭდავ დემონსტრაციას დიდი გამოხმაურება შეიძლება მოჰყვეს, სანამ ვინმე იკითხავს, მუშაობს თუ არა ის რეალურ გარემოში.
ჩვენი საქმეა კლიენტის პრობლემის იმ ხარისხით გადაჭრა, რომლის საიმედოობაზეც საექსპლუატაციო გარემოში პასუხისმგებლობას ავიღებთ.
2025 წლის შუა პერიოდში დაახლოებით წინა ხაზზე გაგზავნილი 15 ინჟინერი ნახევარგამტარების სფეროში მოღვაწე მსხვილ კლიენტთან გამოყენების 10-ზე მეტ სცენარზე მუშაობდა. მიზანი იყო, მათი ვერიფიკაციის პროცესი თავიდანვე AI-ზე დაფუძნებულიყო და მოეცვა:
მიზნობრივი ტესტების გენერირება
ძირეული მიზეზების ანალიზი და ხარვეზების აღმოფხვრა
არქიტექტურის ასისტენტი
ამ სფეროში ვერიფიკაციას პროექტზე გაწეული ძალისხმევის დაახლოებით 70% შეიძლება დასჭირდეს. პოტენციალი უზარმაზარი იყო და მუშაობის დაწყება მრავალი მიმართულებით შეიძლებოდა.
წინა ხაზზე გაგზავნილი ზოგიერთი ინჟინერი OpenAI-ს სულ რამდენიმე დღის წინ შემოუერთდა და ნახევარგამტარების სფეროში არასდროს უმუშავია. ისინი კლიენტის ვერიფიკაციის გუნდში ჩაერთნენ, თავისუფალ დროს ჩიპების დაპროექტებას სწავლობდნენ და ინჟინრებთან ერთად ქმნიდნენ შეფასებებს, რათა შეემოწმებინათ, შეეძლო თუ არა AI-ს გამოსადეგი ტესტების გენერირება და ჩიპების გაუმართაობის სწორად დიაგნოსტირება.
სწავლის პარალელურად, გამოყენების ცალკეული სცენარებისთვის სპეციალური სარტყლები (harness) შევქმენით. პირველი 3–6 თვის განმავლობაში ყველა მათგანი საექსპლუატაციო გარემოში მოხვდა და პირველმა მომხმარებლებმაც დაიწყეს მათი გამოყენება. შრომის შედეგი მაჩვენებლებში დავინახეთ:
AI-ზე დაფუძნებული მიზნობრივი ტესტების გენერირებით დროის დაახლოებით 48% დაიზოგა.
ბირთვის ოპტიმიზაციით წარმადობის მედიანური გაუმჯობესება 22% იყო.
გამართვას კვირების ნაცვლად საათები დასჭირდა
როცა ეს ყველაფერი წარვადგინეთ, აპარატურული უზრუნველყოფის დირექტორმა იკითხა: „აქ მოსვლამდე ჩიპების დიზაინერებად მუშაობდით?“
ჩვენს წინა ხაზზე გაგზავნილ ინჟინრებს არ მოეთხოვებათ დარგის ცოდნა პირველივე დღეს, თუმცა მისი შესწავლა მათი პასუხისმგებლობაა.
კოდის წერის ასისტენტები პროგრამული უზრუნველყოფის შექმნას აჩქარებს, ამიტომ კლიენტის ბიზნესის გაგება კიდევ უფრო მნიშვნელოვანი ხდება. გუნდებს ფართო პროფილის სპეციალისტებისა და დარგის ექსპერტებისგან ვქმნით.
დასაბუთებული გადაწყვეტილებებისთვის საკმარისი ცოდნაა საჭირო, ხოლო არსებული მდგომარეობის შესახებ დაშვებების კითხვის ნიშნის ქვეშ დასაყენებლად — საკმარისი ცნობისმოყვარეობა.
მაგალითად, სიცოცხლის შემსწავლელ მეცნიერებებში ჩვენი წინა ხაზზე გაგზავნილი ინჟინრების სამეცნიერო გამოცდილება ეხმარება მათ იმ მკვლევრების ნდობის მოპოვებაში, რომლებიც წამლების აღმოჩენის პრეკლინიკურ ამოცანებზე მუშაობენ: სამიზნეების ვალიდაციასა და პრიორიტეტიზაციაზე, გენების ექსპრესიის ანალიზსა და ქიმიური სინთეზის გზების რეკონსტრუქციაზე. ეს ცოდნა მათ საშუალებას აძლევს, ამ სამუშაო პროცესების გაუმჯობესებაზე დასაბუთებული მოსაზრებები გამოთქვან.
უკვე ვაჩვენეთ, რომ ამ სამუშაო პროცესებს სარგებლის მოტანა შეეძლო, თუმცა სხვა გუნდში თითოეულის დანერგვა ჯერ კიდევ მეტისმეტად ბევრ ინდივიდუალურ ინტეგრაციას მოითხოვდა. შემდეგი ამოცანა ამ შედეგების შენარჩუნება და, ამავდროულად, პროგრამული უზრუნველყოფის გაშლისა და თანხლების გამარტივება იყო.
ამ დროისთვის Codex-ის შესაძლებლობები გაზრდილი იყო. ერთმა წინა ხაზზე გაგზავნილმა ინჟინერმა სცადა აპლიკაციის მის საფუძველზე ხელახლა აგება, შემდეგ კი გუნდთან ერთად გამოყენების სცენარები გადაიტანა საერთო სარტყელზე, რომლის ბირთვიც Codex იყო.
ინდივიდუალური აპლიკაციები Codex-ის საერთო საბაზისო ელემენტებზე აგებულ პლაგინებად და უნარებად იქცა. Codex ინტერფეისიც გახდა, რამაც საშუალება მოგვცა, ცალკეული სცენარებისთვის დაწერილ ტერმინალის ინტერფეისებსა და ბრძანების სტრიქონის ინტერფეისებზე უარი გვეთქვა.
თითოეული პროექტიდან ინდივიდუალურად დაწერილი კოდის დაახლოებით 90% ამოვიღეთ. ამან შეცვალა ჩვენი მიდგომა ამ სამუშაო პროცესების შექმნის, თანხლებისა და მასშტაბირებისადმი:
შეგვეძლო გვესარგებლა Codex-ის ცენტრალიზებული გაუმჯობესებებით და შეგვემცირებინა თითოეული სცენარისთვის საჭირო დამაკავშირებელი კოდის მოცულობა
ძირითადი ფუნქციები უნარებად და პლაგინებად გაერთიანდა, რამაც გაამარტივა მათი ერთმანეთისთვის გაზიარება და ცენტრალიზებული მართვა AI-ს კომპეტენციის ცენტრის (AI CoE) მიერ. ეს ნიშნავდა, რომ სხვა გუნდში დანერგვისთვის ზოგჯერ მხოლოდ ახალი კონექტორების/MCP სერვერების ჩართვა, ახალი შეფასებების შექმნა (რისთვისაც უნარიც გვქონდა შემუშავებული) და სისტემის ამოქმედება იყო საკმარისი.
2026 წლის აგვისტოს ერთ-ერთ მაგალითში საწყის გაშლას ორი თვე დასჭირდა. მეორე გუნდში გადაწყვეტის დანერგვას კი — ერთი დღე. მასშტაბის ზრდასთან ერთად მომდევნო გუნდები უფრო სწრაფად ერთვებოდნენ და ეს ტენდენცია გაგრძელდა: 2026 წლის აგვისტოში ერთ-ერთი სცენარის გაშლას მეორე გუნდში 1 დღე დასჭირდა, მაშინ როცა საწყისი გაშლა 2 თვეს გაგრძელდა.
ეს არის ერთ-ერთი გზა, რომლითაც ჩვენი ჩარევა აღარ ხდება საჭირო. საექსპლუატაციო გარემოში მოხვედრისთვის გაწეულმა შრომამ დაგვანახა, რა იყო მნიშვნელოვანი. საბაზისო პროდუქტის გაუმჯობესებასთან ერთად, შეგვეძლო ჩვენი ინდივიდუალური იმპლემენტაციის დიდი ნაწილი ჩაგვენაცვლებინა და მისი სარგებელი შეგვენარჩუნებინა.
სწორედ ამიტომ აქვს თანმიმდევრობას მნიშვნელობა. LLM-ები სწრაფად შექმნის საშუალებას გვაძლევს. გამოიყენეთ ეს სისწრაფე, რათა მომხმარებლებს ღირებული რამ მიაწოდოთ, გაიგოთ, რა ამართლებს პრაქტიკაში, შემდეგ კი მასშტაბი გაუზარდოთ იმას, რაც მუშაობს.
იგივე პრინციპი ვრცელდება ყველა თანამშრომლობაზე.
OpenAI Presence, ჩვენი პროდუქტი კორპორაციული ხმოვანი და ჩატზე დაფუძნებული აგენტებისთვის, რეალური სამომხმარებლო გაშლებიდან წარმოიშვა. სამუშაო Swarm(იხსნება ახალ ფანჯარაში)-ით დაიწყო და განვითარდა Agents API-ს მეშვეობით, ხოლო დღეს ერთი მომხმარებელი ზარების ნახევარზე მეტს ხელოვნური ინტელექტით ამუშავებს.
ექსპლუატაციაში ამ გაშლების გაშვებამ გვასწავლა, თუ რომელ პრობლემებს სჭირდებოდა ინდივიდუალური გადაწყვეტა და რომელი სტანდარტული ბლოკების გამოყენება შეეძლოთ სხვა გუნდებს. ჩვენ ეს სტანდარტული ბლოკები Presence-ში შევიტანეთ, რამაც დეველოპერებს გაუადვილა რეგულირებადი სამუშაო პროცესების ავტომატიზაცია ძირითადი ინფრასტრუქტურის ხელახლა აწყობის გარეშე. თითოეული გაშლა ხელს უწყობდა პროდუქტის ჩამოყალიბებას და მომდევნო მომხმარებელს უკეთეს საწყის წერტილს აძლევდა.
OpenAI-ს წინა ხაზზე გაგზავნილი ინჟინრები და მკლევრები ინჟინრებსა და ბუღალტრებთან ერთად მუშაობდნენ Thrive Holdings-თან, რომ Crete-ის საბუღალტრო ფირმებისთვის Tax AI (საგადასახადო ხელოვნური ინტელექტი) შეექმნათ. საპილოტო პროექტის ფარგლებში, Tax AI-მ 7000 საგადასახადო დეკლარაცია დაამუშავა და მწარმოებლურობა დაახლოებით 50%-ით გაზარდა.
ერთ-ერთი ურთულესი ამოცანა გაქირავებული უძრავი ქონების საგადასახადო დეკლარაციების ავტომატიზაცია იყო; 90%-იანი სიზუსტისა და სისრულის მისაღწევად ექვსკვირიანი საინჟინრო სამუშაო და დარგის სპეციალისტების მხრიდან შემოწმება გახდა საჭირო. ამ მუშაობის შედეგად შეიქმნა მრავალჯერ გამოსაყენებელი მიდგომები, რომლებმაც Tax AI-ს საგადასახადო დეკლარაციის სხვა რთულ დანართებზე გავრცელება გაამარტივა.
გუნდები ამჟამად იგივე მიდგომას იყენებენ ბუღალტრული აღრიცხვის, აუდიტისა და IT მხარდაჭერის მიმართ — ქმნიან სისტემებს, რომლებიც გაუმჯობესდება პრაქტიკოსების უკუკავშირისა და რეალურ სამყაროში გამოყენების გზით.
ზოგჯერ უკეთესი პროდუქტი შექმნილის გამარტივების საშუალებას გვაძლევს, თუმცა ზოგჯერ თავად მოდელს ჯერ კიდევ არ შეუძლია ამოცანის შესრულება.
თუ მხოლოდ იმას შევქმნით, რისი შესაძლებლობაც დღევანდელ მოდელებს უკვე აქვს, ვერ აღმოვაჩენთ ინტელექტუალური შესაძლებლობების იმ ნაკლოვანებებს, რომელთა აღმოფხვრაზეც კვლევითმა გუნდმა შემდეგ უნდა იმუშაოს. ამიტომ ჩვენი ბევრი მნიშვნელოვანი თანამშრომლობა სწორედ ამ შეზღუდვებთან იწყება — კლიენტი, წინა ხაზზე გაგზავნილი ინჟინერი და კვლევითი გუნდი მათ გადალახვაზე ერთობლივად მუშაობას იღებენ საკუთარ თავზე.
მსხვილ სატელეკომუნიკაციო კლიენტთან ერთად უკვე გვქონდა შექმნილი მომხმარებელთა მომსახურების პლატფორმა და მას ხმოვანი მომსახურების დამატებაც სურდა.
მომხმარებელთა მომსახურების მოცულობის დაახლოებით 90% ხმოვან ზარებზე მოდიოდა. ასეთი მიმართვების ოპერატორის გარეშე მოგვარება ჩატთან შედარებით უფრო ძვირი იყო. ამასთან, აქცენტებთან, ტონთან, დაყოვნებასა და სიზუსტესთან დაკავშირებული ახალი ტექნიკური სირთულეები უნდა გადაგვეჭრა, რათა სისტემა ექსპლუატაციისთვის ყოფილიყო გამოსადეგი. ამ ამოცანის წარმატებით შესრულება მათ ბიზნესზე მნიშვნელოვან გავლენას მოახდენდა.
პროექტის ფარგლების განსაზღვრისას ჩვენმა მოდელმა დაახლოებით 60% აჩვენა ძირითად შეფასებებში, რომლებითაც ვამოწმებდით, შეძლებდა თუ არა ის საექსპლუატაციო გარემოში ამოცანის შესრულებას. მისი შესაძლებლობების ზღვარს მივაღწიეთ. მომხმარებელთა მომსახურების სცენარებში ფუნქციის გამოძახება და ინსტრუქციების შესრულება გაუმჯობესებას საჭიროებდა.
ეს კლიენტს ავუხსენით და მუშაობაში კვლევითი გუნდი ჩავრთეთ. წინა ხაზზე გაგზავნილი ინჟინერი (FDE) კლიენტთან ერთად მუშაობდა პლატფორმის შექმნასა და იმის განსაზღვრაზე, თუ რა უნდა გაეკეთებინა მოდელს. კვლევითი გუნდი შესაძლებლობების ნაკლოვანებების აღმოფხვრაზე მუშაობდა, მოდელის თანმიმდევრული ვერსიები კი საშუალებას გვაძლევდა, პროგრესი კლიენტის მოთხოვნებთან მიმართებით შეგვემოწმებინა.
ექვს თვეში ძირითადი შეფასებების შედეგი დაახლოებით 60%-დან 80%-მდე, შემდეგ კი 90%-ზე მეტამდე გაიზარდა და ექსპლუატაციისთვის საჭირო დონეს მიაღწია.
შექმნილი ხმოვანი მოდელი ახლა საფუძვლად უდევს როგორც ამ კლიენტის სისტემას, ისე მომხმარებელთა მომსახურების სხვა ინდივიდუალურად მორგებულ და Presence-ის მეშვეობით მართულ სისტემებს. ერთი კლიენტის ბიზნესში აღმოჩენილმა პრობლემამ დაგვანახა გაუმჯობესების გზები, რომლებიც ბევრ სხვასაც გამოადგებოდა.
თითოეულ ნაწილს მნიშვნელობა ჰქონდა. კლიენტმა მზადყოფნა გამოთქვა, ემუშავა პრობლემაზე, რომელსაც მოდელი ჯერ ვერ წყვეტდა. წინა ხაზზე გაგზავნილი ინჟინერი კლიენტთან მჭიდროდ მუშაობდა, რათა პრობლემა ზუსტად ჩამოეყალიბებინა, პლატფორმა აეგო და თანამშრომლობა თავიდან ბოლომდე წარემართა. კვლევითმა გუნდმა საბაზისო მოდელის შესაძლებლობები გააუმჯობესა.
ეს კიდევ ერთი გზაა, რომლითაც ჩვენი ჩარევა აღარ ხდება საჭირო: ხელს ვუწყობთ, დღევანდელი მოდელებისთვის გადაუჭრელი პრობლემა მომავალი მოდელების შესაძლებლობად იქცეს. ჩვენი შრომის სარგებელი ბევრად სცდება რომელიმე ერთ კლიენტთან გატარებულ საათებს.
OpenAI-ს შევუერთდი, რათა AI ადამიანების ყოველდღიურ საქმიანობაში გამოსადეგი გამხდარიყო. გუნდისთვის ეს დღესაც მთავარი ორიენტირია. გუნდს ხშირად ვეუბნები, რომ LLM-ის შემუშავებისას უმეტეს შემთხვევაში ოკამის სამართებლის პრინციპი მოქმედებს — საუკეთესო გადაწყვეტა ყველაზე მარტივია. კომპანიაში, რომელსაც მოწინავე კვლევები განსაზღვრავს, და ინდუსტრიაში, რომლის რეპუტაციასაც გაზვიადებული დაპირებები აზიანებს, გვინდა შევქმნათ ის, რაც საიმედოდ მუშაობს და რასაც პრაქტიკოსები დაეყრდნობიან.
მიზანია, ყოველი თანამშრომლობა შემდეგი ნაბიჯის გაუმჯობესებას ემსახურებოდეს: უფრო მარტივად გასაშლელ პროდუქტს, უფრო რთულ ამოცანასთან გამკლავების უნარის მქონე მოდელს ან ნაკლებ ინდივიდუალურ სამუშაოს მომდევნო კლიენტისთვის.
თუ რთული პრობლემის გადაჭრა გსურთ, სიამოვნებით ვითანამშრომლებთ თქვენთან. თუ ასეთი პრობლემების გადაჭრაში მონაწილეობის მიღება გსურთ, სიამოვნებით მიგიღებთ ჩვენს გუნდში.
მაშ, რას ვაკეთებთ, როცა Codex უკვე უმკლავდება საქმეს, რომლისთვისაც სისტემას თვეების განმავლობაში ვქმნიდით?
უფრო რთულ პრობლემას ვეძებთ.
