Начальная волна модели большой языковой модели (LLM) была сосредоточена на быстрого проектирования — тщательно создавая правильный вопрос или инструкцию, чтобы уговорить желаемый ответ. Разработчики и энтузиасты LLM гордятся умными одноразовыми подсказками, такими как «Вы-эксперт x. do y like z»; и термин «бывший инженер» набрал тягу соответственно. Тем не менее, поскольку приложения LLM-мощности стали более сложными и готовыми к производству, разработчики поняли, что достижение хороших результатов-это больше, чем формулирование умного запроса. Введите контекстную инженерию, более широкий и более мощный подход, который фокусируется на всем, что модель знает и воспринимает, когда он генерирует ответ.
В этой статье представлена контекстная инженерия, объясняет, почему она имеет значение для разработки приложений LLM, и показывает, как она отличается от традиционного быстрого инженерного и извлеченного агентства (RAG).
Что такое контекстная инженерия?
Контекстная инженерия — это дисциплина построения динамических систем, которые обеспечивают LLM всем, что ему нужно для выполнения задачи. Чтобы понять это, важно понимать, что «подсказка» LLM — это не просто одна строка текста, но и целое контекстное окно ввода, которое модель видит, прежде чем производить вывод. Этот контекст включает в себя несколько компонентов за пределами непосредственного вопроса пользователя.
Контекстная инженерия — это дисциплина построения динамических систем, которые обеспечивают LLM всем, что ему нужно для выполнения задачи.
Например, хорошо информированный контекст может охватывать системное сообщение с инструкциями, которые устанавливают роль и правила модели, запрос или команду пользователя, краткое изложение истории разговора или состояния до сих пор, любая долгосрочная память или сохраненные факты, которые ИИ выучил, полученные документы или данные, извлеченные из внешних источников, и даже результаты инструментов или функций, которые может вызвать AI.
Короче говоря, контекстная инженерия рассматривает «все, что модель видит до того, как генерирует ответ» как критический ввод.
Контекстная инженерия включает в себя сборку множества компонентов, включая основную подсказку, память, вывод из тряпичных трубопроводов, вывод из вызова инструмента, четко определенного и структурированного формата вывода и ограждения.
Важно отметить, что контекстная инженерия меняет мышление с простого написания подсказок к проектированию системы. Подсказка, которую вы пишете, становится лишь подмножеством этой системы. Не менее важно то, как вы структурируете и управляете всей вспомогательной информацией. Это включает в себя тщательное внимание к форматированию и управлению ограничениями окна контекста. У LLM есть фиксированный предел токена для ввода, поэтому инженер-контекст должен решить, какая информация наиболее актуальна и как сжимать или усекнуть менее критическое содержание. По сути, контекстная инженерия-это целостный подход, который включает в себя куратор и оптимизацию кратковременной «рабочей памяти» модели каждый раз, когда она вызывается.
Контекстная инженерия против быстрого инженера
Чем контекстный инженер отличается от быстрого инженерного метода, с которыми уже знакомы разработчики? Ключевое отличие — область применения. Обратная техническая инженерия обычно относится к созданию эффективной строки быстрого приглашения, такой как формулирование запроса пользователя и инструкции, чтобы четко направлять модель. Часто это одноразовое, сосредоточенное на «Что сказать модели в любой момент времени».
Контекстная инженерия — это суперсет быстрой инженерии.
Напротив, контекстная инженерия связана с «что модель знает, когда вы это говорите — и почему она должна заботиться». Вместо того, чтобы просто настраивать формулировку единой подсказки, контекстная инженерия учитывает все взаимодействие, в том числе о том, должна ли информация быть включена до и после первичной инструкции, как включить память из предыдущих поворотов и как форматировать полученные факты, среди других факторов. Обратная техническая инженерия происходит в окне контекста, тогда как контекстная инженерия определяет, что заполняет это окно. Таким образом, контекстная инженерия — это суперсет быстрой инженерии.
Еще один способ противопоставить их — это изучение их результатов и долговечности. Обратное инженерное мышление часто приводит к испытанию и ошибке, где вы настраиваете формулировку, запускаете модель и смотрите, улучшается ли выход, повторяя процесс по мере необходимости. Это может дать хороший результат для одного входа, но затем не удастся для немного другого случая, что требует дальнейших корректировок.
Контекстная инженерия, с другой стороны, подчеркивает систематические, повторяемые рамки. Разработав, как контекст генерируется и поддерживается, вы стремитесь к последовательной производительности в различных входах и сценариях. Это скорее архитектурный подход, похожий на архитектуру программного обеспечения, а не писать одну подпрограмму. Это становится решающим для приложений, которые должны обрабатывать случаи краев и различные запросы пользователей, не требуя ручной настройки быстрого настройки каждый раз.
Таким образом, быстрое проектирование включает в себя написание точных и точных инструкций, которые вызывают ожидаемый ответ от LLM. Напротив, контекстная инженерия — это построение всей информационной среды, чтобы модель могла справиться со всем, что происходит. Разработчики обнаруживают, что последнее является основной компетенцией, необходимой для передовых систем, управляемых LLM.
Тряпка против быстрого инженера
Поигрывательный поколение, обычно называемая RAG, объединяет шаг поиска с большой языковой моделью, позволяя авторитетным отрывкам из внешнего хранилища знаний быть извлечены и введены в подсказку непосредственно перед поколением. Это позволяет модели отвечать с актуальными фактами, а не полагаться исключительно на замороженные данные обучения. Паттерн впервые появился в статье 2020 года и в настоящее время является стандартной практикой в таких компаниях, как Microsoft, Google и Nvidia, потому что он основал ответы и резко уменьшает галлюцинации.
RAG становится одним из компонентов, на которые зависит контекстно -инженерию для обоснования ответов в фактических данных.
Контекстная инженерия, по сравнению, является более широким мастерством куратора всего, что видит модель — системные инструкции, история разговора, выходы инструментов и любой извлеченный текст — и расположение этих элементов внутри ограниченного контекста окна так, как модель может использовать. RAG становится одним из компонентов, на которые зависит контекстно -инженерию для обоснования ответов в фактических данных.
RAG решает конкретную проблему, которая обеспечивает точные ответы, когда корпус превышает контекстное окно модели. Тем не менее, его эффективность по -прежнему зависит от контекстной инженерии, чтобы определить, какие фрагменты актуальны, сколько жетонов выделять и где их разместить, чтобы вопрос пользователя оставался заметным. Эксперименты показывают, что если поиск возвращает нерелевантные или повторяющиеся отрывки, эти дополнительные жетоны толпят окно, вытесняют критические подсказки из фокуса и позволяют галлюцинациям ползти, несмотря на использование тряпки.
Разработчики попытались обойти поиск, переходя к длинным контекстным моделям, которые принимают 128 000 токенов или более. Тем не менее, тесты показывают более высокую задержку, увеличение использования памяти графических процессоров и снижение качества после заполнения окна с низкой стоимостью текста. RAG избегает этих затрат, отправляя только несколько отрывков с лучшим рейтингом, хотя он вводит новую инфраструктуру, такую как векторные магазины и ретриверы, которые должны поддерживаться и настроить. Прагматическое руководство заключается в выборе тряпки, когда база знаний больше или более динамична, чем окно контекста, и полагаться на длинный контекст только тогда, когда автономный документ удобно вписывается в предел.
Контекстная инженерия преобразует LLM из простых чат -ботов в мозг за мощными автономными агентами.
Даже при разработке простой тряпичной стеки вы должны решить, как внедрить полученные отрывки. Позиционирование, форматирование и сжатие-это контекстные варианты, которые влияют на окончательную точность.
Короче говоря, RAG — мощная тактика, встроенная в более широкую дисциплину контекстной инженерии. Последний организует поиск наряду с сжатием, памятью, размещением и форматированием, чтобы предоставить точно правильную информацию в правильный момент.
Заключение
Контекстная инженерия преобразует LLM от простых разговорных чат -ботов в мозг за мощными автономными агентами. Сознательно куратор системных инструкций, памяти, полученных знаний, выходов инструментов и ограждений в окне конечного контекста, разработчики предоставляют агентам ситуационную осведомленность, необходимую для рассуждения, определения и действовать автономно по разным задачам.
Дисциплина также обеспечивает соблюдение ограждений, сжимает шум и уравновешивает бюджеты токенов, обеспечивая, чтобы решения оставались заземленными и эффективными во время выполнения. В агентских рабочих процессах, когда вывод одного агента питает другой, последовательный контекст контекста становится протоколом, который сохраняет целостность намерения, снижает распространение ошибок и в конечном итоге повышает сквозную производительность системы, общую надежность и доверие пользователей.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Janakiram MSV является основным аналитиком в Janakiram & Associates и адъюнкт -преподавателем Международного института информационных технологий. Он также является квалифицированным Google Cloud Developer, сертифицированным архитектором решений Amazon, сертифицированным разработчиком Amazon, … Подробнее от Janakiram MSV
