Тілдік модельдер және компания деректері: шекара қайдан өтеді
Компания тілдік модельді өнімге немесе процеске енгізуді шешкенде, бірінші сұрақ «қай модель жақсы» емес, «ол қандай деректерді көреді» болуы керек. Жауапқа архитектура, құн және клиенттер мен заңгерлерге не уәде етуге болатыны байланысты. Біз мұны іске қосқаннан кейін емес, жобаны бағалағанға дейін шешеміз.
Модельді қосудың үш тәсілі
Сыртқы провайдер. Сұраныстар модельге API арқылы — тікелей немесе оларды бірнеше провайдер арасында бөлетін шлюз арқылы жіберіледі. Бұл ең жылдам жол әрі ең мықты модельдерге қолжетімділік, бірақ сұраныстағы деректер үшінші тарапқа беріледі. Сондықтан қандай деректер сыныптарын жіберуге болатынын, провайдер сұраныстарды қалай сақтайтынын және оларды оқытуға пайдаланатынын, өңдеу қай аймақта жүретінін және жіберер алдында нені алып тастау немесе иесіздендіру керектігін алдын ала бекітеміз. Сыртқы API пайдаланылса, «деректер компаниядан шықпайды» деп уәде беруге болмайды.
Аймақтық провайдер. Юрисдикция, провайдермен шарт немесе инфрақұрылымдық шекара маңызды болғанда, қажетті елде қолжетімді модельді таңдаймыз. Провайдердің шыққан жері тексерудің орнын баспайды: сақтау және өңдеу шарттарын кез келген басқа провайдердікіндей мұқият оқимыз.
Сіздің серверлеріңіздегі модель. Ашық салмақтары бар модель компанияның GPU-ында орналастырылады, ал сұраныстар оның инфрақұрылымынан шықпайды. Бұл өз жабдығы мен оны пайдалануды талап етеді, ал таңдау өз бетінше орналастыруға болатын модельдермен шектеледі. Прототип үшін модельді жұмыс компьютерінде де іске қосуға болады, бірақ бұл өнеркәсіптік орналастырудың орнын баспайды.
Жобаны бағалауға дейінгі алты сұрақ
- Сыртқы провайдерге қандай деректерді жіберуге болады, ал қандайын — жоқ.
- Сұраныстан нені иесіздендіру, біріктіру немесе алып тастау керек.
- Модель сіздің инфрақұрылымыңызда жұмыс істейтін режим керек пе.
- Модельдің сұраныстары мен жауаптарын кім және қанша уақыт сақтайды.
- Сұраныстардың мазмұнын сақтамай қандай метрикаларды жинауға болады.
- Жоба аяқталғаннан кейін деректер қалай жойылады.
Жауаптар архитектураны анықтайды. Мысалы, шарттарды сыртқы сервистерге жіберуге болмаса, олар бойынша білім қоры векторлық іздеумен және сіздің контурыңыздағы модельмен құрылады — тіпті сыртқы API арзанырақ болса да.
Сапа уәде етілмейді, өлшенеді
Тілдік модельдің сапасы деректерге және міндеттің қалай қойылғанына байланысты, сондықтан метрикаларға алдын ала кепілдік бермейміз. Оның орнына процесіңізден мысалдар жинағын — дұрыс жауаптары бар сұрақтарды, типтік құжаттарды, күрделі жағдайларды — жинап, әр өзгерісті сол бойынша өлшейміз: басқа модельді, жаңа промптты, құжаттар бойынша іздеудің өзге тәсілін. Итерациялар жобаға кіреді, ал тәуекелдер туралы жұмыс басталғанға дейін айтамыз.
Шекаралардағы мінез-құлықты бөлек тексереміз: құжаттарда жауап болмаса модель не айтады, тақырыптан тыс сұрақтарға қалай жауап береді және пайдаланушыға көруге болмайтын нәрсені көрсетпей ме.
Агентке — ең аз құқық
Модель тек жауап беріп қана қоймай, әрекет етсе — тапсырмалар жасаса, CRM-ге жазса, хат жіберсе — деректер шекарасына өкілеттік шекарасы қосылады. Агент тек сценарийге қажетті құқықтарды алады, маңызды әрекеттерді адам растайды, ал әр қадам журналға жазылады. Осылайша қатені салдары арқылы емес, тауып, түзетуге болады.
Неден бастау керек
Ережелері түсінікті, ал нәтижесін тексеру оңай бір процестен. Онда деректермен жұмыс режимін келісіп, мысалдар жинағын құрастырамыз және әсердің бар-жоғын өлшейміз. Тек осыдан кейін енгізуді кеңейтудің мағынасы бар.