AI აგენტის შეცდომები ხშირად ძებნის ხარვეზია და არა მოდელის — Anthropic-ის 49% და 67%

აგენტი, რომელსაც გრძელი PDF-ის შეჯამება, API-ის სწორად გამოძახება და მრავალნაბიჯიანი პროცესის შესრულება შეუძლია, მაინც გამოტოვებს პოლიტიკის დოკუმენტში ჩაფლულ დაბრუნების ვადას, აირჩევს არასწორ SKU-ს ან დაივიწყებს ხელსაწყოს შედეგს, რომელიც ათი წამის წინ მიიღო. DEV Community-ზე გამოქვეყნებულ წერილში დეველოპერი ლარს უინსტანდი ამტკიცებს, რომ „აგენტის სისულელის“ უმეტესი ბაგი მსჯელობის კი არა, ძებნის — ანუ წარუმატებელი fetch-ის — შედეგია, და ეს ცვლის იმას, საიდან უნდა დაიწყოს დებაგინგი.

შეცდომა მსჯელობას ჰგავს, მაგრამ არაა

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

Anthropic-ის ციფრები: 49% და 67%

მთავარი არგუმენტი Anthropic-ის Contextual Retrieval-ის კვლევას ეყრდნობა: კონტექსტუალიზებული ჩანკების, სემანტიკური ძებნისა და Contextual BM25-ის კომბინაციით ვერ მოძიებული ფაქტების რაოდენობა 49%-ით მცირდება. Reranking-ის დამატება მაჩვენებელს 67%-მდე აწევს. სტანდარტული RAG — ჩვეულებრივი ჩანკინგი და სუფთა სემანტიკური ძებნა — შედარებად ციფრს არ იძლევა. უინსტანდის სიტყვებით, „აგენტის არასაიმედოობა მოდელის ინტელექტი კი არა, არასაკმარისად აწყობილი retrieval-ია“.

გრძელი კონტექსტი და ვექტორული ძებნა საკმარისი არაა

ორი გავრცელებული ვარაუდი ვერ ძლებს. პირველი: დოკუმენტაციის მთლიანად მოდელისთვის მიცემა არ იძლევა გარანტიას, რომ ის სწორ აბზაცს გამოიყენებს — „Lost in the Middle“ ეფექტის გამო მოდელები ხშირად უარესად მუშაობენ, როცა საჭირო ფაქტი გრძელი პრომპტის შუაშია. მეორე: სუფთა embedding-ძებნა ზარალდება ზუსტ დამთხვევებში — შეკვეთის ID-ები, პოლიტიკის სათაურები, პროდუქტის SKU-ები, სამუშაო პროცესების სახელები, შეცდომის კოდები და ბილეთის ID-ები. ჰიბრიდული retrieval — keyword, semantic და reranking ერთად — რეალურ სისტემებში უფრო საიმედოა.

ჯერ retrieval-ის ფენა გამოიკვლიეთ

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

ბოლო პუნქტი არქიტექტურულია: თუ ცოდნის ბაზა კომფორტულად ეტევა კონტექსტში — დაახლოებით 200 000 ტოკენამდე — Anthropic გვირჩევს RAG-ზე საერთოდ უარი თქვას; ამავე მასალაში ნათქვამია, რომ prompt caching-ი ლატენტურობას ორჯერ მეტად და ღირებულებას 90%-მდე ამცირებს. უინსტანდის წესი მარტივია: როცა აგენტი აშკარა დავალებას ვერ ასრულებს, ჰკითხეთ, რა დააბრუნა retrieval-მა, სად გამოჩნდა ფაქტი, არსებობდა თუ არა exact-match ძებნა, მუშაობდა თუ არა reranking და დაინახა თუ არა აგენტმა სწორი რამ გამოსაყენებელი ფორმით.