Dauguma DI projektų nepavyksta ne dėl to, kad modelis buvo netinkamas. Jie nepavyksta, nes komanda pasirinko netinkamo tipo sprendimą savo problemai: nusipirko universalų įrankį užduočiai, kuriai reikėjo pritaikymo, kūrė individualų sprendimą tada, kai puikiai būtų tikęs paruoštas produktas, arba tobulino (fine-tuning) modelį, kai iš tikrųjų problema buvo ta, kad jam reikėjo naujesnės informacijos, o ne kitokio elgesio stiliaus.
Prieš pradėdami planuoti biudžetą ar inžinierių darbo laiką, paklauskite savęs kelių klausimų. Jie neišspręs visų ribinių atvejų, tačiau leidžia išspręsti daugumą „pirkti ar kurti” diskusijų, kuriose įstringa mūsų klientai.
Pradėkite nuo sprendimo: ar tai informacijos, ar elgesio problema?
Prieš pereidami prie visos sprendimų medžio schemos, užduokite vieną greitą klausimą. Ar DI nesusidoroja, nes jam trūksta žinių (jam reikia prieigos prie tinkamo dokumento, įrašo ar duomenų taško), ar nes jis elgiasi ne taip, kaip norite (netinkamas tonas, netinkamas formatas, nenuoseklus struktūrizavimas)? Žinių problemos kreipia į paieška pagrįstus (retrieval) sprendimus. Elgesio problemos kreipia į modelio tobulinimą (fine-tuning) arba tikslesnius nurodymus (prompting). Turėkite šį skirtumą omenyje peržiūrėdami toliau pateiktus klausimus, nes tai dažniausiai praleidžiamas aspektas.
Sprendimų medis: šeši klausimai
1. Ar yra paruoštas DI produktas, kuris jau atitinka 70-80 % jūsų poreikių?
Jei taip, pirkite jį. Tai tinka paprastoms, tiksliai apibrėžtoms užduotims, kai greitis svarbesnis nei tobulas atitikimas, o retos klaidos kaina yra nedidelė: pagalbos užklausų rūšiavimui, susitikimų užrašams, pirminei paieškai, vidiniams klausimams ir atsakymams (Q&A) apie neslaptus dalykus. Kurti savo versiją jau išspręstai problemai neduoda strateginio pranašumo.
2. Ar tikroji problema susijusi su procesu ir integracija, o ne su žiniomis?
Jei modelis jau žino pakankamai, tačiau aplink jį sukurta darbo eiga yra sugedusi, pritaikykite darbo eigos sluoksnį, o ne patį modelį. Dažnas pavyzdys: pardavimo skambutis teisingai apibendrinamas, tačiau niekas nesusiejo tos santraukos su laukais, kuriuos jūsų CRM sistema turi užpildyti. Tai nėra DI problema, tai integracijos problema, ir ją paprastai išspręsti pigiau, nei žmonės mano.
3. Ar kiekvienas atsakymas turi tiksliai atitikti aktualius dokumentus ir turėti nurodytus šaltinius?
Jei tikslumas ir atsekamumas svarbūs, o jūsų šaltinių medžiaga keičiasi dažnai, diekite paieška papildytą generavimą (RAG), o ne bandykite žinias sudėti tiesiai į modelį. RAG modelį laiko pagrįstą jūsų tikraisiais, aktualiais dokumentais ir leidžia parodyti, iš kur atsakymas atsirado, o tai svarbu visur, kur reikalingas audito pėdsakas: politikos asistentams, atitikties klausimams ir atsakymams, vidinės dokumentacijos paieškai.
4. Ar modeliui reikia nuoseklaus tono ar formato, taikomo tūkstančius kartų?
Tik jei atsakymas akivaizdžiai teigiamas, verta apsvarstyti modelio tobulinimą (fine-tuning), ir net tuomet tai turėtų būti vėlesnio etapo optimizavimas, o ne pirmasis žingsnis. Fine-tuning retai yra tinkamas pasirinkimas pirmajame projekto etape. Jį teisingai atlikti yra brangu, jis pririša jus prie konkrečios modelio versijos ir sprendžia siauresnę problemą (nuoseklų stilių ir struktūrą), nei dauguma komandų iš pradžių tikisi. Jei jūsų tikroji problema yra pasenusi informacija, fine-tuning jos neišspręs, tai padarys RAG.
Vizualiai pavaizduoti, šeši klausimai susijungia į vieną schemą, kurią galite peržiūrėti per kelias minutes:
Keturios galimybės vienoje vietoje
1 galimybė: pirkti paruoštą sprendimą
Geriausiai tinka paprastoms, gerai suprantamoms užduotims, kurias jau atlieka universalus įrankis. Greitai įdiegiamas, nedidelės pradinės išlaidos, minimalus pritaikymas. Kompromisas tas, kad priimate tai, ką pardavėjas sukūrė vidutiniam klientui, o ne pritaikytą jūsų konkrečiai darbo eigai.
2 galimybė: pritaikyti darbo eigos sluoksnį
Geriausiai tinka, kai modelio rezultatai yra tvarkingi, tačiau jį supantys procesai netvarkingi. Tai dažnai pigiausias sprendimas iš visų, nes visai nekeičiate DI, tik sumažinate atotrūkį tarp to, ką jis sukuria, ir to, ko reikia jūsų sistemoms.
3 galimybė: diegti RAG
Geriausiai tinka, kai svarbūs tikslumas, informacijos aktualumas ir atsekamumas, o jūsų žinių bazė keičiasi reguliariai. RAG leidžia atnaujinti pagrindinius dokumentus, nereikalaujant iš naujo apmokyti modelio, todėl priežiūros išlaidos išlieka nuspėjamos.
4 galimybė: tobulinti modelį (fine-tuning) atsargiai
Geriausiai tinka, kai turite tūkstančius panašių pavyzdžių ir reikia griežto, pasikartojančio formatavimo ar tono, pavyzdžiui, masiškai generuojant produktų aprašymus pagal fiksuotą struktūrą. Vertinkite tai kaip tobulinimo žingsnį, kai pagrindai jau veikia, o ne kaip pradžios tašką.
Kur komandos dažniausiai suklysta
Klaidos, kurias matome dažniausiai, nėra techninės, tai netinkamas pasirinkimas: nusipirktas universalus įrankis, kai užduočiai iš tikrųjų reikėjo pritaikymo, pasirinktas fine-tuning, kai problema buvo pasenusi informacija, kurią būtų išsprendęs RAG, arba nuo nulio sukurta individuali sistema, kai esamas produktas dengė didžiąją dalį poreikio. Kiekvieną iš šių klaidų brangu atitaisyti, nes kol tampa akivaizdu, kad pasirinkimas netinkamas, aplink jį jau būna sukurta darbo eiga.
Apibendrinant
Jei DI vertinate kaip greitą pataisymą, ilgainiui jis dažniausiai kainuoja daugiau, dėl pakartotinio testavimo, taisymų ir palaipsniui mažėjančio pasitikėjimo rezultatais. Jei jį vertinate kaip gebėjimą, kurį reikia pritaikyti tikrajai problemos formai, jis pradeda veikti kaip tikra sistemos dalis, o ne kaip prisegtas eksperimentas.
Jei nesate tikri, kuri iš keturių galimybių tinka jūsų situacijai, tai geras momentas pasitelkti pašalinę nuomonę. Susisiekite su mūsų komanda ir padėsime jums įvertinti problemą, kol dar neišsirinkote savo sprendimo.