ცუდი AI agent implementation-ის ღირებულება

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

ცუდი AI agent implementation ინვოისზე ბევრად მეტი ჯდება: რეალური ანგარიშია ინციდენტები ungated მოქმედებებისგან, კვირები მონაცემების დასუფთავებაზე, security debt, მეორე ვენდორი, რომელსაც პირველის reverse-engineering-ში უხდიან, და გუნდი, რომელიც შემდეგ automation-ზე უარს ამბობს. პროექტის ფასი ჩვეულებრივ ყველაზე პატარა ხაზია ledger-ში. ამ ხარჯების უმეტესობა ერთსა და იმავე გამოტოვებულ არტეფაქტებს უბრუნდება: არ არის acceptance test, არ არის approval gates, არ არის logging, არ არის დასახელებული owner.

ხარჯების სრული ledger

ინციდენტების ხარჯები: ხმაურიანი ჩავარდნები

Ungated write წვდომა არის ადგილი, სადაც ხილული კატასტროფები ცხოვრობს. კლასიკური ფორმები: შაბლონიდან ამოვარდნილი შეტყობინება მთელ სიაზე, refund თანხები, რომლებსაც არც ერთი ადამიანი არ დაამტკიცებდა, retry ციკლი, რომელიც დუბლირებულ შეკვეთებს ქმნის, ნაჩქარევი integration, რომელიც token-ს ლოგებში აჟონავს. თითოეული ცალკე გადასატანია; ძვირს მათ სიჩქარე და მოცულობა ხდის - agent ერთსა და იმავე არასწორ call-ს ასობით ჯერ იმეორებს, სანამ პარასკევის საღამოს შეტყობინება მოვა. ამ კლასის ჩავარდნების engineering პატერნები კატალოგიზებულია სტატიაში production agent-ების failure რეჟიმები.

პრევენციის პრიმიტივი მოსაწყენია: human approval gates ყოველ შეუქცევად მოქმედებაზე, სანამ override rate agent-ის მზადყოფნას არ დაამტკიცებს, პლუს caps და idempotency, რომ bug-ი ერთი ცუდი მოქმედება დაჯდეს და არა ხუთასი.

Operational debt: ჩუმი ჩავარდნები

უფრო ჩუმი და ხშირად უფრო დიდი: implementation, რომელიც "მუშაობს", სანამ ირგვლივ ყველაფერს ადეგრადირებს.

• CRM pollution. Agent, რომელიც ოდნავ არასწორ ჩანაწერებს მასშტაბით წერს, წამლავს სეგმენტაციას, პროგნოზირებას და ყველა downstream automation-ს. დასუფთავება ხელითაა და ნელი.
• ხმაურიანი queue-ები. Agent, რომელიც თავისი case-ების ნახევარს ესკალირებს, ქმნის ახალ inbox-ს, რომელიც არავინ დააკომპლექტა. გუნდი ახლა ძველ პროცესს პლუს review პროცესს უშვებს.
• უპატრონო ბოტები. Contractor წავიდა, credentials ყოფილი თანამშრომლის ანგარიშში ცხოვრობს და არავინ იცის, რა გატყდება, თუ გამოირთვება - ამიტომ აგრძელებს მუშაობას, უმეთვალყურეოდ.
• ჩუმი დრეიფი. Evals-ის გარეშე მოდელის განახლება ან prompt-ის შესწორება ხარისხს კვირების განმავლობაში ადეგრადირებს, სანამ ვინმე ჩივილებში პატერნს შეამჩნევს.

ორგანიზაციული ხარჯი: ყველაზე გრძელი კუდი

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

ცუდი implementation-ის ანატომია

ჩავარდნილი პროექტები საოცრად ერთგვაროვანია:

1. Discovery გამოტოვებული ან უფასო. ვენდორმა quote ერთსტრიქონიანი brief-იდან გასცა, ამიტომ scope ვარაუდი იყო.
2. წერილობითი acceptance test არ არის. "წარმატება" მოლაპარაკებადი დარჩა, ამიტომ demo დასრულებულად გამოცხადდა.
3. ავტონომია default-ად. Gates ხახუნად აღიქმებოდა და არა ნდობის აშენების მექანიზმად.
4. არც logging, არც evals. პირველი ინციდენტის შემდეგ ვერავინ უპასუხა კითხვას "რა გააკეთა და რატომ".
5. Handoff არ არის. Docs, runbook და credentials გეგმა "phase two" იყო, phase two კი არასოდეს დამდგარა.
6. Owner არ არის. ბოლო ინვოისის დახურვის შემდეგ სისტემა არავის ეკუთვნოდა.

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

აღდგენის playbook

ცუდი implementation ჩვეულებრივ აღდგენადია სრული rewrite-ის გარეშე. Triage-ის რიგი:

1. შეაკავეთ. Gate-ეთ ან დააპაუზეთ ყველა write მოქმედება, რომელსაც agent ასრულებს. Read-only agent-ები გადაუდებელ ქირურგიას იშვიათად საჭიროებენ.
2. Audit. დახაზეთ, რას აკეთებს სისტემა რეალურად: integrations, credentials, ჩაწერილი მონაცემები, ჩავარდნის წერტილები. ელოდეთ სიურპრიზებს.
3. გაზომეთ. ააშენეთ მინიმალური eval set რეალური case-ებიდან, რომ მიმდინარე ხარისხი დაფიქსირდეს რაიმეს შეცვლამდე.
4. ჯერ ყველაზე რისკიანი გზა გაასწორეთ. Secrets და ფულის path-ები კოსმეტიკამდე.
5. Rewrite შერჩევით. დაიტოვეთ, რაც evals-ს გაივლის; თავიდან ააშენეთ მხოლოდ კრიტიკული path-ები, რომლებიც ვარდება. სრული rewrite-ები გამოუსწორებელი საძირკვლებისთვისაა და არა დაჭრილი სიამაყისთვის.
6. დააყენეთ ownership. Docs, runbook, kill switch და დასახელებული შიდა owner - არტეფაქტები, რომელთა არარსებობამაც ეს არეულობა გამოიწვია.

პრევენციის checklist კონტრაქტისთვის

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

• ფასიან discovery-ს workflow-ის რუკითა და რისკების სიით
• წერილობით acceptance test-ს გავლის ზღვრით, შეთანხმებულს build-მდე
• Gate-ის წესებს, რომლებიც ასახელებს, რომელი მოქმედებები საჭიროებს human approval-ს და ვინ ამტკიცებს
• Logging-ს, რომელსაც წაიკითხავთ, და eval set-ს, რომელიც თქვენ გრჩებათ
• LLM cost შეფასებას რეალურ მოცულობაზე, საკუთარ API key-ებზე
• Handoff პაკეტს: დოკუმენტაცია, runbook, credentials გეგმა, ტრენინგი
• მხარდაჭერის ფანჯარას და დასახელებულ ესკალაციის გზას go-live-ის შემდეგ
• ცალსახა exclusions-ს, რომ scope-ის დავებს საორიენტაციო დოკუმენტი ჰქონდეს

ვენდორი, რომელიც ამათგან სამს ან მეტს ეწინააღმდეგება, ზემოთ მოცემული ledger-ის იაფ ვერსიას გაფასებთ.

როგორ ჯდება Northstar

Northstar ორივე ბოლოზე მუშაობს: fixed pilot-ები gates-ით, acceptance test-ებითა და handoff-ით, რომ ledger არასოდეს გაიხსნას, და rescue უკვე გაჭირვებაში მყოფი სისტემებისთვის vibe-code rescue-ის გავლით. ნებისმიერ შემთხვევაში პირველი ნაბიჯი audit-ია.