Мазмұнға өту
5 мин оқу

Ластанған тест жиынтығы eval-іңізді әлдеқашан бұзды ма?

Тест жиынтығының ластануы LLM ұпайларын асырады. Дереккөздерді, дубликаттарды, шаблондарды және модельдердің парафраздарға тұрақтылығын тексеріңіз.

Ластанған тест жиынтығы eval-іңізді әлдеқашан бұзды ма?

LLM-нің жоғары ұпайы модель сапасы туралы ештеңе айтпайды, егер сіз жалпылауды жаттап танудан ажыратпасаңыз. Тест формулировкалары, жауаптар немесе олардың жақын нұсқалары ашық интернетте, дооқытуға арналған датасетте не командаңыздың промпттарында бұрыннан болған болса, модель тексеруден жадының арқасында өтуі мүмкін. Продакшенде ол басқа құжатты, шарттардың басқа ретін және басқа ерекшелікті көреді, ал көшбасшылар кестесі мұны байқамайды.

Тест жиынтығының ластануын бір ғана дедупликатор арқылы жою мүмкін емес. Дәл көшірмелер сирек кездеседі әрі оларды табу оңай. Қауіптісі басқа: елу тапсырма бір ашық шаблонның негізінде жасалған, синтетикалық генератор шарттардың орнын ауыстырған, ал редактор нысандардың атауларын өзгерткен. Адамға бұл әртүрлі жолдар болып көрінеді. Ал бастапқы бенчмаркті және оның мыңдаған мазмұндама нұсқасын көрген модель үшін бұл бұрыннан таныс бір емтихан.

GPT-4 есебінде OpenAI бағалау деректерімен қиылысуларды бөлек тексеруді сипаттаған. Бұл дұрыс инженерлік әдет, бірақ кез келген сыртқы тестің таза екенін дәлелдемейді: жабық модель жағдайында сыртқы команда оның алдын ала оқытудың толық корпусын көре алмайды. «Proving Test Set Contamination in Black-Box Language Models» жұмысының авторлары қара жәшікке арналған әдістерді дәл осы себептен құрады, өйткені салмақтар мен оқыту деректері көбіне қолжетімсіз.

Ластану мен ағып кету бағалауды әртүрлі бұзады

Ластану модель сіз іске қоспай тұрып бағалау материалын көрген болуы мүмкін дегенді білдіреді. Дереккөз ашық болуы ықтимал: GitHub-репозиторийі, жарыс беті, Hugging Face жиынтығы, дұрыс жауаптары бар талқылау немесе сұрақтары қайта жазылған оқу конспектісі. Мұндай жағдайда компания ішінен кінәлі адам іздеуге міндетті емессіз, бірақ ұпайды жалпылауды таза тексеру деп атауды тоқтатуыңыз керек.

Әзірлеу мен тест арасындағы ағып кету сіздің процестің ішінде болады. Команда тест мысалын few-shot промптқа қосты. Аналитик деректер выгрузкасын белгілеу үшін мердігерге жіберді. Инженер тест қателерін SFT датасетіне қосты. Басшы модель провайдеріне ең қиын он кейсті көрсетіп, кейін сол жолдармен жақсаруды өлшеді. Бұл енді деректердің шығу тегіне қатысты қауіп емес, әзірлеу контурының тікелей ақауы.

Бұл жағдайларды араластырмау керек. Сыртқы ластану кезінде бенчмарк дәлелінің күшін өзгертесіз және тәуелсіз тексерулер қосасыз. Ішкі ағып кету кезінде әсер еткен жазбалар бойынша нәтижені жарамсыз деп танып, деректердің жолын анықтап, қолжетімділіктерді өзгертесіз. «Біз модельді оқытқан жоқпыз» деген сөз тест мысалдары жүйелік промптта немесе модельді қолмен таңдауға арналған жиынтықта болған жағдайды ақтамайды.

«Ағып кету» сөзімен жиі бүркемеленетін үшінші жағдай да бар: қайталанатын шаблон. Модель дәл осы жолды көрмеуі мүмкін, бірақ ондаған мысалда бірдей операция, жауаптардың бірдей бөлінісі және нұсқаудың бірдей стилі қолданылады. Формалды түрде қиылысу жоқ. Іс жүзінде бір дағды шамадан тыс салмақ алады да, қорытынды ұпай тұрақсыз болады.

Бір жоғары ұпай жады мен дағдыны ажыратпайды

Жауапты білетін модель мен тапсырманы шеше алатын модель бірдей жолды шығара алады. Қарапайым accuracy бұл себептерді ажыратпайды. Сондықтан модельден «Сен бұл сұрақты көрдің бе?» деп сұраудың пайдасы жоқ. Оның дереккөздер журналы тексерілмейді, әрі ол өзінің оқыту тарихы туралы сұраққа сенімді түрде қате жауап беруі мүмкін.

Инварианттылықты тексеру қажет. Логикалық тапсырманы сақтаңыз, бірақ жауапқа әсер етпеуі тиіс форманы өзгертіңіз. Шарттардың орнын ауыстырыңыз. Фирмалық атауларды алып тастаңыз. Тұрмыстық сюжетті бейтарап сюжетке ауыстырыңыз. Маңызы жоқ деталь қосыңыз. Жауапты басқа формада қайтаруды сұраңыз. Егер модель бастапқы нұсқаны мінсіз шешіп, балама нұсқада күрт төмендесе, бұл таныстықтың белгісі, бірақ дәлелі емес. Модель сатып алу туралы шешім үшін мұндай сигналдың өзі жеткілікті.

Sainz және авторластарының «NLP Evaluation in trouble» жұмысы ең ауыр жағдай ретінде тест сплитінде оқытып, кейін сол сплитте бағалауды атайды және мәселе ауқымын өлшеу қиын екенін көрсетеді. Практикалық қорытынды академиялық тұжырымнан қарапайым: бір пайызды ғана жарияламаңыз және ол бір ғана нәрсені өлшейтіндей кейіп танытпаңыз.

Әр тапсырма тобы үшін төрт мәнге қараңыз:

  • бастапқы жолдардағы нәтиже;
  • мағынасы балама парафраздардағы нәтиже;
  • сол жұмыс процесіндегі жаңа тапсырмалардағы нәтиже;
  • жауап қана емес, модель сенімділігі де өзгеретін жағдайлардың үлесі.

Бірінші және екінші мән арасындағы алшақтық ашық жиынтықтағы орташа ұпайдан пайдалырақ. Ол бағалаудың мәтіннің сыртқы формасына қаншалықты тәуелді екенін көрсетеді. Екінші және үшінші мән арасындағы алшақтық басқа нәрсені көрсетеді: дағды оқу тапсырмаларына ұқсамайтын, шынайы кіріс құжаттарына ауыса ма.

Чеклист әр жолдың шығу тегінен басталады

Жиынтықты тексеру эмбеддингтерден басталмайды. Алдымен әр жазбаның қайдан шыққанын анықтаңыз. Команда бұл сұраққа жауап бере алмаса, нені бағалап отырғанын білмейді.

Әр жол үшін item_id, source, source_url_or_ticket, created_at, author_or_owner, license_or_access, transformation, cluster_id, answer_owner және release_status өрістері бар тізілім жасаңыз. transformation өрісіне «тазартылды» деп жазбай, нақты әрекетті көрсетіңіз: «ағылшын тілінен аударылды», «редактор парафраздады», «v3 шаблоны бойынша жасалды», «клиент өтінішінен алынды, PII өшірілді».

Содан кейін осы чеклисттен өтіңіз. Ол қысқа, бірақ команда әр тармаққа естелікпен емес, құжатпен жауап беруі керек.

  1. Бастапқы сұрақ немесе оның аудармасы ашық репозиторийде, мақалада, оқу материалында, жарыста немесе жария жиынтықта болған-болмағанын тексеріңіз.
  2. Мысал промпттарға, демонстрациялық сұрауларға, қолмен жасалған тесттерге, SFT-ке, preference-деректеріне және бұрынғы эксперименттер есептеріне түскен-түспегенін тексеріңіз.
  3. Test ішіндегі дәл және дерлік дәл дубликаттарды, сондай-ақ test пен train, dev және қателер жиынтығы арасындағы қиылысуларды табыңыз.
  4. Парафраздар мен синтетикалық нұсқаларды кластерлерге біріктіріп, әр кластердің соңғы метрикадағы салмағын есептеңіз.
  5. Жауап нұсқаның орналасуына, ұзындығына, JSON шаблонына немесе сұрақтағы қайталанатын сөзге қарап болжанатын жолдарды белгілеңіз.

Соңғы тармақты жете бағаламайды. Жауап нұсқалары бар тесттерде дұрыс жауап кейде бір позицияда жиірек тұрады, нақтырақ тұжырымдалады немесе сұрақтағы терминді қайталайды. Бұл алдын ала оқыту ластануы емес, бірақ мұндай ақау дәл сондай жалған ұпай береді: модель қажетті операцияның орнына жанама белгіні үйренеді.

Мәселені тек лицензиямен немесе қолжетімділікпен жабуға тырыспаңыз. Жиынтық сіз үшін жабық болуы мүмкін, бірақ провайдердің оқыту деректерінде әлдеқашан кездесуі ықтимал. Керісінше, ашық жиынтықты регрессия үшін пайдалануға болады, егер оның ашық екенін ашық айтып, жалғыз критерий ретінде қолданбасаңыз және оны жабық тексерумен толықтырсаңыз.

Дәл сәйкестіктерді мұқият оқу емес, скрипт табады

Кестені көзбен оқу анық көшірмелерді жақсы табады, бірақ тыныс белгілерін, Unicode-ты, аударманы және сөз тіркестерінің орнын ауыстыруды нашар байқайды. Төмендегі минималды тексеруді eval жиынтығы жаңарған сайын іске қосқан жөн. Ол нормализациядан кейінгі дәл сәйкестіктерді және таңбалық ұқсастығы жоғары жұптарды іздейді.

import csv
import re
import unicodedata
from difflib import SequenceMatcher
from collections import defaultdict

def normalize(text: str) -> str:
    text = unicodedata.normalize("NFKC", text).lower()
    text = re.sub(r"\s+", " ", text).strip()
    text = re.sub(r"[^\w\s]", "", text)
    return text

def read_items(path: str):
    with open(path, newline="", encoding="utf-8") as f:
        return list(csv.DictReader(f))

train = read_items("train.csv")
test = read_items("test.csv")

train_index = defaultdict(list)
for row in train:
    train_index[normalize(row["prompt"])].append(row["id"])

for test_row in test:
    prompt = normalize(test_row["prompt"])
    if prompt in train_index:
        print({
            "type": "exact_overlap",
            "test_id": test_row["id"],
            "train_ids": train_index[prompt]
        })

    for train_row in train:
        score = SequenceMatcher(
            None, prompt, normalize(train_row["prompt"])
        ).ratio()
        if score >= 0.92:
            print({
                "type": "near_duplicate",
                "test_id": test_row["id"],
                "train_id": train_row["id"],
                "similarity": round(score, 3)
            })

Шығыс жалпы сан емес, жазба түрінде болуы керек:

{'type': 'exact_overlap', 'test_id': 't-041', 'train_ids': ['tr-882']}
{'type': 'near_duplicate', 'test_id': 't-117', 'train_id': 'tr-301', 'similarity': 0.947}

0.92 шегін регламентке енгізіп, оны әмбебап деп ойламаңыз. Қысқа сұрақтар үшін бұл тым дөрекі, ал ұзын заң мәтіндерінде бір ғана ауысқан тіркесі бар көшірмені өткізіп алуы мүмкін. Алғашқы 50 нәтижеңізді алып, оларды адамға «дубликат», «бір шаблон», «кездейсоқ ұқсастық» деп белгілеңіз де, өз мәтін түріңізге арналған шекті таңдаңыз.

Бұл скрипт модельдің алдын ала оқытуындағы ағып кетуді іздемейді. Ол күнделікті, бірақ маңызды жұмысты атқарады: командаңызға өз train жиынтығында кездейсоқ бағалау жүргізуге жол бермейді және бір кейстің ондаған көшірмесінің өзін кең тапсырмалар жиынтығы ретінде көрсетуіне мүмкіндік бермейді. Бұл қазірдің өзінде қисынсыз есептердің басым бөлігін жояды.

Семантикалық іздеу көмектеседі, бірақ үкім шығармайды

Open-weight модельдерін қосыңыз
AI Router-дің жеке инфрақұрылымында Llama 4, Qwen 3, Gemma 4, DeepSeek V3.2 және Phi-5 орналастырылған.

Эмбеддингтер сөздері сәйкес келмейтін жұптарды табады: аударма, шарттардың ауыстырылған реті, қайта жазылған сюжет. Олар қолмен тексеру кезегін жасауға пайдалы. Бірақ екі мәтіннің бір дағдыны өлшейтінін де, модель олардың бірін іске қосылғанға дейін көргенін де дәлелдемейді.

Әр мысал үшін prompt бойынша бөлек және prompt + expected_answer байланысы бойынша бөлек вектор жасаңыз. Екінші индекс маңызды: екі формулировка ұқсас болғанымен, олар әртүрлі шешімді талап етуі мүмкін. Содан кейін test жиынтығын train, dev, SFT деректерімен және локалдық көшірмесі бар болса, ашық дереккөздермен салыстырып, ең жақын көршілерді шығарыңыз. Әр жұппен не істеу керегін адам шешуі тиіс.

Нашар тәжірибе былай көрінеді: команда cosine similarity мәні 0.85-тен жоғарының бәрін өшіріп, жиынтықты таза деп жариялайды. Осылайша тақырыбы ұқсас, бірақ әртүрлі жазбаларды шығарып тастайсыз, қауіпті құрылымдық парафраздарды қалдырасыз және журналдағы іздерді жоғалтасыз. Жақсы тәжірибе ревьюер шешімін сақтайды: keep, merge_cluster, remove_from_test, rewrite, investigate_source.

«How Contaminated Is Your Benchmark?» мақаласының авторлары ықтимал ластануды дооқытуға дейінгі және кейінгі көріністер мінез-құлқының айырмасы арқылы өлшеу тәсілі ретінде Kernel Divergence Score ұсынады. Бұл қызықты зерттеу әдісі, бірақ оған модель мен fine-tuning кезеңіне қолжетімділік қажет. API-моделін таңдау кезінде ол бақылау жиынтығы мен түрлендірілген тапсырмалардың орнын баспайды.

Семантикалық іздеуді сот сараптамасы ретінде көрсетпеңіз. Оның рөлі қарапайым: адам назарын пайдалы жұмсайтын жерлерді табу.

Синтетикалық нұсқалар көбіне басқа біреудің емтиханын сақтап қалады

Командалар синтетиканы ұнатады, өйткені ол көлемді тез ұлғайтады және клиенттің шынайы өтінішін көрсету қажеттігін жояды. Бұл орынды, бірақ көлемді тәуелсіздікпен шатастырмаңыз.

Мынадай ашық тапсырманы елестетіңіз: «Клиент аударымды 18:00-ден кейін қайтаруды сұрады, оператор не істеуі керек?» Генератор жүз нұсқа жасайды: банкті маркетплейске, аударымды қайтарымға, 18:00-ді 17:30-ға, клиенттің аты мен валютаны өзгертеді. Бірақ барлық нұсқа бір формадағы таныс ережені тексеріп тұр. Егер модель бастапқы тапсырманы, құжаттаманы және соған ұқсас көптеген бенчмаркті көрген болса, синтетикалық жиынтық бір сигналды ғана көбейтеді.

Синтетикалық деректерде жолдардың бірегейлігін емес, шешімнің тәуелсіздігін тексеріңіз. Әр шаблон үшін мына үш сұраққа жазбаша жауап беріңіз:

  • орындаушы қандай фактіні немесе шектеуді бөліп алуы керек;
  • нұсқалар арасында не өзгереді және дұрыс жауапты өзгертуі мүмкін;
  • өзгерістен кейін қай қате жол нанымды болуы тиіс.

Егер тек нысанның аты немесе сан өзгерсе, нұсқаны тестке қоспаңыз. Оны жүктемені тексеру, форматты тексеру немесе регрессия жиынтығында қалдырыңыз. Ол пайдалы болуы мүмкін, бірақ модель сапасына деген сенімділікті арттыруға құқығы жоқ.

Тұрақты жауабы бар шаблондар ерекше қауіпті. Мысалы, генератор тапсырмаларды тыйым салынған әрекеттер айналасында құрғандықтан, жағдайлардың 80 пайызында жүйе «операторға жіберу» деп жауап беруі керек делік. Модель қауіпсіз сөзді үйреніп алып, бірде-бір шартты талдамай-ақ жоғары score жинауы мүмкін. Класс бөлінісін тек бүкіл датасет бойынша емес, әр шаблон бойынша есептеңіз.

Қайталанатын формулировкалар бір дағдыға артық дауыс береді

Кандидаттарды бір іске қосу арқылы салыстырыңыз
Бірдей сұрауларды OpenAI-мен үйлесімді модельдерге AI Router бірыңғай API-і арқылы жіберіңіз.

Егер жиырма жазба тек келісімшарт нөмірімен ерекшеленсе, олар жиырма тәуелсіз бақылауға тең емес. Бұл бір сценарийдің жиырма рет қайталануы. Мұндай құрылымдағы орташа accuracy сенімділікті асырып, сирек сценарийлердегі сәтсіздіктерді жасырады.

Кластер тақырып бойынша емес, операция бойынша құрылуы керек. «Сканнан ЖСН-ді шығару», «шоттағы соманы салыстыру» және «келісімшарттағы күнді табу» сұраулары құжат айналымына жатады, бірақ әртүрлі әрекеттерді тексереді. Ал әртүрлі есімдер мен сомалар қолданылған «аударымға лимит бойынша рұқсат бар-жоғын анықта» сұрауларының ережелері мен тұзақтары бірдей болса, көбіне бір кластерге жатады.

Есепте екі нәтиже көрсетіңіз. Біріншісі, жол бойынша есептелгені, нақты қателерді іздеуге қажет. Екіншісі, кластерлік нәтиже: алдымен әр кластер ішіндегі метриканы есептеп, кейін кластерлерді бірдей салмақпен орташалайды. Айырмашылық байқалса, қай ұпайдың «нағыз» екенін талқыламаңыз. Себебін бекітіңіз: бір немесе бірнеше сценарий жиынтықта басым болып тұр.

Маңызды процестер үшін тағы бір кесінді пайдалы: worst-cluster score. Ол жағымсыз, бірақ іскерлік тұрғыдан маңызды сұраққа жауап береді: модель сұраудың қай түрін ең нашар өңдейді? Банкте, healthcare немесе мемлекеттік қызметтерде орташа ұпай сезімтал операциядағы қайталанатын бір сәтсіздіктің орнын толтырмайды.

Dynabench сияқты динамикалық жиынтықтар нақты модель қателесетін, бірақ адам шеше алатын мысалдарға негізделіп жасалды. Идея модельді шексіз айламен ұстауда емес. Мақсат тест әзірлеушілер мен модельдер жаттап үлгерген формада қатып қалмауы.

Шешім үшін жабық, бақылау үшін ашық жиынтық қажет

Eval-ді бір API-ге біріктіріңіз
Бірыңғай OpenAI-мен үйлесімді эндпоинт OpenAI, Anthropic, Google, DeepSeek, xAI және басқа провайдерлерді біріктіреді.

Ашық бенчмарктер пайдалы. Олар регрессияны бақылауға, промпт конфигурацияларын салыстыруға және модельдер арасындағы жалпы айырмашылықтарды көруге ыңғайлы. Бірақ соларға ғана сүйеніп, модель сіздің өтініштеріңізбен, келісімшарттарыңызбен, ішкі ережелеріңізбен немесе жергілікті тілдік контекстпен жұмыс істей алады деп мәлімдеуге болмайды.

Жабық жиынтықтың өте үлкен болуы міндетті емес. Оның сапалы іріктелуі маңызды. Онда шынайы операциялар, белгілі қателердің нұсқалары, жаңа құжаттар, өзара қайшы шарттар және дұрыс жауап жергілікті саясатқа тәуелді жағдайлар болуы керек. Оған бәрін тықпалай бермеңіз. Процеске жауап беруге дайын иесі бар нәрсені ғана қосыңыз.

Қолжетімділіктерді бөліңіз. Промптты өзгертетін әзірлеуші қате класын және жинақталған кері байланысты көре алады, бірақ бастапқы мәтін мен эталонды әрдайым көруі міндетті емес. Әйтпесе бірнеше итерациядан кейін жабық тест формалды оқыту болмаса да, оқу материалына айналады.

LLM-қосымшалары үшін үш қабатты ұстау пайдалы:

  • регрессия мен қайталанатын салыстыруларға арналған ашық жиынтық;
  • жөндеу үшін командаға таныс, бірақ тұлғасы жасырылған кейстері бар жұмыс жиынтығы;
  • шығару туралы шешімге және мерзімді тәуелсіз тексеруге арналған жабық жиынтық.

AI Router бірдей eval-ді OpenAI-мен үйлесімді әртүрлі модельдер арқылы іске қосуды жеңілдетуі мүмкін. Бұл командаға клиент кодын қайта жазбай кандидаттарды салыстыру қажет болғанда пайдалы. Бірақ шлюз жиынтықты сіз үшін тәуелсіз етпейді: мысалдардың шығу тегі, қолжетімділіктер және кластерлік есеп команда жұмысы болып қалады.

Есеп күмәнді жасырып қоймай, көрсетуі керек

Нашар есеп былай дейді: «A моделі 84,2%, B моделі 81,7% алды». Мұндай есептен айырмашылықтың неге негізделгенін, деректердің қайсысы ашық болуы мүмкін екенін және бір типті қанша жазба орташа мәнге кіргенін түсіну мүмкін емес.

Жақсы есеп төрт бөлек блоктан тұрады. Біріншісінде модель нұсқаларын, жүйелік промптты, генерация параметрлерін, іске қосылған күнді және бағалау тәсілін көрсетіңіз. Екіншісінде жиынтықтың шығу тегін, яғни ашық, ішкі, синтетикалық және жабық жазбалардың үлесін көрсетіңіз. Үшіншісінде post-level және cluster-level метрикаларын, сондай-ақ бастапқы нұсқа мен парафраз арасындағы алшақтықты бірге келтіріңіз. Төртіншісінде шығарылған жолдар мен шығару себептерін тізіңіз.

«Контаминация болуы мүмкін» деген сөйлемді төменге жасырып қоймаңыз. Егер ол модель таңдауын өзгерте алса, қорытынды кестенің жанында тұруы керек. Сатып алудан бұрын осы шектеуді көрген басшы оқиғадан кейін әдемі ұпай көрсетіліп, мәселе түсіндірілген басшыға қарағанда пайдалырақ шешім қабылдайды.

Бір әрекеттен бастаңыз: соңғы 100 тест жазбасын алыңыз, кластерлер құрыңыз, әр маңызды кластерге бір балама парафраз жасаңыз да, нәтижені қайта есептеңіз. Егер көшбасшы өзгерсе, сіз жай ғана өкінішті ауытқуды тапқан жоқсыз. Ескі тест модель жұмысына қарағанда тапсырма формасымен таныстықты көбірек өлшегенін анықтадыңыз.

Жиі қойылатын сұрақтар

LLM таңдау үшін ашық бенчмаркті пайдалануға бола ма?

Иә. Деректердің ашық болуы жиынтықты өздігінен пайдасыз етпейді, бірақ нәтиженің мағынасын өзгертеді: сіз модель қабілеті мен оның материалмен бұрын таныс болуының ықтимал әсерін бірге тексересіз. Мұндай жиынтықты регрессия мен конфигурацияларды салыстыру үшін пайдаланыңыз, ал продакшенге шығару туралы шешімді өз міндеттеріңізден тұратын жабық жиынтықпен растаңыз.

Жабық модельдің тест деректерін көргенін қалай дәлелдеуге болады?

Ашық салмақтар үшін алдын ала оқыту корпустарымен белгілі сәйкестіктерді іздеп, датасет тарихын тексеруге болады. API-модель үшін оқыту деректерінің құрамын дәлелдеу әдетте мүмкін емес. Сондықтан мына белгілерді іздеңіз: мәтінді сөзбе-сөз жалғастыру, бұрынғы ашық тапсырмалардағы күрт артықшылық және парафраздан кейін бұл артықшылықтың жоғалуы.

Тест жиынында ұқсас сұрақтар көп болса, не істеу керек?

Алдымен нормализациядан кейінгі дәл дубликаттар мен жауабы бірдей жазбаларды алып тастаңыз. Содан кейін мағынасы бірдей нұсқаларды кластерлерге біріктіріп, соңғы есепте әр кластерден бір өкілді ғана қалдырыңыз. Әйтпесе бір таныс шаблон сізге ондаған дауыс береді.

Синтетикалық жиынтық ластану қаупін азайта ма?

Синтетикалық деректер жаңа фактілерді, жаңа шектеулерді немесе құжаттардың жаңа үйлесімдерін жасағанда пайдалы. Ал генератор ашық тапсырмадағы есімдерді, сөз тәртібін және сандарды ғана өзгерсе, синтетика қорғаныс бола алмайды: модель әр жолды жаттауы міндетті болмаса да, тапсырманың қаңқасын таниды.

LLM бағалауындағы парафраз тесті деген не?

Парафраз тесті дұрыс жауапты сақтай отырып, тапсырманың берілуін өзгертеді: контексті, шарттардың ретін, алаңдататын детальдарды және сұрақ формасын. Модель бастапқы нұсқаға ғана сенімді жауап берсе, оның жоғары ұпайын қолданбалы дағдының таза бағасы деп санауға болмайды.

Ашық бенчмарктен кейін бөлек жабық тест қажет пе?

Иә, егер бұл жиынтық әзірлеу процесінен бөлек сақталып, промпттарға, few-shot мысалдарға, белгілеу файлдарына және команда есептеріне түспесе. Ең дұрысы, оны өнім иесінде немесе тәуелсіз сапа тобында сақтап, тек алдын ала іріктеуден өткен кандидаттарда іске қосу.

Тест жиынтығының ластанғанын қандай метрикалар көрсетеді?

Тек орташа ұпайды емес, бастапқы және түрлендірілген нұсқалар арасындағы алшақтықты, кластерлер бойынша тұрақтылықты және маңызды сценарийлердегі сәтсіздіктер санын салыстырыңыз. Ескі ашық жиынтықта бір пайыздық пунктке озған, бірақ сіздің парафраздарыңызда қателесетін модель шын мәнінде пайдалы жеңіске жеткен жоқ.

Ластану train мен test арасындағы ағып кетуден несімен ерекшеленеді?

Егер ашық деректер алдын ала оқытуға түссе, бұл сіздің командаңыздан болған ағып кету емес, бірақ бенчмарктің ластануы болып қала береді. Ал тест жазбалары сіздің командаңыздың SFT, preference-деректеріне, промпттарына немесе қолмен жетілдіру цикліне түссе, бұл бағалаудың әзірлеу процесіне ағып кетуі. Оны процесс ақауы ретінде талдау керек.

Тест мысалдарының тізілімінде қандай өрістер болуы керек?

Бастапқы мәтінді, нормализацияланған нұсқаны, дереккөзді, жиынтықта пайда болған күнді, кластер идентификаторын және қосу себебін сақтау жеткілікті. Жабық жиынтыққа иесін, рұқсат етілген адамдар тізімін және іске қосу журналын қосыңыз. Әйтпесе жарты жылдан кейін тестіңіздің қашан жабық болудан қалғанын ешкім түсінбейді.

Eval жиынтығын ластануға қаншалықты жиі тексеру керек?

Тексеру модельдерді алғаш рет ауқымды салыстырудан бұрын, жаңа дереккөз қосылғаннан кейін және командадан тыс нәтиже жарияланар алдында пайдалы. Күдікті жоғары ұпайды күтпеңіз: сол уақытқа қарай модель таңдауы, бюджет және жол картасы қате қорытындыға сүйеніп кетуі мүмкін.