ბლოგი

განახლებულია 10 წთ კითხვაუსაფრთხოება და მმართველობატუტორიალი

Human-in-the-loop AI აგენტები: დამტკიცება, ესკალაცია და კონტროლი

როგორ მუშაობს human-in-the-loop AI აგენტი, რომელი მოქმედებები საჭიროებს დამტკიცების კარიბჭეს, როდის არის საჭირო ესკალაცია და როგორ დავამატოთ HITL კონტროლი რუტინის დაბლოკვის გარეშე.

Northstar

Northstar არის AI agent systems სტუდია. ალექსი - engineering/product, ჯორდანი - operations/workflow fit. Production აგენტები არსებულ tools-ში.

Alex Morgan · LinkedIn · Northstar

კონტროლის კარიბჭის სქემა ადამიანის დამტკიცებისთვის AI აგენტის სისტემაში

პირდაპირი პასუხი

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

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

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

Runtime HITL და training-time HITL

ზოგადად, human-in-the-loop ნიშნავს, რომ ადამიანები მონაწილეობენ ავტომატური სისტემების მუშაობაში, ზედამხედველობასა ან გადაწყვეტილების მიღებაში (IBM). მანქანური სწავლების განათლებაში ეს ხშირად ტრენინგის ეტაპის სამუშაოა: მონაცემების მარკირება, პრეფერენციების უკუკავშირი (RLHF) ან აქტიური სწავლება. Production AI აგენტებისთვის runtime HITL განსხვავებულია: აგენტი სთავაზობს ხელსაწყოს მოქმედებას, სამუშაო ნაკადი ჩერდება და ადამიანი წყვეტს რეალურ გვერდით ეფექტამდე. ეს სტატია runtime კონტროლის კარიბჭეებზეა და არა მოდელის ტრენინგის ციკლებზე.

სად არის ადამიანი არქიტექტურაში

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

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

მოთხოვნა
   |
   v
აგენტის გეგმა -> read-only tools -> მტკიცებულებების პაკეტი
   |                              |
   | უსაფრთხო, შექცევადი          | რისკიანი, გარე, გაურკვეველი
   v                              v
ავტომატური შესრულება         ადამიანის განხილვის რიგი
   |                         | დამტკიცება | შეცვლა | უარყოფა
   |                         v          v      v
   +--------------------> კონტროლირებული მოქმედება  ესკალაცია
                                  |
                                  v
                         აუდიტის ლოგი + შედეგის მეტრიკები

სურათი: კონტროლის კარიბჭის ნაკადი ადამიანის დამტკიცებისთვის AI აგენტის სისტემაში. უსაფრთხო შექცევადი სამუშაო შეიძლება ავტომატურად შესრულდეს; რისკიანი ან გაურკვეველი სამუშაო გვერდით ეფექტამდე განხილვის რიგში შედის.

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

პრაქტიკული გაყოფა არის propose, შემდეგ commit: აგენტი აბრუნებს სტრუქტურირებულ განზრახვასა და პარამეტრებს; ადამიანი (ან წესი) შეიძლება შეცვალოს ისინი; მხოლოდ ამის შემდეგ აპლიკაცია ასრულებს ხელსაწყოს გამოძახებას. პლატფორმის პროდუქტები იგივე იდეას გამოხატავენ როგორც მომხმარებლის დადასტურება კრიტიკული ხელსაწყოების წინ, ან კონტროლის დაბრუნება, როცა აპლიკაცია მოქმედებას ადამიანის შეტანის შემდეგ ასრულებს (AWS Bedrock Agents user confirmation; return of control). გამოიყენეთ ეს შაბლონის ენად და არა კონკრეტული cloud პროდუქტის ათვისების მოთხოვნად.

რომელი მოქმედებები ჩვეულებრივ საჭიროებს კარიბჭეს

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

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

დამტკიცება თუ ესკალაცია: გადაწყვეტილების ცხრილი

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

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

მინიმალური დამტკიცების კარიბჭის დიზაინი

  1. ზუსტად დაასახელეთ მოქმედება და მისი მაქსიმალური ზემოქმედების რადიუსი.
  2. წესი აღწერეთ დაკვირვებადი პირობებით და არა ბუნდოვანი ინსტრუქციით „გამოიყენე განსჯა“.
  3. დამმტკიცებელი მიანიჭეთ როლითა და უფლებებით და არა იმით, ვინ არის ამჟამად ონლაინ.
  4. ააწყვეთ მტკიცებულებების პაკეტი: შეყვანები, განზრახული გვერდითი ეფექტები, წყაროები, შემოწმების შედეგები და წინასწარი ხედვა იმისა, რა მოხდება თუ ადამიანი დაამტკიცებს.
  5. შემოგთავაზეთ დამტკიცების, უარყოფის და შეცვლის გზები, თითოეული გადაწყვეტილების მიზეზის ჩაწერით.
  6. განსაზღვრეთ SLA და მოძველებული ჩანაწერის გზა, რათა რიგში მყოფი სამუშაო ჩუმად არ გაქრეს (შეხსენება, ხელახალი დანიშვნა, ხელით დასრულება ან უსაფრთხო გაუქმება; არასოდეს ჩუმი ავტომატური შესრულება მხოლოდ ვადის ამოწურვის გამო).
  7. შეთავაზება, მიმომხილველი, გადაწყვეტილება, საბოლოო ხელსაწყოს გამოძახება და შედეგი ერთ correlation ID-ს ქვეშ დალოგეთ.
  8. კარიბჭის შემსუბუქებამდე გაზომეთ გადაწერის წილი, რიგის დრო, ინციდენტები და წარმატებული დასრულება.

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

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

სიმწიფის შაბლონები ერთ კარიბჭეს მიღმა

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

ეტაპიშაბლონიროდის ეხმარება
Baselineერთი დამტკიცება დასახელებულ გვერდით ეფექტამდენაგულისხმევად გარე, ფინანსური, წვდომის ან შეუქცევადი მოქმედებებისთვის
Dual controlორი ავტორიზებული როლი მაღალი ზემოქმედების რადიუსისთვისზღვარს ზემოთ გადახდები, production წვდომა, რეგულირებადი გამოქვეყნება
Sampled reviewავტომატური შესრულება დაბალი რისკის კლასებზე; ნაწილი აუდიტისთვისმოცულობა იზრდება, მაგრამ ნარჩენი რისკი გაზომვადი რჩება
Exception-onlyადამიანი მხოლოდ წესის გაცდენაზე, ხელსაწყოს მარცხზე ან ანომალიაზემომწიფებული გზები სტაბილური გადაწერისა და ინციდენტის მაჩვენებლებით
Propose / commit splitგანზრახვა და პარამეტრები რედაქტირებადია commit-მდემიმომხილველები ასწორებენ ცუდ პარამეტრებს სრული უარყოფისა და თავიდან დაწყების გარეშე

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

ზედამხედველობის კონტექსტი (არ არის იურიდიული რჩევა)

ადამიანის ზედამხედველობა საჯარო რისკის ჩარჩოებში დიზაინის მიზანია და არა ერთი დაწკაპუნებით შესრულებადი შესაბამისობის მონიშვნა. EU AI Act-ის Article 14 ეხება ადამიანის ზედამხედველობას high-risk AI სისტემებისთვის, რათა ფიზიკურმა პირებმა შეძლონ მუშაობის ზედამხედველობა და საჭიროებისას ჩარევა (Article 14 text; დამატებითი ინსტიტუციური კონტექსტი: EC AI Act service desk on Article 14). აშშ-ში NIST AI Risk Management Framework არის ნებაყოფლობითი მიდგომა AI რისკის რუკირების, გაზომვისა და მართვისთვის, მათ შორის ადამიანის ზედამხედველობა როგორც სანდო ოპერირების ნაწილი (NIST AI RMF hub; AI RMF 1.0 PDF).

ეს სტატია არ ადგენს, არის თუ არა მკითხველის სისტემა high-risk EU AI Act-ის მიხედვით, ან არის თუ არა კარიბჭის დიზაინი „შესაბამისი“ მოთხოვნებთან. რეგულაციასა და ჩარჩოებს მოეპყარით როგორც კონტექსტს; გამოყენებადობას იურიდიული მრჩეველი განსაზღვრავს. Production აგენტებისთვის საინჟინრო თარგმანი კონკრეტულია: გაჩერდით ზემოქმედებამდე, კომპეტენტურ მიმომხილველს მიეცით გამოსაყენებელი მტკიცებულებები, გადაწყვეტილება დალოგეთ და გაჩერების გზა შეინარჩუნეთ.

გავრცელებული მარცხის რეჟიმები

ყველაფრის კარიბჭე

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

კარიბჭე საერთოდ არ არსებობს

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

ესკალაცია აღიქმება როგორც უარყოფა

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

დასახელებული მფლობელი არ არსებობს

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

სუსტი მტკიცებულებების პაკეტები

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

აუდიტის კვალი არ არსებობს

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

დანერგვის ჩეკლისტი

  • ყველა ხელსაწყოს მოქმედება აღწერეთ და მონიშნეთ, არის თუ არა ის გარე, ფინანსური, დამანგრეველი, რეგულირებადი ან ძნელად შექცევადი.
  • განსაზღვრეთ მოქმედებების კლასები: ნებადართული, აკრძალული, დამტკიცებას საჭიროებს და მხოლოდ ესკალაციით.
  • დამმტკიცებლებისთვის როლზე დაფუძნებული წვდომა შექმენით და დამტკიცება სისტემის ადმინისტრირებისგან გამოყავით.
  • განხილვის ბარათი დააპროექტეთ საკმარისი მტკიცებულებებით და ზუსტი გვერდითი ეფექტის წინასწარი ხედვით.
  • Idempotency keys დაამატეთ, რათა ორმაგმა დამტკიცებამ ორმაგი მოქმედება არ შექმნას (იხილეთ აგრეთვე იდემპოტენტობა, განმეორებები და რიგები).
  • განმეორების ლიმიტები განსაზღვრეთ და განმეორებითი მარცხები ადამიანის მფლობელობაში არსებულ გამონაკლისების რიგში გადაიტანეთ.
  • გადაწყვეტილებები და შესწორებები evals-ისთვის მარკირებულ მონაცემად ჩაიწერეთ და არა არასტრუქტურირებულ ჩატის ისტორიად.
  • დატესტეთ დამტკიცების, უარყოფის, შეცვლის, ვადის ამოწურვის, ორმაგი დაწკაპუნების, მიუწვდომელი ხელსაწყოსა და არაავტორიზებული მიმომხილველის გზები.
  • Shadow mode, შემდეგ canary გაუშვით კარიბჭით გასავლელი შესრულების გზისთვის.
  • რიგის დრო, გადაწერის წილი, ინციდენტის მაჩვენებელი და ცრუ ესკალაციები ყოველკვირეულად გადახედეთ.
  • გაჩერების გადამრთველი და ინციდენტის დროს კარიბჭეების გამკაცრების პროცესი დოკუმენტირეთ.
  • მოქმედების კლასის ავტომატური დამტკიცება მხოლოდ მაშინ ჩართეთ, როცა გაზომილი რისკი შეთანხმებულ ზღვარშია; dual-control ან sampling სიმწიფისთვის ეტაპი და გასვლის კრიტერიუმები დააფიქსირეთ საბაზისო კარიბჭის შემსუბუქებამდე.

როგორ იყენებს Northstar HITL-ს

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

FAQ

  • არა. დაამტკიცეთ გარე ან შეუქცევადი მოქმედებები და არა ყოველი შიდა შავი ვერსია. თუ გენერირებული შეტყობინება sandbox-ს ვერ ტოვებს, განხილვა შეიძლება მოგვიანებით შერჩევითა და evals-ით.