Подход «бюджет полезного контекста» решает отдельную продуктовую задачу. Контекстное окно следует рассматривать как ограниченный бюджет внимания: в него включают только сведения, влияющие на решение, и сохраняют происхождение каждого фрагмента.
Рамка «бюджет полезного контекста» отделяет проверяемые решения от стилистических предпочтений.
Исследование Lost in the Middle обнаружило ухудшение качества при размещении релевантной информации в середине длинного контекста. основание
Редакционная схема «бюджет полезного контекста» проверяется на запросах про «обязательные инструкции» и данных конкретного продукта.
Рабочая постановка задачи
Постановка «бюджет полезного контекста» начинается с пользователя и его следующего действия.
Цель «бюджет полезного контекста» связывается с допустимой ошибкой и способом проверки.
Элемент «обязательные инструкции» уточняет границу решения «бюджет полезного контекста».
Действие «измерить фактический состав контекста» превращает эту границу в рабочий артефакт.
Связка «обязательные инструкции — измерить фактический состав контекста» получает владельца и версию.
Элемент «текущий пользовательский запрос» уточняет границу решения «бюджет полезного контекста».
Действие «назначить приоритет каждому блоку» превращает эту границу в рабочий артефакт.
Связка «текущий пользовательский запрос — назначить приоритет каждому блоку» получает владельца и версию.
Элемент «релевантные факты» уточняет границу решения «бюджет полезного контекста».
Действие «удалить повторяющиеся сведения» превращает эту границу в рабочий артефакт.
Связка «релевантные факты — удалить повторяющиеся сведения» получает владельца и версию.
Google публикует отдельные рекомендации по работе с длинным контекстом и составом промпта. основание
Постановка «бюджет полезного контекста» считается готовой после проверки неоднозначностей.
Состав решения и границы компонентов
Модель «бюджет полезного контекста» включает шесть наблюдаемых элементов.
Обязательные инструкции. Этот элемент задаёт часть рамки «бюджет полезного контекста».
Для «обязательные инструкции» выполняется действие «измерить фактический состав контекста».
Проверка «обязательные инструкции» использует критерий «каждый блок имеет назначение».
Текущий пользовательский запрос. Этот элемент задаёт часть рамки «бюджет полезного контекста».
Для «текущий пользовательский запрос» выполняется действие «назначить приоритет каждому блоку».
Проверка «текущий пользовательский запрос» использует критерий «источник фрагмента известен».
Релевантные факты. Этот элемент задаёт часть рамки «бюджет полезного контекста».
Для «релевантные факты» выполняется действие «удалить повторяющиеся сведения».
Проверка «релевантные факты» использует критерий «критические данные не теряются при обрезке».
История диалога. Этот элемент задаёт часть рамки «бюджет полезного контекста».
Для «история диалога» выполняется действие «сжимать историю по правилам».
Проверка «история диалога» использует критерий «длина измеряется до отправки».
Примеры формата. Этот элемент задаёт часть рамки «бюджет полезного контекста».
Для «примеры формата» выполняется действие «размещать критические данные заметно».
Проверка «примеры формата» использует критерий «качество тестируется на длинных входах».
Резерв для ответа. Этот элемент задаёт часть рамки «бюджет полезного контекста».
Для «резерв для ответа» выполняется действие «проверить результат на разной длине».
Проверка «резерв для ответа» использует критерий «резерв ответа учитывается заранее».
Связи элементов «бюджет полезного контекста» сохраняются в технической трассе.
Порядок внедрения и проверки
Процедура «бюджет полезного контекста» меняет один существенный фактор за итерацию.
Шаг 1: измерить фактический состав контекста. Результат шага сохраняется отдельно.
Шаг «измерить фактический состав контекста» проверяет элемент «обязательные инструкции».
Шаг «измерить фактический состав контекста» исключает сбой «передача всего корпуса документов».
Шаг 2: назначить приоритет каждому блоку. Результат шага сохраняется отдельно.
Шаг «назначить приоритет каждому блоку» проверяет элемент «текущий пользовательский запрос».
Шаг «назначить приоритет каждому блоку» исключает сбой «дублирование одной инструкции».
Шаг 3: удалить повторяющиеся сведения. Результат шага сохраняется отдельно.
Шаг «удалить повторяющиеся сведения» проверяет элемент «релевантные факты».
Шаг «удалить повторяющиеся сведения» исключает сбой «устаревшая история диалога».
Шаг 4: сжимать историю по правилам. Результат шага сохраняется отдельно.
Шаг «сжимать историю по правилам» проверяет элемент «история диалога».
Шаг «сжимать историю по правилам» исключает сбой «обрезка без учёта структуры».
Шаг 5: размещать критические данные заметно. Результат шага сохраняется отдельно.
Шаг «размещать критические данные заметно» проверяет элемент «примеры формата».
Шаг «размещать критические данные заметно» исключает сбой «смешение доверенных и недоверенных данных».
Шаг 6: проверить результат на разной длине. Результат шага сохраняется отдельно.
Шаг «проверить результат на разной длине» проверяет элемент «резерв для ответа».
Шаг «проверить результат на разной длине» исключает сбой «передача всего корпуса документов».
OpenAI рекомендует предоставлять релевантный контекст вместо ожидания, что модель восстановит отсутствующие сведения. основание
Итерация «бюджет полезного контекста» завершается решением владельца, а не впечатлением.
Типовые сбои и диагностика
Диагностика «бюджет полезного контекста» начинается с наиболее раннего наблюдаемого сбоя.
Передача всего корпуса документов. Такой дефект относится к «обязательные инструкции».
Сбой «передача всего корпуса документов» воспроизводится через действие «измерить фактический состав контекста».
Исправление «передача всего корпуса документов» проверяется без смены остальных факторов.
Дублирование одной инструкции. Такой дефект относится к «текущий пользовательский запрос».
Сбой «дублирование одной инструкции» воспроизводится через действие «назначить приоритет каждому блоку».
Исправление «дублирование одной инструкции» проверяется без смены остальных факторов.
Устаревшая история диалога. Такой дефект относится к «релевантные факты».
Сбой «устаревшая история диалога» воспроизводится через действие «удалить повторяющиеся сведения».
Исправление «устаревшая история диалога» проверяется без смены остальных факторов.
Обрезка без учёта структуры. Такой дефект относится к «история диалога».
Сбой «обрезка без учёта структуры» воспроизводится через действие «сжимать историю по правилам».
Исправление «обрезка без учёта структуры» проверяется без смены остальных факторов.
Смешение доверенных и недоверенных данных. Такой дефект относится к «примеры формата».
Сбой «смешение доверенных и недоверенных данных» воспроизводится через действие «размещать критические данные заметно».
Исправление «смешение доверенных и недоверенных данных» проверяется без смены остальных факторов.
Разбор «бюджет полезного контекста» не затушёвывает исходный сбой качественным финальным текстом.
Практический пример
Условный сценарий для «бюджет полезного контекста»: Помощник по регламентам получает системные правила, вопрос, три найденных фрагмента и краткую историю; старые реплики заменяются структурированным резюме с указанием нерешённых вопросов.
Пример «бюджет полезного контекста» не описывает опыт конкретной организации.
Сначала «обязательные инструкции» фиксируется через действие «измерить фактический состав контекста».
Затем «обязательные инструкции» проверяется критерием «каждый блок имеет назначение».
Результат по «обязательные инструкции» сравнивается с исходной версией.
Сначала «текущий пользовательский запрос» фиксируется через действие «назначить приоритет каждому блоку».
Затем «текущий пользовательский запрос» проверяется критерием «источник фрагмента известен».
Результат по «текущий пользовательский запрос» сравнивается с исходной версией.
Сначала «релевантные факты» фиксируется через действие «удалить повторяющиеся сведения».
Затем «релевантные факты» проверяется критерием «критические данные не теряются при обрезке».
Результат по «релевантные факты» сравнивается с исходной версией.
Сначала «история диалога» фиксируется через действие «сжимать историю по правилам».
Затем «история диалога» проверяется критерием «длина измеряется до отправки».
Результат по «история диалога» сравнивается с исходной версией.
Неудачный прогон «бюджет полезного контекста» откатывается до повторной диагностики.
Успешный прогон «бюджет полезного контекста» расширяется только после контрольной выборки.
Критерии качества
Качество «бюджет полезного контекста» определяется совокупностью независимых признаков.
Каждый блок имеет назначение. Признак проверяется на элементе «обязательные инструкции».
Критерий «каждый блок имеет назначение» имеет порог и владельца решения.
Доказательство «каждый блок имеет назначение» сохраняется рядом с версией системы.
Источник фрагмента известен. Признак проверяется на элементе «текущий пользовательский запрос».
Критерий «источник фрагмента известен» имеет порог и владельца решения.
Доказательство «источник фрагмента известен» сохраняется рядом с версией системы.
Критические данные не теряются при обрезке. Признак проверяется на элементе «релевантные факты».
Критерий «критические данные не теряются при обрезке» имеет порог и владельца решения.
Доказательство «критические данные не теряются при обрезке» сохраняется рядом с версией системы.
Длина измеряется до отправки. Признак проверяется на элементе «история диалога».
Критерий «длина измеряется до отправки» имеет порог и владельца решения.
Доказательство «длина измеряется до отправки» сохраняется рядом с версией системы.
Качество тестируется на длинных входах. Признак проверяется на элементе «примеры формата».
Критерий «качество тестируется на длинных входах» имеет порог и владельца решения.
Доказательство «качество тестируется на длинных входах» сохраняется рядом с версией системы.
Резерв ответа учитывается заранее. Признак проверяется на элементе «резерв для ответа».
Критерий «резерв ответа учитывается заранее» имеет порог и владельца решения.
Доказательство «резерв ответа учитывается заранее» сохраняется рядом с версией системы.
NIST относит качество и происхождение данных к существенным факторам риска генеративных систем. основание
Выпуск «бюджет полезного контекста» блокируется заранее определёнными критическими дефектами.
Ограничения применимости
Ограничения «бюджет полезного контекста» публикуются рядом с результатами проверки.
Доступная длина зависит от конкретной модели. Ограничение связано с «обязательные инструкции».
Риск «доступная длина зависит от конкретной модели» получает владельца и дату пересмотра.
Вывод по «доступная длина зависит от конкретной модели» не переносится автоматически на другой контекст.
Большое окно не гарантирует устойчивого использования середины. Ограничение связано с «текущий пользовательский запрос».
Риск «большое окно не гарантирует устойчивого использования середины» получает владельца и дату пересмотра.
Вывод по «большое окно не гарантирует устойчивого использования середины» не переносится автоматически на другой контекст.
Сжатие может потерять важные детали. Ограничение связано с «релевантные факты».
Риск «сжатие может потерять важные детали» получает владельца и дату пересмотра.
Вывод по «сжатие может потерять важные детали» не переносится автоматически на другой контекст.
Контекст увеличивает задержку и стоимость. Ограничение связано с «история диалога».
Риск «контекст увеличивает задержку и стоимость» получает владельца и дату пересмотра.
Вывод по «контекст увеличивает задержку и стоимость» не переносится автоматически на другой контекст.
Позиция информации влияет на некоторые задачи. Ограничение связано с «примеры формата».
Риск «позиция информации влияет на некоторые задачи» получает владельца и дату пересмотра.
Вывод по «позиция информации влияет на некоторые задачи» не переносится автоматически на другой контекст.
Рамка «бюджет полезного контекста» не заменяет профильную правовую экспертизу.
Критичное применение «бюджет полезного контекста» требует независимого человеческого контроля.
Вывод
Подход «бюджет полезного контекста» превращает общую рекомендацию в проверяемый контракт.
Элемент «обязательные инструкции» связывается с действием «измерить фактический состав контекста».
Действие «измерить фактический состав контекста» подтверждается критерием «каждый блок имеет назначение».
Элемент «текущий пользовательский запрос» связывается с действием «назначить приоритет каждому блоку».
Действие «назначить приоритет каждому блоку» подтверждается критерием «источник фрагмента известен».
Элемент «релевантные факты» связывается с действием «удалить повторяющиеся сведения».
Действие «удалить повторяющиеся сведения» подтверждается критерием «критические данные не теряются при обрезке».
Главный результат «бюджет полезного контекста» — воспроизводимое продуктовое решение.
Решение «бюджет полезного контекста» показывает основание, ограничение и безопасный следующий шаг.
