Вопросы на собеседовании: Промпт-инженер

Я использую zero-shot chain-of-thought для многошаговых задач только после того, как прямой промпт показал недостаточную точность на оценке.

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

Промпт не может сделать chain-of-thought приватным, поэтому я запрашиваю только краткие проверяемые артефакты, а показом данных управляет приложение.

• Контракт ответа может разрешать итог, ключевые допущения, ссылки на доказательства и краткую формулу с входными данными, но не полный ход рассуждения.
• Я никогда не помещаю секреты, скрытые политики или учетные данные в контекст модели в надежде, что инструкция не даст их раскрыть.
• Приложение валидирует и фильтрует разрешенные поля ответа, а eval-тесты проверяют правильность, согласованность доказательств и утечки.

Я генерирую несколько вариантов решения и агрегирую нормализованные финальные ответы только тогда, когда измеренный прирост точности оправдывает дополнительные вызовы.

• Число выборок и параметры генерации я настраиваю на development-наборе для конкретной модели и задачи: универсальной температуры или числа от пяти до десяти нет.
• Для точных ответов подходит большинство голосов, а свободный текст требует канонизации, кластеризации или калиброванного судьи с заданной рубрикой.
• Я показываю ничьи, концентрацию голосов, стоимость и задержку, затем подтверждаю конфигурацию на holdout-наборе, поскольку коррелированные выборки создают ложную уверенность.

Я бы сделал выявление допущений обязательным результатом планирования и блокировал выполнение, если неподтвержденное допущение существенно влияет на результат.

• Планировщик разделяет предоставленные факты, выведенные факты, допущения и неизвестные, указывая источник или способ проверки каждого пункта.
• Каждый шаг объявляет предпосылки; отсутствие важных данных приводит к уточнению или проверке, а не к подстановке правдоподобного значения.
• В eval-тестах я удаляю или опровергаю ожидаемые входные данные и проверяю, что план показывает пробел до запуска зависимого действия.

Я использую least-to-most, когда поздние подзадачи действительно зависят от ответов на более простые ранние вопросы.

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

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

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

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

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

Я превращаю конституцию в приоритетные проверяемые принципы и требую назвать нарушенный принцип до переписывания.

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

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

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

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

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

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

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

Я указываю допустимый источник каждого чувствительного или значимого аргумента и запрещаю модели додумывать отсутствующие значения.

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

Жесткие лимиты применяет runtime, а планировщик или исполнитель получает структурированный снимок остатка, нужный для следующего решения.

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

Каждый этап получает одну ответственность, валидируемую входную схему и выходную схему, подготовленную для следующего этапа.

• Этап извлечения возвращает фрагменты источника и поля, а последующий синтез может интерпретировать их, но не создавать отсутствующие доказательства.
• Контракты описывают работу с null, правила уверенности или отказа и исходные входы, которые остаются доступны дальше.
• Я оцениваю этапы по отдельности до проверки всей цепочки, чтобы хороший финальный ответ не скрывал сломанный промежуточный шаг.

Я задаю взаимно различимые критерии маршрутов и выделяю unknown как полноценную метку с четким порогом.

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

Я использую ансамбли для независимого разнообразия, а дебаты только там, где явное оспаривание может выявить конкурирующие допущения.

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

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

• Задачи планирования, расписания с ограничениями и выбор стратегии программы могут выиграть, потому что ветви оцениваются до полного завершения.
• Промпт должен определить генерацию ветвей, представление состояния, оценку для отсечения, глубину и жесткий бюджет расширений.
• Для обычного резюме или извлечения ветвление в основном дублирует текст и повышает стоимость, поэтому лучше прямой или plan-and-solve промпт.

Я бы задал лимит, измеряемый целевым токенизатором, и контракт сохранения, который проверяется по исходному контексту.

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

Я требую цитирование на уровне утверждений и соответствие каждой ссылки фрагменту, который прямо подтверждает это утверждение.

• Формат ответа ставит ID источника сразу после фактического предложения, а не собирает несвязанные ссылки в конце.
• Проверочный проход извлекает каждую пару утверждения и ссылки и помечает полную, частичную, отсутствующую или противоречащую поддержку.
• Я запрещаю ссылки у чистых рекомендаций, если они не зависят от факта из источника, чтобы контракт цитирования сохранял смысл.

Я требую явно показывать существенные конфликты и применять документированную политику приоритета, а не усреднять утверждения или выбирать самый новый текст.

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