ყველა CTO-ს, ვისთანაც ახლა ვსაუბრობ, ბორდი ერთსა და იმავე კითხვას უსვამს: „როგორია ჩვენი AI-სტრატეგია?” და ამის საპასუხოდ დაწერილი სტრატეგიების უმეტესობას საერთო დეფექტი აქვს — ისინი აღწერენ, რისი გაკეთება სურს კომპანიას, და არა იმას, რისი შესრულებაც შეუძლია. ამ ორს შორის უფსკრული გაზომვადია, და გაზომვას დაახლოებით ერთი კვირა სჭირდება. გაზომვამდე დაწერილი სტრატეგია ბიუჯეტიანი ფიქციაა.
ეს პოსტი ის შეფასებაა, რომელსაც მე ვატარებ. ის შეგნებულად თითქმის შეხვედრების გარეშეა: მისი უმეტესი ნაწილი სისტემების კითხვა და ცალკეული ინჟინრებისთვის მოკლე, კონკრეტული კითხვების დასმაა. ქვემოთ მოცემული რუბრიკით თავადაც ჩაატარებთ.
რას ნიშნავს სინამდვილეში „AI-ready”?
ორგანიზაცია AI-სთვის მზადაა, როცა ოთხი რამ სრულდება: მისი მონაცემები მიწვდომადია და საკმარისად სუფთა, რომ მათზე retrieval გააკეთოთ; სულ მცირე რამდენიმე ინჟინერს შეუძლია LLM-ფიჩის აშენება და შეფასება end-to-end; მისი ტულინგი ახერხებს არადეტერმინირებული სისტემის დეპლოისა და დაკვირვებას; და ვიღაცას შეუძლია AI-use-case-ს „არა” უთხრას რეალური უფლებამოსილებით. მზაობა ყოველი ინიციატივის ქვეშ მდებარე იატაკია — სტრატეგია წყვეტს, რა ავაშენოთ, მზაობა წყვეტს, გადარჩება თუ არა რამე პროდუქშენთან შეხებას.
დააკვირდით, რა არ არის სიაში: ვენდორის არჩევანი, მოდელის არჩევანი, პლატფორმა. ეს გადაწყვეტილებები მზაობის დინების ქვემოთაა და მათი შეცვლა უფრო იაფია, ვიდრე ოთხი იატაკიდან ნებისმიერის.
დღე 1–2: შესაძლებელია თუ არა თქვენს მონაცემებზე retrieval?
აიღეთ სამი მონაცემთა წყარო, რომელიც თქვენს ყველაზე სასურველ AI-use-case-ს დასჭირდებოდა, და სცადეთ თითოეულიდან ერთ რეალურ კითხვაზე პასუხის გაცემა — ხელით, არსებული წვდომებით. გაზომეთ, რამდენი დრო დასჭირდა და რამდენ ადამიანს მოგიწიათ კითხვა. თუ ლეგიტიმური წვდომის მქონე ინჟინერს ორი დღე და სამი Slack-თრედი სჭირდება, რომ შეაგროვოს კონტექსტი, რომელიც ფიჩას 200 მილიწამში დასჭირდება, ფიჩი მონაცემების სანტექნიკაზეა დაბლოკილი და არა AI-ზე.
შეაფასეთ პირდაპირ: მწვანე — თუ მონაცემები მიწვდომადია API-ის ან warehouse-ის მეშვეობით დოკუმენტირებული მნიშვნელობით; ყვითელი — თუ მიწვდომადია, მაგრამ მნიშვნელობა ვიღაცის თავში ცხოვრობს; წითელი — თუ თავად წვდომა უკვე პროექტია. ჩემი გამოცდილებით, კომპანიების უმეტესობა, რომლებიც თავს „მონაცემების ოქროს საბადოზე მჯდომად” აღწერს, სამი წყაროდან ორზე წითელს იღებს.
დღე 2–3: გაქვთ თუ არა უნარები, და სად არის ისინი?
თქვენ არ ითვლით „ინჟინრებს, რომლებსაც ChatGPT გამოუყენებიათ”. თქვენ ითვლით ინჟინრებს, რომლებსაც შეუძლიათ retrieval-პაიპლაინის დაპროექტება, აგენტის გარშემო ხელსაწყოების საზღვრების დაყენება და ისეთი eval-ის დაწერა, რომელიც რეგრესიას იჭერს. სთხოვეთ ხუთ სენიორ ინჟინერს, დახაზონ — დაფაზე, ათ წუთში — როგორ ააშენებდნენ თქვენს ყველაზე სასურველ ფიჩას. თქვენ უსმენთ retrieval-ს, კონტექსტის სტრუქტურას, evaluation-სა და ღირებულებას; კონტექსტ-ინჟინერიის ლექსიკონს და არა დემოების ლექსიკონს.
ორი-სამი ინჟინერი, რომელიც ამ ზღვარს გადალახავს, დასაწყებად საკმარისია; ნული ის აღმოჩენაა, რომელიც სტრატეგიას გარდაქმნის — თქვენი პირველი ინიციატივა შესაძლებლობის აშენება ხდება და არა ფიჩის. ეს უკეთესი შედეგია, ვიდრე იმავეს პროექტის შუაში აღმოჩენა, და ეს უფსკრული მიზანმიმართული სწავლებით იხურება (RAG-ისა და აგენტების კურსი ზუსტად ამ პროფილისთვის არსებობს: ძლიერი ინჟინრები, რომლებსაც ჯერ არ აქვთ პროდუქშენ-LLM-გარბენი).
დღე 3–4: უმკლავდება თუ არა თქვენი პროცესი არადეტერმინიზმს?
ტრადიციული მიწოდება ვარაუდობს, რომ ერთი და იგივე შესასვლელი ერთსა და იმავე გამოსავალს იძლევა; LLM-ფიჩები ამ ვარაუდს ამტვრევენ, და სწორედ პროცესში ჩანს ეს მსხვრევა. კითხვა, რომელსაც პასუხი უნდა გაეცეს: როცა AI-ფიჩი პროდუქშენში არასწორად იქცევა, ზუსტად რას შეხედავს თქვენი გუნდი? თუ პასუხი არ არის „თრეისებს, შემდეგ კი ამ მტყუნებას eval-ნაკრებში დავამატებთ”-ის რაღაც ფორმა, თქვენ პროცესის უფსკრული გაქვთ და არა ტულინგის.
აქვე ვეძებ სპეციფიკაციის ჩვევას. გუნდები, რომლებიც აშენებამდე იწერენ, რა უნდა და რა არ უნდა გააკეთოს ფიჩამ, AI-განვითარებას მკვეთრად უფრო სწრაფად ეგუებიან — სპეკი თითქმის მექანიკურად eval-ნაკრებად იქცევა, რაც spec-driven development-ის ბირთვული ციკლია. გუნდები, რომლებიც Slack-თრედებიდან აწვდიან, აღმოაჩენენ, რომ „მოდელი ხანდახან რაღაც უცნაურს აკეთებს” არ არის ბაგ-რეპორტი, რომელზეც ვინმეს მოქმედება შეუძლია. თუ ეს ჩვევა აკლია, მისი აშენება წინაპირობაა და არა სასიამოვნო დანამატი.
დღე 5: ვის შეუძლია თქვას „არა”?
Governance-მზაობა ერთი კითხვაა: დაასახელეთ ადამიანი, რომელსაც შეუძლია AI-use-case-ზე ვეტო დაადოს რისკის საფუძვლით და ეს ვეტო შედგეს. თუ პასუხი კომიტეტია, რომელიც ჯერ არ შეკრებილა, ან თავად CTO მას შემდეგ, რაც პროექტმა უკვე ინერცია აიღო, დაწერეთ წითელი. ყველაფერი დანარჩენი governance-ფრეიმვორკში — გამოყენების პოლიტიკა, რევიუ-გეიტები, მონაცემების საზღვრები — მხოლოდ მაშინ მუშაობს, როცა ვეტო რეალურია.
თანმდევი კითხვა არანაკლებ მეტყველია: დაასახელეთ use case, რომელსაც უკვე უთხარით „არა”. ორგანიზაციები, რომლებსაც ვერცერთის დასახელება არ შეუძლიათ, governance-ს არ ეწეოდნენ — ისინი იმედოვნებდნენ. დაწერილი სტრატეგია სანდოობას იმ „არა”-ებისგან იღებს მემკვიდრეობით, რომლებზეც მითითება შეუძლია.
რუბრიკა ერთ გვერდზე
ეს არის მთელი შეფასება ისეთი ფორმით, რომ ხელმძღვანელობის შეხვედრაზე თან წაიღოთ. შეაფასეთ თითოეული იატაკი გულწრფელად; სასარგებლო სწორედ ის სვეტია, რომელიც არასასიამოვნოა.
| იატაკი | მწვანე | ყვითელი | წითელი |
|---|---|---|---|
| მონაცემების მიწვდომადობა | მიწვდომადია API-ის ან warehouse-ის მეშვეობით, და ველების მნიშვნელობა დოკუმენტირებულია | მიწვდომადია, მაგრამ მნიშვნელობა ერთი ადამიანის თავში ცხოვრობს | წვდომის მიღება თავად არის პროექტი |
| უნარები | სამმა ან მეტმა ინჟინერმა LLM-ფიჩა end-to-end მიიყვანა პროდუქშენამდე და შეაფასა | ერთ ინჟინერს შეუძლია, და მის უკან არავინაა | ვერავინ ხაზავს ათ წუთში retrieval-ს, ხელსაწყოების საზღვრებსა და evals-ს |
| პროცესი | Traces არსებობს, და პროდუქშენის მტყუნებები ახალ eval-ქეისებად იქცევა | ლოგები არსებობს; მათ არავინ კითხულობს, სანამ რამე არ გაფუჭდება | „ის ხანდახან რაღაც უცნაურს აკეთებს” ბაგ-რეპორტად ითვლება |
| Governance | დასახელებულ ადამიანს შეუძლია use case-ზე ვეტოს დადება — და უკვე გაუკეთებია | კომიტეტი ქაღალდზე არსებობს და არასოდეს შეკრებილა | არავის არასოდეს უთქვამს „არა” არცერთ AI-იდეაზე |
გაზომვამდე დაწერილი სტრატეგია ბიუჯეტიანი ფიქციაა. სწორედ ზემოთ მოცემული ქულები აქცევს AI-სტრატეგიას სლაიდიდან თანმიმდევრობად.
როგორ ვაქციოთ ქულა სტრატეგიად
ოთხი იატაკი, თითოეული შეფასებული მწვანედ, ყვითლად ან წითლად — და სტრატეგია თითქმის თავისით იწერება. წითლები პირველი ინიციატივებია; მათ თავზე ფიჩების დაფინანსებას აზრი არ აქვს. ყვითლები ტაიმლაინს პატიოსნად აყალიბებენ. მწვანეები ის ადგილია, საიდანაც მომდევნო ორ კვარტალში ხილული გამარჯვებები უნდა მოვიდეს, რადგან სტრატეგია ხილული გამარჯვებების გარეშე აუდიტორიას კარგავს, რამდენად საფუძვლიანიც არ უნდა იყოს.
დოკუმენტი, რომელიც აქედან გამოდის — ქულები, მტკიცებულებები, თანმიმდევრობა, მფლობელები და პირველი ოთხმოცდაათი დღე — ის არის, რაც ფასილიტირებულ engagement-ად გამიკეთებია კომპანიებისთვის, რომლებსაც გარე სენიორული თვალი და ბორდისთვის სანდო დოკუმენტი სჭირდებათ: ეს არის AI readiness & strategy. მაგრამ ზემოთ მოცემული რუბრიკა მთელი მეთოდია. ჩაატარეთ ის, სანამ სტრატეგიას დაწერთ. ერთი კვირის გაზომვა ჯობია თავდაჯერებული ფიქციის მთელ კვარტალს.
