სამიზნე აუდიტორია: დეველოპერები, რომლებიც იყენებენ AI პროგრამირების ინსტრუმენტებს (როგორიცაა Cursor, Windsurf, trae...) და ტექნიკური მენეჯერები, რომლებსაც არ აქვთ AI-ს ხარჯების გაცნობიერება.

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

თქვენი „AI ხარჯები“ შეიძლება ხელფასზე მაღალი იყოს

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

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

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

ქვემოთ მოცემული სურათი არის მომხმარებლის „მოხუცი K-ს ყოველდღიური ცხოვრება“ მიერ გადაღებული ეკრანის სურათი, სადაც ჩანს 200 მილიონი ტოკენის მოხმარების ჩანაწერი ერთ დღეში:

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

რას ნიშნავს 100 მილიონი ტოკენი? თუ ვიანგარიშებთ „ზოგიერთი ძირითადი კომერციული მოდელის“ საერთო საანგარიშო დონეს (შეყვანა/გამოტანა ცალ-ცალკე ირიცხება, ერთად უხეშად შეფასებულია 10 აშშ დოლარი / მილიონ ტოკენზე), მაშინ ამ დღეს დაიწვა 1000 დოლარი. ერთ დღეში 7000 იუანის დაწვა. ბევრი დამწყები პროგრამისტის ხელფასი შეიძლება არ იყოს საკმარისი AI-სთვის ამ ერთ დღეს „ფიქრისთვის“.

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

თუ გსურთ თავად გადაამოწმოთ, ზოგადად ეს არის ფორმულა (გამორიცხავს ქეშირებას/ფასდაკლებებს და სხვა სპეციალურ წესებს): ღირებულება ≈ (შეყვანის ტოკენი / 1,000,000) × ფასი_in + (გამოტანის ტოკენი / 1,000,000) × ფასი_out

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

დღეს ყველასთან ერთად ღრმად გავაანალიზებთ ამ „ტოკენის შავი ხვრელის“ ლოგიკას და როგორ შევაჩეროთ ზარალი.

I. რატომ „აფეთქდება ექსპონენციალურად“ ტოკენი?

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

1. გამოვთვალოთ გასაგებად

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

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

• 1 ჩინური სიმბოლო: ჩვეულებრივ 1–2 ტოკენი (მაღალი სიხშირის სიმბოლოები უფრო ახლოსაა 1-თან, იშვიათი სიმბოლოები/კომბინაციები უფრო ადვილად აღწევს 2–3-ს)

• 1 ინგლისური სიტყვა: ჩვეულებრივ დაახლოებით 1.2–1.5 ტოკენი (უხეში შეფასებისთვის შეგიძლიათ გამოიყენოთ 1.3)

• კოდის 1 ხაზი ≈ 10–50 ტოკენი (შეიცავს შეწევას, კომენტარებს, ტიპის დეკლარაციას)

• ლაკონური ბიზნეს ლოგიკა ≈ 12–20 ტოკენი

• ტიპის ანოტაციებით, ინტერფეისით, JSDoc-ით, 4 სივრცის შეწევით ≈ 20–35 ტოკენი

• დიდი რაოდენობით იმპორტით / დეკორატორებით / კომენტარებით ≈ 30–50+ ტოკენი

• 1 საწყისი ფაილი (400–600 ხაზი, თანამედროვე TS/Java პროექტი) ≈ 4,000–24,000 ტოკენი ძალიან ხშირია (მედიანა ≈ 12,000–18,000)

• 1 საშუალო ზომის პროექტი (100–200 საწყისი ფაილი, მხოლოდ src/-ის გათვალისწინებით, node_modules/ / გენერირებული კოდის გარეშე)

• ძირითადი საწყისი კოდის „ერთხელ წაკითხვა“ ხშირად მილიონი ტოკენიდან იწყება

• თუ ტესტებს, კონფიგურაციებს, სკრიპტებს, დამოკიდებულების დეკლარაციებს და ჟურნალებს ერთად ჩავყრით, ათობით მილიონი ტოკენიც არ არის გასაკვირი

დღევანდელი ფრონტენდ პროექტები არის TypeScript, სავსე რთული Interface-ის განმარტებებით; ან Java, რომელსაც აქვს ათობით ხაზი Import. ეს „თარგის კოდი“ რეალურად ტოკენის მკვლელია. საშუალო ზომის პროექტს, თუ აქვს 100 ფაილი, მხოლოდ AI-სთვის „კოდის წაკითხვის“ უფლების მიცემა, სავარაუდოდ, პირდაპირ გაანადგურებს 1 მილიონ ტოკენს.

2. ტოკენის „ზვავის“ ეფექტი

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

LLM-ის მექანიზმი უსახელოა. იმისათვის, რომ AI-ს ახსოვდეს რა თქვით წინა წინადადებაში, სისტემა ჩვეულებრივ აგზავნის „სისტემის მოთხოვნას + ისტორიულ საუბრებს + თქვენს მიერ ციტირებულ ფაილებს/კოდის ფრაგმენტებს + ხელსაწყოების გამოძახების შედეგებს (როგორიცაა საძიებო შედეგები, შეცდომების ჟურნალები)“ ერთად. თქვენ ფიქრობთ, რომ მხოლოდ ერთი რამ იკითხეთ, მაგრამ რეალურად განმეორებით იხდით „მთლიანი კონტექსტის პაკეტში“.

• პირველი რაუნდი: იგზავნება 10 ათასი ტოკენი, AI პასუხობს 1 ათასს.

• მე-2 რაუნდი: იგზავნება (10 ათასი + 1 ათასი + ახალი კითხვა), AI პასუხობს...

• მე-10 რაუნდი: თქვენი კონტექსტი შესაძლოა 200 ათას ტოკენამდე გაიზარდა.

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

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

II. ორი სახის „სიზარმაცე“ ანადგურებს თქვენს საინჟინრო შესაძლებლობებს

კომენტარების განყოფილებაში იმ რამდენიმე „ასი მილიონის ძმასთან“ გადახედვის შემდეგ, აღმოვაჩინე, რომ ტოკენის მკვეთრი ზრდის მიზეზი არა მხოლოდ AI-ს მოხმარების მექანიზმის პრობლემაა, არამედ ადამიანის სიზარმაცესთანაც არის მჭიდრო კავშირში.

ქვემოთ მოცემულია „აზროვნების სიზარმაცის“ ორი ტიპური მაგალითი.

სიზარმაცე პირველი: ხელების დაბანის ტიპი

გაქვთ თუ არა თქვენც ასეთი მენტალიტეტი:

• „ეს ძველი პროექტი ძალიან არეულია, მე ზარმაცი ვარ, რომ ლოგიკას გადავხედო, პირდაპირ AI-ს მივცემ.“

• „Cursor-ს აქვს Agent რეჟიმი, ძალიან კარგია, მივცეთ მას უფლება თავად გამოასწოროს შეცდომა.“

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

• მან წაიკითხა 50 ფაილი (დახარჯა 500 ათასი).

• მან აღმოაჩინა, რომ ციტირებულია utils, შემდეგ წავიდა ინსტრუმენტების კლასების წასაკითხად (დახარჯა 200 ათასი).

• მან სცადა შეცვლა, შეცდომა დაუშვა, წაიკითხა შეცდომის ჟურნალი (დახარჯა 100 ათასი).

• მან სცადა გამოსწორება, ისევ შეცდომა დაუშვა...

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

უფრო პროფესიონალურად რომ ვთქვათ, აქ არის ორი ფენა ზარალი:

• ღირებულების ფენა: შეყვანის ტოკენი იზრდება, გამეორებების რაოდენობა იზრდება და ხარჯები ხაზობრივად ემატება

• საინჟინრო ფენა: თქვენ კარგავთ კონტექსტს და გადაწყვეტილების მიღების უფლებას და ბოლოს რჩებით უკონტროლო სისტემასთან, რომელიც „უბრალოდ მუშაობს“

სიზარმაცე მეორე: ყველაფერი ერთად

როდესაც შეცდომას წააწყდებით, როგორ აგდებთ მას AI-ს? პირდაპირ აკოპირებთ მთელ შეცდომის კონსოლს Ctrl+A-ით, თუ პირდაპირ @Codebase-ს აძლევთ AI-ს უფლებას თავად მოძებნოს?

ამას ჰქვია „ყველაფერი ერთად“. თქვენ ზარმაცი ხართ, რომ იპოვოთ პრობლემის ბირთვი, ზარმაცი ხართ, რომ გაფილტროთ კოდის ძირითადი ფრაგმენტები. თქვენ AI-ს აძლევთ ინფორმაციის 99%-ს (ხმაურს) და ინფორმაციის 1%-ს (სიგნალს) ერთად.

AI გამაძლიერებელივითაა.

• თქვენ აძლევთ მას მკაფიო ლოგიკას (სიგნალს), ის აძლიერებს თქვენს სიბრძნეს, ტოკენი ნაკლებად გამოიყენება და ეფექტი კარგია.

• თქვენ აძლევთ მას არეულობას და ბუნდოვანებას, ის აძლიერებს თქვენს არეულობას, ტოკენი გიჟურად იზრდება და წარმოქმნის ნაგავს.

III. გადაწყვეტა: როგორ გამოვიყენოთ AI ეფექტურად და შევამციროთ ტოკენის მოხმარება

თქვენი საფულის დასაცავად, უფრო მნიშვნელოვანია თქვენი საინჟინრო კონტროლის დაცვა, ჩვენ უნდა შევცვალოთ AI-სთან თანამშრომლობის რეჟიმი.

1. მინიმალური კონტექსტის პრინციპი

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

Cursor-ში კარგად გამოიყენეთ ეს ოპერატორები:

• @File: ციტირება მხოლოდ შესაბამის ფაილებზე და არა მთელ საქაღალდეზე.

• Ctrl+L** კოდის არჩევა**: Chat-ში გაგზავნეთ მხოლოდ კურსორის მიერ არჩეული 50 ხაზი კოდი და არა მთელი ფაილი.

• @Docs: მესამე მხარის ბიბლიოთეკებისთვის ციტირება დოკუმენტაციაზე და ნუ აიძულებთ მას გამოცნობას.

ეს არის სტრუქტურირებული, განმეორებადი SOP, რომელსაც ხშირად ვიყენებ (თუ ამას გააკეთებთ, ტოკენი შესამჩნევად დაეცემა):

ეს სიტყვები ნიშნავს: AI-სთან თანამშრომლობისას ყურადღება უნდა მიაქციოთ ეფექტურობას და სიზუსტეს. კონკრეტული მიდგომა შემდეგია:

• პირველ რიგში, განვსაზღვროთ მიზანი: მოკლედ და ლაკონურად ვუთხრათ AI-ს მიმდინარე პრობლემა და სასურველი შედეგი, ნუ აიძულებთ მას გამოცნობას.

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

• მიაწოდეთ მინიმალური საჭირო ინფორმაცია: მიეცით მხოლოდ 1-3 შესაბამისი ფაილი, ძირითადი ფუნქციები და შეცდომების დასტას პირველი რამდენიმე ხაზი და არა სრული ინფორმაცია.

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

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

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

2. ასევე ყველაზე მნიშვნელოვანი: ჯერ იფიქრეთ, შემდეგ მოითხოვეთ, ჯერ დაგეგმეთ, შემდეგ იმოქმედეთ

Enter-ის დაჭერამდე აიძულეთ თავი გაჩერდეთ 10 წამით და დაუსვით საკუთარ თავს სამი კითხვა:

• რა პრობლემას ვაგვარებ? (საზღვრების განსაზღვრა)

• რომელ ძირითად მოდულებს ეხება ეს პრობლემა? (კონტექსტის გაფილტვრა)

• თუ მე თვითონ დავწერდი, როგორ დავწერდი? (იდეების მიწოდება)

თქვენ ხართ 1, AI არის 0 მის უკან. თუ 1 ვერ დგას, მაშინ მის უკან რაც არ უნდა ბევრი 0 იყოს, ეს მხოლოდ უაზრო მოხმარებაა.

რამდენიმე გულწრფელი სიტყვა

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

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

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