ქართული ხმოვანი AI-ის მზადყოფნის სია ბიზნესისთვის

ვისთვის არის ეს მზადყოფნის სია?

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

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

1. განსაზღვრეთ ერთი გაზომვადი ბიზნესშედეგი

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

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

2. აღწერეთ საუბრის მდგომარეობები და გადასვლები

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

1. 1

   შესვლის პირობა

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

2. 2

   მოსალოდნელი პასუხი

   რომელ ველებს ელოდება სისტემა და რომელი თავისუფალი საუბარი შეიძლება მხოლოდ ფონური კონტექსტი იყოს.

3. 3

   შემოწმება

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

4. 4

   გადასვლა

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

3. გამოცადეთ ქართული რეალური ზარის პირობებში

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

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

4. განსაზღვრეთ მონაცემის ერთი სანდო წყარო

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

5. შეამოწმეთ კალენდრის, CRM-ის, API-ისა და webhook-ის კონტრაქტები

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

• დროის სარტყელი და თარიღის ფორმატი შეთანხმებულია ორივე მხარეს.
• timeout და დროებითი 5xx შეცდომა არ ითარგმნება ცრუ წარმატებად.
• webhook ხელმოწერა მოწმდება და მიღება განმეორებით უსაფრთხოა.
• საიდუმლო გასაღებები ინახება სერვერზე და არ ხვდება ბრაუზერსა ან ტრანსკრიპტში.

6. კრიტიკული ინფორმაცია მოქმედებამდე დაადასტურეთ

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

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

7. თავიდან აიცილეთ დუბლირება და განმეორებითი მოქმედება

ქსელის retry, განმეორებითი თანხმობა ან სამუშაო პროცესის აღდგენა არ უნდა ქმნიდეს მეორე ჯავშანს, გადახდას ან CRM ჩანაწერს. მუტაციას სჭირდება idempotency key, ატომური შენახვა და უკვე დასრულებული ოპერაციის ამოცნობა.

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

8. წინასწარ განსაზღვრეთ კონფიდენციალურობისა და წვდომის საზღვრები

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

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

9. მოამზადეთ ტელეფონია, დატვირთვა და ხარვეზის fallback

SIP კავშირი, ნომრის მარშრუტი, აუდიოს ფორმატი, packet loss, jitter, რეგიონი და პარალელური ზარების ზღვარი წინასწარ უნდა შემოწმდეს. თუ STT, TTS, LLM ან ბიზნესსერვისი მიუწვდომელია, ზარი კონტროლირებადად უნდა დასრულდეს ან ადამიანს გადაეცეს.

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

10. ჩაატარეთ სიმულაცია წარმოებაში გაშვებამდე

სიმულაცია უნდა ფარავდეს არა მხოლოდ იდეალურ საუბარს, არამედ გადაფარვას, დაგვიანებულ STT-ს, ძველ პასუხს, ფონურ მეტყველებას, შესწორებას, უარყოფას, დუმილს, API timeout-ს და ზარის მოულოდნელ შეწყვეტას.

11. ადამიანთან გადართვას კონტექსტი უნდა მოჰყვეს

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

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

12. მონიტორინგი, ვერსიონირება და rollback წინასწარ დაგეგმეთ

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

• გაზომეთ მომხმარებლის პასუხის დასრულებიდან აგენტის აუდიოს დაწყებამდე დრო.
• ცალკე გამოყავით STT, turn detection, LLM, tool და TTS დაყოვნებები.
• აკონტროლეთ განმეორებითი კითხვები, არასწორი გადასვლები, გადართვები და დაუდასტურებელი მოქმედების მცდელობები.
• შეცვლილი prompt, flow და provider კონფიგურაცია ვერსიაში ფიქსირდება.

მინიმალური გასაშვები ზღვარი

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

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