Практикум по поиску и проверке оснований ответа

RAG: от поиска документов к проверке ответа

Разберите готовые учебные примеры: потерянное условие, результаты поиска и ответ с неподходящей цитатой. Затем примените проверки к своей системе: проследите путь документа, проверьте вход модели и сравните варианты с повторной сортировкой и без неё по поддержке ответа, времени и стоимости. На готовых метках проверьте, как LLM-судья различает подтверждённые и неподтверждённые ответы.

База → инженерная практика245 минут7 модулей25 вопросов
После курса

Что вы сможете сделать

  1. Различать отсутствие сведений в индексе, пропуск поиска и потерю кандидата при отборе.
  2. Проверять повторную сортировку на фиксированном наборе кандидатов.
  3. Сопоставлять результаты поиска с фактическим входом модели.
  4. Оценивать поддержку утверждений и сравнивать системы в одинаковых условиях.
  5. Отделять релевантность документа от права доступа и различать инструкции приложения и внешний текст.
  6. Проверять LLM-судью по человеческой разметке, разбирать ложные допуски и расхождения при перестановке ответов.
Модуль 1 из 7

1. Проследите путь документа до ответа

RAG дополняет генерацию найденными материалами. В системе с поиском по индексу проследите путь нужных сведений: от индекса через результаты поиска до входа модели.

  • В классической схеме Azure AI Search поиском и передачей результатов модели управляет приложение. Эти этапы можно проверять отдельно.

    Проверить тезис: RAG 01 10

  • Историческая работа RAG 2020 года использовала индекс Wikipedia вместе с генератором. Из её архитектуры нельзя вывести устройство любой современной системы RAG.

    Проверить тезис: RAG 03

  • Для разбора пропуска сохраните версию индекса и запрос. Проверьте сначала наличие нужных сведений, затем их прохождение через результаты поиска и вход модели.

    Проверить тезис: RAG 10

  • Релевантность документа не устанавливает право на чтение. OWASP рекомендует учитывать разрешения в хранилищах векторных представлений и разделять данные и доступ к ним для разных групп пользователей.

    Проверить тезис: RAG 11

  • В описанной Microsoft схеме Azure AI Search приложение добавляет фильтр по идентификаторам пользователя или его групп к каждому поисковому запросу. Так ограничивается доступ к документам; сама строка идентификатора не подтверждает личность или права. Это отдельная схема, не описание встроенных списков контроля доступа.

    Проверить тезис: RAG 12

Модуль 2 из 7

2. Измерьте, находит ли поиск ответ

Сначала оцените результаты поиска, не запуская генерацию. Заранее задайте контрольные вопросы, допустимые ответы и число результатов k. Не требуйте единственного эталонного фрагмента, если ответ содержится и в других.

  • DPR отбирает кандидатов из индексированной коллекции. Сведения, которых в ней нет, этот поиск вернуть не сможет.

    Проверить тезис: RAG 04

  • В метрике DPR вопрос считается успешным, если ответ есть хотя бы в одном из первых k фрагментов. Долю считают по вопросам, а не по числу фрагментов.

    Проверить тезис: RAG 05

  • Поиск по ключевым словам, векторный и гибридный поиск — разные варианты. Их перечисление в документации не определяет победителя на ваших вопросах: сравните результаты на одном корпусе.

    Проверить тезис: RAG 02 · Приёмочное испытание инференса 01

  • RRF объединяет списки по позициям: при равных весах балл документа — сумма 1/(k + r), где k — константа RRF, а r — место, начиная с 1. Учебный пример: списки [А, Б] и [В, Б], k = 60. Б получает 2/62 ≈ 0,03226, А и В — по 1/61 ≈ 0,01639. Б выходит первым; наличие ответа в нём проверяют отдельно.

    Проверить тезис: Гибридный поиск 02 · Повторная сортировка найденных фрагментов 05

  • В Elasticsearch rank_window_size ограничивает число результатов каждого поиска на входе RRF, а size — предельную длину итогового списка. При неизменных входных списках увеличение size не добавит отсутствующий в них фрагмент. Проверьте, на каком этапе он выбыл: при поиске или при ограничении входного окна.

    Проверить тезис: Гибридный поиск 03 · RAG 10

Модуль 3 из 7

3. Проверьте повторную сортировку

Если система повторно оценивает найденные фрагменты, проверьте этот этап отдельно. Он может изменить порядок кандидатов, но при фиксированном входном наборе не восполнит пропуск поиска.

  • В исследовании Nogueira–Cho BERT оценивает релевантность пары «запрос — фрагмент». Это основание для сортировки, а не оценка истинности будущего ответа.

    Проверить тезис: Повторная сортировка найденных фрагментов 01 05

  • В исследованном каскаде BERT получает результаты BM25. Если нужный фрагмент не попал в этот набор, изменение его порядка не добавит фрагмент.

    Проверить тезис: Повторная сортировка найденных фрагментов 02

  • Сравните, какие фрагменты после сортировки получает генератор. Улучшение позиции нужного текста и обоснованность готового ответа проверяйте отдельно.

    Проверить тезис: Повторная сортировка найденных фрагментов 05 · RAG 10

  • В BERT-ранжировщике Nogueira–Cho запрос и один фрагмент подают совместно. Каждая пара получает оценку независимо от остальных; по этим оценкам сортируют фрагменты. Проверяйте вход каждой пары, а не только полный текст найденного документа.

    Проверить тезис: Повторная сортировка найденных фрагментов 03

  • В той же реализации запрос ограничивают 64 токенами, а фрагмент сокращают так, чтобы вся пара со служебными токенами занимала не более 512. Сравните полный найденный текст со входом ранжировщика: сохранилось ли нужное условие? Эти пределы не относятся ко всем ранжировщикам.

    Проверить тезис: Повторная сортировка найденных фрагментов 04 · RAG 10

Модуль 4 из 7

4. Сверьте фактический вход модели

Найденный текст может не дойти до генератора: приложение выбирает фрагменты и укладывает их в доступный объём входа. Проверяйте получившийся запрос, включая инструкции и оформление.

  • В варианте VANILLA из ALCE модели передают первые k найденных фрагментов и просят ссылаться на них. Проверить выдачу поиска недостаточно: нужно увидеть выбранный контекст.

    Проверить тезис: RAG 06 10

  • В фактический вход могут входить системные инструкции, история, текущий вопрос и служебные токены шаблона. Считайте весь переданный набор, а не только найденные документы.

    Проверить тезис: Контекстное окно языковой модели 02

  • В Transformers параметр max_new_tokens ограничивает число новых токенов ответа. Его увеличение не расширяет поддерживаемое контекстное окно модели.

    Проверить тезис: Контекстное окно языковой модели 03

  • Инъекция отклоняет модель от задачи: напрямую через запрос или косвенно через внешний материал, намеренно или случайно. В опытах Greshake и соавторов 2023 года чужие инструкции перенаправляли работу искусственно созданных приложений; для Bing Chat использовали локальные HTML-файлы. Это не оценка частоты успеха на современных системах. Отделяйте внешний текст от инструкций приложения, ограничивайте права модели и обрабатывайте функции приложения кодом. RAG не устраняет уязвимость полностью.

    Проверить тезис: Инъекция промпта 01 02 03 04

Модуль 5 из 7

5. Проверьте основания утверждений

Открывающаяся ссылка ещё не подтверждает содержание ответа. Сопоставьте каждое существенное утверждение с указанными фрагментами, допуская их совместную поддержку. Затем проверьте, нет ли среди ссылок лишних, не участвующих в обосновании.

  • В ALCE совокупность фрагментов может обосновывать утверждение, которое не следует из каждого фрагмента по отдельности. При оценке ссылок также выявляют не относящиеся к обоснованию материалы.

    Проверить тезис: RAG 07

  • RAGAs разделяет поддержку контекстом, соответствие ответа вопросу и релевантность контекста. Ответ по теме ещё не обязательно подтверждён источниками.

    Проверить тезис: RAG 08

  • Автоматический балл — результат проверки моделью-оценщиком. Высокий балл не исключает её ошибки и не устанавливает достоверность исходных материалов.

    Проверить тезис: RAG 09

Модуль 6 из 7

6. Сравните два варианта системы

Выберите одно изменение для проверки. Например, добавьте повторную сортировку, сохранив вопросы, корпус и первичный поиск. Заранее определите, какой результат считаете правильным и какую задержку готовы принять.

  • Для каждой ошибки сохраните результаты поиска, фактический вход и ответ. Так можно увидеть, на каком этапе варианты разошлись.

    Проверить тезис: RAG 10

  • В сравнении с повторной сортировкой и без неё зафиксируйте модель, шаблон, параметры генерации и правила выбора контекста. Сам порядок фрагментов может измениться — это часть проверяемого воздействия.

    Проверить тезис: Приёмочное испытание инференса 01 · Повторная сортировка найденных фрагментов 02

  • Сначала сопоставьте ответы с выбранными критериями качества, затем задержку и затраты. Более быстрый вариант, который перестал решать нужные задачи, не проходит такую приёмку.

    Проверить тезис: Приёмочное испытание инференса 02

Модуль 7 из 7

7. Проверьте LLM-судью на размеченных ответах

Общая доля совпадений не показывает, какие ответы оценщик ошибочно принял или отклонил. Сначала задайте критерий и человеческую разметку, затем проверьте виды ошибок и чувствительность парного решения к порядку.

  • Выберите оценку одного ответа или сравнение пары и решите, нужен ли эталон. Затем зафиксируйте критерий и смысл положительной метки; человеческие разногласия разрешите до сравнения с моделью.

    Проверить тезис: LLM-судья 01 02 · Приёмочное испытание инференса 02

  • Если положительная метка означает «судья принимает ответ как подтверждённый», TP — правильно принятый ответ, FP — ошибочно принятый, TN — правильно отклонённый, FN — ошибочно отклонённый относительно человеческой разметки. Доля ложных допусков среди ответов с отрицательной человеческой меткой (FPR) равна FP/(FP+TN); если таких ответов нет, FPR не определён.

    Проверить тезис: LLM-судья 01 02

  • Учебный пример, не запуск модели: из 20 ответов люди пометили 18 как подтверждённые источником, а 2 — как неподтверждённые. J1 принимает все: TP=18, FP=2, TN=0, FN=0, согласие 18/20=90%, доля ложных допусков FP/(FP+TN)=2/2=100%. J2 принимает 16 из 18 подтверждённых, отклоняет ещё 2 подтверждённых и оба неподтверждённых: TP=16, FP=0, TN=2, FN=2, согласие 18/20=90%, доля ложных допусков 0/2=0%. Равная доля совпадений скрыла разные ошибки.

    Проверить тезис: LLM-судья 02

  • Второй учебный пример: для четырёх пар X/Y прямой показ A=X, B=Y дал [A, A, B, =], обратный A=Y, B=X — [B, A, A, =]. После возврата к именам ответов получаются X/X, X/Y, Y/Y и =/=. Три из четырёх пар согласованы, включая ничью: 75%. Расхождение второй пары — повод для разбора, а повторная ничья не доказывает равноценность.

    Проверить тезис: LLM-судья 03

  • Отделите настройку рубрики от итоговой проверки. Сверьте судью с человеческими решениями на отдельной выборке именно целевой задачи; 20 учебных примеров и оценки, полученные при настройке, не доказывают будущую надёжность или перенос на другой язык.

    Проверить тезис: LLM-судья 04 · Приёмочное испытание инференса 01

  • Поля ниже вымышлены и не задают формат реальной модели. Подтверждайте тезис только тем, что явно записано в источнике: 1) weights_bits=4, поле kv_cache_bits отсутствует; «KV-кэш 4-битный» — сведений недостаточно. 2) weights_bits=4, kv_cache_bits=16; тот же тезис — противоречит записи. 3) те же поля; «веса 4-битные, KV-кэш 16-битный» — поддерживается записью.

    Проверить тезис: RAG 07

  • Дайте участникам одинаковые учебные записи и тезисы для независимой разметки; до сдачи они не обсуждают метки. Сохраните обе исходные метки, а итог разбора и основание запишите отдельно. Если сведений источника не хватает, используйте категорию «источник не позволяет решить». Если спор касается применения самой рубрики, отметьте его отдельно как неразрешённое разногласие, а не как отрицательную метку для FPR.

    Проверить тезис: LLM-судья 05 02

  • Учебный набор: для 10 ответов модель оценила вероятность правильности как 0,8, верны 6; для ещё 10 оценка — 0,6, верны 8. Средняя оценка и общая доля верных ответов равны 0,7, хотя в каждой группе они расходятся. Числа вымышлены.

    Проверить тезис: Калибровка уверенности модели 01

  • Ожидаемая ошибка калибровки (ECE) — сумма по интервалам модулей разности между средней оценкой вероятности и долей верных ответов; каждый модуль умножают на долю примеров интервала в выборке. В примере пять равных интервалов (0; 0,2], (0,2; 0,4], (0,4; 0,6], (0,6; 0,8], (0,8; 1] дают 0,2; два интервала (0; 0,5], (0,5; 1] — 0, поскольку объединяют оценки 0,6 и 0,8. Это не доказывает калибровку распределения.

    Проверить тезис: Калибровка уверенности модели 02

  • Для очереди проверки отдельно оцените, чаще ли ошибаются ответы с низкими вероятностями: совпадение общих средних этого не показывает. Результат такой проверки относится к выбранной задаче.

    Проверить тезис: Калибровка уверенности модели 03

Финишная прямая

Проверьте инженерное мышление

Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.

01Модель пропустила условие из регламента. Команда предлагает заменить её, но не сохранила результаты поиска. Что сначала проверить, чтобы отличить нехватку данных от ошибки генерации?
02Для 50 вопросов поиск вернул по пять фрагментов. В первых пяти результатах ответ есть для 40 вопросов. Какова top-5 retrieval accuracy по определению DPR?
03Нужный фрагмент есть в доступном индексе, но его нет среди 20 результатов первичного поиска. Все 20 без потерь переданы ранжировщику, который не выполняет нового поиска. Как получить пропущенный фрагмент?
04BERT-ранжировщик поставил фрагмент первым. Разработчик предлагает считать будущий ответ достоверным на основании этой оценки. Что на самом деле оценивала описанная модель?
05Нужное условие есть в сохранённой выдаче поиска. Перед генерацией приложение выбирает пять фрагментов и сокращает их текст. Ответ игнорирует условие. Что проверить следующим?
06Ответ утверждает: «В модели Z два отсека, каждый поддерживает накопители формата F». Один указанный фрагмент подтверждает число отсеков, второй — формат для каждого отсека именно модели Z. Других условий в утверждении нет. Как оценить поддержку?
07Автоматическая метрика дала высокий балл подтверждённости ответа контекстом. Редактор ещё не проверял ни ответ, ни источники. Как трактовать результат?
08Команда проверяет, помогает ли повторная сортировка перед генерацией. Вопросы и снимок индекса одинаковы. Какое сравнение лучше отделяет её влияние?
09Ассистент сравнивает оборудование по найденной спецификации. Рядом с характеристиками есть просьба отправить историю диалога на сторонний адрес. Какой шаг помогает оценить риск выполнения этого указания ассистентом?
10В схеме фильтрации Microsoft для Azure AI Search приложение уже установило пользователя и его группы. Для одного ответа оно выполняет основной и уточняющий поиск в том же индексе. Где применять фильтр доступа?
11Учебный пример: текстовый поиск вернул [А, Б, Г], векторный — [Г, В, Б]. RRF использует равные веса и константу k = 60; места начинаются с 1. Кто окажется первым и почему?
12В Elasticsearch нужный фрагмент есть на 12-м месте сохранённого текстового поиска. Векторный поиск его не вернул. На вход RRF из каждого списка поступают первые 10 результатов: rank_window_size = 10, size = 5. Что проверить, чтобы фрагмент мог участвовать в объединении?
13Команда воспроизводит BERT-ранжировщик Nogueira–Cho: один запрос и 20 найденных фрагментов. Разработчик предлагает сохранить отдельный вектор каждого фрагмента и сравнивать его с вектором запроса. Какая схема соответствует описанной работе?
14Учебная упаковка пары для ранжировщика Nogueira–Cho: общий предел 512 токенов, запрос занимает 64, служебные токены — 3; от фрагмента сохраняется только начало. Нужная оговорка начинается с 450-го токена фрагмента. Что следует из этих данных?
15Вымышленный пример. Вопрос: «Можно ли экспортировать данные из E-17?» D1 (устарел): «Экспорт доступен». D2 (актуален): «Экспорт возможен только при permit-export=1». D3 (актуален): «По умолчанию permit-export=0; значение в E-17 неизвестно». Поиск нашёл D1, D2 и D3; модели передали D1 и D3. Ответ: «Экспорт доступен [D1]». Какой вывод об экспорте в E-17 обоснован?
16Вымышленный пример. D1: «У шлюза N два сетевых порта». D2: «У шлюза N только порт 1 поддерживает питание по Ethernet (PoE)». Ответ: «У шлюза N два сетевых порта, оба поддерживают PoE [D1][D2]». Как оценить две части ответа?
17Учебный пример. Для пяти вопросов редактор проверил первые три фрагмента: 1 — фрагмент содержит ответ на этот вопрос, 0 — нет. Q1 [1, 0, 1], Q2 [0, 1, 0], Q3 [0, 0, 0], Q4 [0, 0, 1], Q5 [0, 0, 0]. Какова доля вопросов с ответом хотя бы в одном из первых трёх фрагментов (top-3 в DPR)?
18Учебный пример. Два варианта проверили на одних и тех же 20 вопросах. База: 16/20 ответов целиком подтверждены цитатами, медианное время до полного ответа — 1,8 с, весь прогон — 20 ₽. С сортировкой: 18/20, 2,4 с, 26 ₽. До измерения заданы пороги: поддержка ≥85%, время ≤3 с, весь прогон ≤25 ₽. Какой вариант проходит все пороги в этом прогоне?
19Учебная выборка содержит 20 ответов: 18 подтверждённых людьми и 2 неподтверждённых. J1 принимает все. J2 принимает 16 подтверждённых и отклоняет остальные 4. При положительной метке «ответ подтверждён» какой расчёт верен?
20В учебной проверке четыре пары X/Y показаны прямо A=X, B=Y и обратно A=Y, B=X. Метки прямо: [A, A, B, =]; обратно: [B, A, A, =]. Что следует после сопоставления меток с X и Y?
21Команда настроила рубрику судьи на 20 ответах и получила 90% совпадений. Теперь хочет использовать его для приёмки другой задачи на другом языке. Какой следующий шаг обоснован?
22Условные учебные поля, не формат реальной модели. 1) weights_bits=4, поля kv_cache_bits нет; тезис: «KV-кэш 4-битный». 2) weights_bits=4, kv_cache_bits=16; тот же тезис. 3) Те же поля, тезис: «веса 4-битные, KV-кэш 16-битный». Каковы метки в порядке 1–3?
23В трёх условных кейсах метки A: [недостаточно сведений, противоречит, поддерживается], B: [поддерживается, противоречит, поддерживается]. После обсуждения участники записали общий итог: [недостаточно сведений, противоречит, поддерживается]. Как корректно отчитаться?
24Учебные данные: 10 ответам назначена вероятность правильности 0,8, верны 6; ещё 10 получили 0,6, верны 8. До расчёта заданы границы пяти равных интервалов 0; 0,2; 0,4; 0,6; 0,8; 1, каждый включает правую границу, и двух: (0; 0,5], (0,5; 1]. Каковы средняя оценка вероятности, доля верных ответов и ECE при каждом разбиении?
25В 20 учебных ответах у 10 оценка вероятности правильности 0,8 и верны 6; у остальных 10 оценка 0,6 и верны 8. Средняя оценка вероятности и общая доля верных ответов равны 0,7. Что говорят эти данные о правиле «меньшая оценка — выше риск ошибки»?
Проверяемая база

Источники курса

Полные сведения о первоисточниках приведены один раз для всего курса. Под тезисами — ссылки на соответствующие утверждения Архивариума.

  • Официальная документация

    Retrieval-augmented generation (RAG) in Azure AI Search

    Microsoft Learn · Azure AI Search, раздел Classic RAG pattern, состояние страницы на 2026-10-14

    Открыты раздел Classic RAG pattern и перечень способов поиска. Рекламные сравнения, численные обещания и предварительные возможности не использованы.

    Открыть первоисточник
  • Первичная публикация

    Dense Passage Retrieval for Open-Domain Question Answering

    ACL, EMNLP 2020 · EMNLP 2020, Anthology ID 2020.emnlp-main.550, pp. 6769–6781

    Разделы 2–3: отбор фрагментов и top-k retrieval accuracy. Знаменатель этой метрики — число проверенных вопросов.

    Открыть первоисточник
  • Первичная публикация

    Enabling Large Language Models to Generate Text with Citations

    ACL, EMNLP 2023 · EMNLP 2023, Anthology ID 2023.emnlp-main.398, pp. 6465–6488

    Разделы 2, 3.3 и 4.2: ссылки на фрагменты, проверка их совместной поддержки утверждения и вариант VANILLA. Проверка ссылок не устанавливает независимую истинность источников.

    Открыть первоисточник
  • Первичная публикация

    Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

    NeurIPS 2020 · NeurIPS 2020, volume 33

    Исследовательская архитектура RAG 2020 года. Описание её памяти не переносится на все современные системы с поисковым дополнением.

    Открыть первоисточник
  • Официальная документация

    LLM08:2025 Vector and Embedding Weaknesses

    OWASP Gen AI Security Project · OWASP Top 10 for LLM Applications 2025, LLM08, section Permission and access control

    Раздел «Разрешения и контроль доступа»: права в хранилищах векторных представлений и разделение данных разных групп. Рекомендация, не проверка реализации.

    Открыть первоисточник
  • Официальная документация

    Security filters for trimming results in Azure AI Search

    Microsoft Learn · Страница обновлена 2026-08-24; схема фильтрации результатов по идентификаторам пользователей и групп

    Разделы о схеме фильтрации, поле доступа и фильтре в запросе. Строка идентификатора сама не подтверждает личность или права; фильтр ограничивает выдачу и применяется к каждому запросу. Встроенные списки контроля доступа здесь не рассматриваются.

    Открыть первоисточник
  • Официальная документация

    vLLM online serving benchmark: benchmark_serving.py

    vLLM Project · репозиторий vLLM, тег v0.5.4, страница открыта 7 сентября 2026 года

    Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Клиентские метрики; точные timestamps, chunks и знаменатели проверить в этой версии и её request adapter.

    Открыть первоисточник
  • Официальная документация

    Transformers 4.44.2: Generation

    Hugging Face · документация Hugging Face Transformers v4.44.2, страница открыта 7 сентября 2026 года

    Открыт редактором 7 сентября 2026 года, заголовок документа сверен.

    Открыть первоисточник
  • Официальная документация

    Service Level Objectives

    Google Site Reliability Engineering · Site Reliability Engineering, Chapter 4

    Определяет SLI, SLO и SLA и объясняет user-centric latency, error rate, throughput и percentiles.

    Открыть первоисточник
  • Официальная документация

    Reciprocal rank fusion — Elasticsearch Reference

    Elastic · Rolling documentation read 2026-10-25; formula and RRF retriever parameters

    Прочитаны формула с нумерацией от 1, rank_constant, rank_window_size, size и обрезка kNN-результатов. Числа учебного примера рассчитаны редакцией; запуск Elasticsearch не выполнялся.

    Открыть первоисточник
  • Первичная публикация

    Passage Re-ranking with BERT

    arXiv · arXiv:1901.04085v5, revised 2020-04-14

    Раздел 2 версии v5 перечитан в HTML 25.10.2026: каскад BM25 → BERT, совместный вход запроса и фрагмента, независимая оценка пар и ограничения 64/512 токенов. Числа относятся к этой реализации.

    Открыть первоисточник
  • Официальная документация

    Transformers 4.44.2: Chat templates

    Hugging Face · документация Hugging Face Transformers v4.44.2, страница открыта 7 сентября 2026 года

    Открыт редактором 7 сентября 2026 года, заголовок документа сверен.

    Открыть первоисточник
  • Официальная документация

    LLM01:2025 Prompt Injection

    OWASP Gen AI Security Project · OWASP Top 10 for LLM Applications 2025, LLM01

    Определения прямой и косвенной инъекции, намеренные и ненамеренные случаи, граница защиты через RAG; рекомендации 4 и 6 об ограничении прав и разделении внешнего содержимого. Рекомендации не являются гарантией.

    Открыть первоисточник
  • Первичная публикация

    Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection

    arXiv · arXiv:2302.12173v2, 5 May 2023

    Разделы 3–3.1 описывают косвенное внедрение инструкций; раздел 5.2 ограничивает эксперименты искусственно созданными приложениями и локальными HTML-файлами для Bing Chat. Результаты не переносятся на все современные системы.

    Открыть первоисточник
  • Первичная публикация

    RAGAs: Automated Evaluation of Retrieval Augmented Generation

    ACL, EACL 2024 System Demonstrations · EACL 2024, Anthology ID 2024.eacl-demo.16, pp. 150–158

    Раздел 3: подтверждённость ответа контекстом, соответствие ответа вопросу и релевантность контекста. Автоматическая оценка не заменяет проверку конкретных примеров.

    Открыть первоисточник
  • Первичная публикация

    AWQ: Activation-aware Weight Quantization for On-Device LLM Compression and Acceleration

    Ji Lin и соавторы · arXiv:2306.00978v6, revised 2026-04-25

    Полный PDF v6 перечитан 15.10.2026: §2–3 — квантование весов и шкалы; §4 — упаковка и исполнение; §5 — качество и скорость. Результаты отдельных моделей и устройств не обобщаются; формат KV не следует из разрядности весов.

    Открыть первоисточник
  • Первичная публикация

    Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena

    arXiv · arXiv:2306.05685v4; §§3.1, 3.3–3.4

    Поддерживает режимы оценки, позиционные смещения и смещение в пользу более длинных ответов, а также осторожную обработку расхождений после перестановки ответов. Выводы относятся к исследованным моделям, промптам и задачам.

    Открыть первоисточник
  • Первичная публикация

    Judging the Judges: Evaluating Alignment and Vulnerabilities in LLMs-as-Judges

    Association for Computational Linguistics · GEM 2025, pp. 404–430; §§4–5, appendix F

    Сопоставляет метки судьи с человеческой разметкой, задаёт TP/FP/TN/FN и долю совпадений. Человеческий оценщик здесь выбран как опорная метка, не объявлен безошибочной истиной.

    Открыть первоисточник
  • Первичная публикация

    Large Language Models are not Fair Evaluators

    Association for Computational Linguistics · ACL 2024, pp. 9440–9450; §§2.3.2–2.3.3

    BPC проверяет кандидатов в обеих позициях двумя запусками; HITLC передаёт людям примеры, отобранные по расхождениям автоматических оценок. Методы направлены на позиционное смещение и не дают общей гарантии точности.

    Открыть первоисточник
  • Первичная публикация

    LLMs instead of Human Judges? A Large Scale Empirical Study across 20 NLP Evaluation Tasks

    Association for Computational Linguistics · ACL 2025, Volume 2: Short Papers, pp. 238–255

    Исследует 11 моделей на 20 наборах с человеческими метками; охват ограничен англоязычными наборами и языковыми парами с английским.

    Открыть первоисточник
  • Официальное разъяснение

    Survey Article: Inter-Coder Agreement for Computational Linguistics

    Association for Computational Linguistics · Computational Linguistics, 34(4), 2008, pp. 555–596; §§2.1, 4.1.1

    Обзор: §2.1 уточняет, что согласие само по себе не доказывает валидность; §4.1.1 пересказывает рекомендации Криппендорфа: заранее зафиксировать ясную рубрику, размечать независимо. Обсуждение не заменяет исходные метки; это контекстная рекомендация.

    Открыть первоисточник
  • Первичная публикация

    On Calibration of Modern Neural Networks

    Chuan Guo, Geoff Pleiss, Yu Sun и Kilian Q. Weinberger · ICML 2017, PMLR 70:1321–1330; §2, pp. 1322–1323

    Определение калибровки и расчёт ECE в классификации.

    Открыть первоисточник
  • Первичная публикация

    Can LLMs Express Their Uncertainty? An Empirical Evaluation of Confidence Elicitation in LLMs

    Miao Xiong и соавторы · arXiv:2306.13063v2, 17 марта 2024 года; ICLR 2024; §§4, 5.1, приложение E.2

    Различает калибровку и прогноз ошибок.

    Открыть первоисточник
Подтвердите действие