რა ვისწავლეთ ChatGPT Apps SDK-ით პროდუქტის გამოშვებისას

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

• აირჩიეთ Apps SDK, როცა მთავარი ინტერფეისი ChatGPT უნდა იყოს და სრულფასოვანი ჩატის პროდუქტის შექმნის გარეშე გსურთ ხელსაწყოებისა და მცირე UI ელემენტების დამატება. აირჩიეთ საკუთარი აგენტების სტეკი, როცა პროცესის, მეხსიერების, პრომპტებისა და ჩაწერის ოპერაციების მკაცრი კონტროლი გჭირდებათ.

• Apps SDK შეეფერება პროდუქტებს, რომლებიც ჩატს რამდენიმე მოკლე UI ეტაპთან აერთიანებს. პროდუქტს უფრო სწრაფად უშვებთ, თუმცა კონტროლის ნაწილს თმობთ.

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

• ქვემოთ ჯერ არჩევის გზას განვიხილავთ, შემდეგ კი — რა მუშაობდა და რა არა.

გუნდების უმეტესობა ჯერაც მხოლოდ ხელოვნური ინტელექტის საპილოტო პროექტებს ახორციელებს ან მას დაბალი რისკისა და სარგებლის მქონე მეორეხარისხოვანი ამოცანებისთვის იყენებს. ცოტა მათგანი უშვებს ბიზნესისთვის კრიტიკულად მნიშვნელოვან პროდუქტს, რომელსაც მომხმარებლები ყოველკვირეულად იყენებენ. თუ მთელი ასისტენტის დამოუკიდებლად შექმნის ნაცვლად ChatGPT-ში ინტეგრირება გსურთ, ChatGPT Apps SDK ამ სხვაობის შემცირების ერთ-ერთი გზაა.

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

ამ ამოცანას Apps SDK შეესაბამებოდა, რადგან კლიენტს სჭირდებოდა:

• არავითარი ცალკე ჩატის პროდუქტის შექმნა და ჰოსტინგი — მას სურდა მომხმარებლებთან წვდომა ChatGPT-ში და არა კიდევ ერთი დამოუკიდებელი ასისტენტის გარსი.

• ჩატი და კონკრეტულ ამოცანებზე მორგებული მცირე UI — ვიჯეტის რამდენიმე მიზნობრივი ეტაპი და არა მეორე სრულფასოვანი პროდუქტი სამუშაო პროცესის შიგნით.

• სერვერული მხარის ფუნქციები, რომლებიც MCP ხელსაწყოებითაა ხელმისაწვდომი — ხელსაწყოების სტანდარტული გამოძახება და არა თავიდან ბოლომდე მათ მფლობელობაში არსებული აგენტის ინდივიდუალური შესრულების გარემო.

• აღმოჩენა ChatGPT-ში — მომხმარებლებს სამუშაო პროცესი იქ უნდა დახვედროდათ, სადაც უკვე მუშაობდნენ.

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

Apps SDK-ს აპი სამ კომპონენტს აკავშირებს ერთმანეთთან:

1. ChatGPT-ს აგენტის შესრულების გარემოს

2. თქვენს MCP ხელსაწყოებს

3. თქვენი ვიჯეტის UI-ს

პრაქტიკული პროცესი:

1. მომხმარებელი ChatGPT-ს რაიმეს სთხოვს.

2. ChatGPT-მ შეიძლება თქვენი ერთ-ერთი MCP ხელსაწყო გამოიძახოს.

3. თქვენი სერვერი ხელსაწყოს სტრუქტურირებულ შედეგს აბრუნებს.

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

5. მომხმარებელი პროცესს ჩატში ან ვიჯეტში აგრძელებს — დამატებითი ტექსტით, არჩევანით ან ვიჯეტიდან ხელსაწყოს გამოძახებით. ეს განაახლებს მიმოწერის ძაფს; ChatGPT კიდევ ერთ ციკლს ასრულებს და მე-2–მე-4 ნაბიჯები ამოცანის დასრულებამდე მეორდება.

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

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

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

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

გამოიყენეთ Apps SDK, როცა გსურთ:

• სწრაფად გაუშვათ ChatGPT-ს სამუშაო პროცესი.

• საუბრის ჰოსტინგი ChatGPT-ს მიანდოთ.

• ბუნებრივი ენა რამდენიმე მიზნობრივ UI ეტაპთან გააერთიანოთ.

• თავიდან აიცილოთ საკუთარი ჩატის ინტერფეისის, აგენტის კონტეინერისა და აღმოჩენის მექანიზმის შექმნა.

ბოლო პუნქტი განსაკუთრებით მნიშვნელოვანია, როცა თქვენი მომხმარებლები უკვე ChatGPT-ში მუშაობენ.

შექმენით საკუთარი აგენტი, როცა გჭირდებათ:

• კოდით უზრუნველყოფილი, ფიქსირებული ეტაპობრივი პროცესი.

• საკუთარი UI და დადასტურების პროცესი, რომელსაც თავიდან ბოლომდე თქვენ მართავთ.

• მეხსიერებისა და მდგომარეობის საკუთარი მოდელი.

• ყოველი გაშვებისას პროგნოზირებადი ქცევა.

• აგენტის ტრასირებები, ჟურნალები და მეტრიკები.

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

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

იდეალური სცენარი მარტივად ჟღერს: მომხმარებელი ითხოვს, ხელსაწყო მუშაობს, მონაცემები ბრუნდება, ხოლო არჩევანის საჭიროებისას ვიჯეტი ჩნდება.

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

პროექტში გამოყენებული სტეკი მარტივი იყო: FastMCP, Pydantic, React და TypeScript. მათი ინტეგრაცია უპრობლემოდ წარიმართა. მთავარი სამუშაო იყო მოდელის, ხელსაწყოებისა და UI-ს შეთანხმება შემდეგ ნაბიჯთან დაკავშირებით.

ყოველი გადასვლა მკაფიოდ განსაზღვრეთ

ხელსაწყოების შედეგებს აღარ განვიხილავდით სერვერული მხარის დაუმუშავებელ მონაცემებად. თითოეული დაბრუნებული შედეგი გადასვლის სიგნალად იქცა.

ხელსაწყოს კარგი შედეგი:

• ვიჯეტს გადასცემს გამოსახვისთვის საჭირო მონაცემებს.

• ChatGPT-ს აწვდის სტრუქტურირებულ ფაქტებს, რომლებზე დაყრდნობითაც პასუხი უნდა შექმნას.

• საჭიროებისას მიუთითებს, რა უნდა მოხდეს შემდეგ, რათა მოდელს გამოცნობა არ დასჭირდეს.

ვიჯეტის მოქმედებები მიმოწერის ძაფში ბუნდოვან ტექსტს არ უნდა აბრუნებდეს. მათ უნდა აღწეროს, რა გააკეთა მომხმარებელმა და რა უნდა მოხდეს შემდეგ.

მკაფიო გადასვლებმა საიმედოობა გაზარდა.

მოდელი მოკლე და მკაფიო ინსტრუქციებს მიჰყვება, როცა ისინი ხელსაწყოს შედეგსა და ვიჯეტის მოქმედებებშია მოცემული.

ქვემოთ მოცემულია ჩვენ მიერ გამოყენებული Pydantic-ის მცირე სტრუქტურა. გამონატანის ველი შეიცავს ვიჯეტისთვის საჭირო სტრუქტურირებულ მონაცემებს და ფაქტებს, რომლებიც ChatGPT-მ სესიაში უნდა გამოიყენოს. agent_directions ველი შეიცავს მოკლე მითითებას, თუ რა უნდა გააკეთოს ასისტენტმა შემდეგ. მიზეზი არასავალდებულოა.

1from typing import Generic, TypeVar2
3from pydantic import BaseModel4
5T = TypeVar("T")6
7class AgentDirections(BaseModel):8 assistant_instruction: str9 reason: str | None = None10
11class ToolResults(BaseModel, Generic[T]):12 agent_directions: AgentDirections13 output: T

ვიჯეტები მცირე ზომის უნდა იყოს

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

მესამე პირი ვიჯეტის შეტყობინებებში

ვიჯეტის შემდგომ შეტყობინებებს აღარ ვწერდით მომხმარებლის ჩატის მსგავსად („ავირჩიე…“, „დავადასტურე“…). მათ ვწერდით როგორც მოკლე ანგარიშებს მომხმარებლის მოქმედებაზე („მომხმარებელმა აირჩია“, „მომხმარებელმა დაადასტურა“). ეს მიდგომა იმიტომ გამოვცადეთ, რომ ChatGPT ვიჯეტის შეტყობინებებს ამატებდა ხელსაწყოს შეტყობინებების სახით მომხმარებლის შეტყობინებების ნაცვლად.

პირდაპირი მოქმედებები, როცა შემდეგი ნაბიჯი აშკარაა

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

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

შეცდომების დამუშავება

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

ხელსაწყოს კონტექსტის მართვა

სესიის მდგომარეობას ჩვენს სერვერზე ვინახავდით. ChatGPT ხელსაწყოს გამოძახებისას სესიის კონტექსტს აგზავნის; FastMCP-ში თითოეულ ხელსაწყოს Context პარამეტრი მივანიჭეთ, რათა დამმუშავებელს ამ მდგომარეობის წაკითხვა და განახლება შეძლებოდა.

• სტაბილური ID-ები და წინა შედეგები სესიაში ინახებოდა, ნაცვლად იმისა, რომ ChatGPT-სთვის ყოველ გამოძახებაზე მათი ხელახლა გადაცემა მოგვეთხოვა ხელსაწყოს არგუმენტების სახით.

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

• გამართვისა და მხარდაჭერისთვის სესიის ჟურნალები ჩვენთან რჩებოდა.

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

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

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

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

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

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

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

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

შეგიძლიათ Apps SDK გამოიყენოთ ChatGPT-ში თქვენი MCP სერვერის გასაშვებად, სანამ თავად შექმნით ჩატს, ავთენტიფიკაციასა და აგენტის დამაკავშირებელ ინფრასტრუქტურას, შემდეგ კი, როცა პროდუქტს დასჭირდება, საკუთარ სტეკზე გადახვიდეთ.

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