Наши подходы к спецификации модели

В OpenAI мы убеждены: ИИ должен быть справедливым, безопасным и общедоступным, чтобы как можно больше людей могли использовать его для решения сложных задач, создания новых возможностей и прогресса в медицине, науке, образовании, работе и повседневной жизни. Мы верим, что демократизация доступа к ИИ — это лучший путь вперед: нам нужен не ИИ, выгоды и контроль над которым сосредоточены в руках немногих, а технология, которую больше людей смогут использовать, понимать и помогать формировать.

Это одна из главных причин существования спецификации модели OpenAI. Спецификация модели⁠(открывается в новом окне) — это наша формальная основа, определяющая поведение модели. Она определяет, как мы хотим, чтобы модели следовали инструкциям, разрешали конфликты, уважали свободу пользователя и вели себя безопасно в невероятно широком спектре запросов, с которыми пользователи ежедневно к ним обращаются. В более широком смысле это наша попытка сделать целевое поведение модели явным: не только внутри процесса обучения, но и в форме, которую пользователи, разработчики, исследователи, политики и широкая общественность смогут прочитать, изучить и обсудить.

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

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

Спецификация модели OpenAI — это часть более широкого подхода OpenAI к безопасному и подотчетному ИИ. В то время как Программа готовности⁠ фокусируется на рисках, связанных с передовыми возможностями моделей, и мерах предосторожности при их росте, спецификация модели отвечает на иной, дополняющий вопрос: как наши модели должны вести себя в самых разных ситуациях. Если рассматривать картину еще шире, концепция устойчивости к ИИ (AI resilience) направлена на решение глобального общественного вызова: помочь человечеству извлечь выгоду из продвинутого ИИ, одновременно снижая риски и потрясения по мере внедрения всё более мощных систем. В совокупности эти инициативы призваны сделать переход к AGI постепенным, итеративным и понятным для общества: дать людям и институтам время на адаптацию, создавая при этом механизмы защиты, подотчетности и общественного понимания, необходимые для того, чтобы мощный ИИ соответствовал интересам человека.

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

С момента выхода первой версии в 2024 году спецификация модели существенно эволюционировала: мы лучше узнали предпочтения пользователей, расширили охват возможностей ИИ и учли общественные отзывы. Следуя принципу итеративного внедрения⁠, спецификация модели остается живым документом, который сочетает в себе базовые ценности и четкие, понятные правила, а также процесс их изменения на основе реального опыта эксплуатации. Мы также инвестируем в механизмы общественной обратной связи, такие как коллективное согласование⁠, чтобы человечество сохраняло контроль над тем, как используется ИИ и как формируется его поведение.

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

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

Спецификация модели OpenAI начинается с общего замысла: четкого объяснения того, что мы пытаемся оптимизировать на уровне системы и почему.

Данная преамбула определяет три стратегические цели нашей работы:

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

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

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

Мы считаем этот баланс оптимальным, поскольку ценим самостоятельность человека и свободу мысли. Если бы мы обучали модели решать, каким инструкциям следовать, исходя из нашего собственного представления о том, что полезно для общества, OpenAI оказалась бы в положении арбитра в вопросах морали на очень широком уровне. Тем не менее, преамбула всё равно важна. Если возникает неоднозначность в том, как применять спецификацию модели, преамбула должна помочь её устранить.

Спецификация модели также содержит публичные обязательства, которые выходят за рамки непосредственно измеримого поведения модели и охватывают цели обучения и ограничения на развертывание. Например, наши принципы «красные линии»⁠(открывается в новом окне) включают обязательство о том, что в собственных продуктах (таких как ChatGPT) мы никогда не будем использовать системные сообщения для намеренного подрыва объективности⁠(открывается в новом окне) или связанных с ней принципов. А пункт «Никаких других целей»⁠(открывается в новом окне) фиксирует наше намерение оптимизировать ответы модели для пользы пользователя, а не ради выручки или не приносящего пользы времени, проведенного на сайте.

В основе спецификации модели лежит цепочка подчинения (the Chain of Command): структура, определяющая, какие инструкции должны применяться в конкретной ситуации. В ней также рассматривается, как модель должна обрабатывать недостаточно конкретизированные инструкции, особенно в агентных сценариях, где от нее ожидается, что она будет самостоятельно дополнять недостающие детали, тщательно контролируя последствия в реальном мире.

Основная идея, лежащая в основе определения того, какие инструкции следует применять, проста. Инструкции могут поступать из разных источников, включая OpenAI, разработчиков и пользователей. Эти инструкции могут конфликтовать. Цепочка подчинения объясняет, как модель должна разрешать эти конфликты.  

Каждой политике спецификации модели и каждой инструкции присваивается уровень авторитетности⁠(открывается в новом окне). Модели предписано отдавать приоритет букве и духу инструкций более высокого уровня при возникновении конфликтов. Если пользователь просит помочь изготовить бомбу, модель должна отдавать приоритет строгим границам безопасности⁠(открывается в новом окне). Если же пользователь просит подшутить над ним (roast), модель, как правило, должна поставить этот запрос выше собственного правила против оскорблений⁠(открывается в новом окне), имеющего более низкий приоритет в спецификации.

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

• Жесткие правила — это четкие границы, которые не могут быть изменены пользователями или разработчиками (в терминологии спецификации это инструкции уровня «корня» (root) или «системы» (system). Они в основном носят запретительный характер, требуя от моделей избегать поведения, которое может способствовать возникновению катастрофических рисков или причинению прямого физического вреда, нарушать законы или подрывать цепочку подчинения. Мы ожидаем, что ИИ станет фундаментальной технологией для общества, аналогичной базовой интернет-инфраструктуре, поэтому вводим правила, ограничивающие интеллектуальную свободу, только тогда, когда считаем их необходимыми для всего круга взаимодействующих с ним людей. Раздел спецификации «Оставаться в рамках» (Stay in bounds)⁠(открывается в новом окне) содержит жесткие правила, касающиеся конкретных рисков безопасности в реальном мире, а «Принципы для лиц моложе 18 лет» (Under-18 Principles)⁠(открывается в новом окне) накладывают дополнительные защитные меры для несовершеннолетних.
• Настройки по умолчанию — это изменяемые отправные точки: поведение ассистента «по умолчанию», когда пользователь или разработчик не указали свои предпочтения. Мы используем настройки по умолчанию, чтобы сделать поведение предсказуемым и управляемым при масштабировании, чтобы люди могли заранее понимать, что произойдет, не создавая каждый раз специальный набор инструкций. Эти настройки сохраняют управляемость: пользователи и разработчики могут явно задавать тон, глубину, формат и даже точку зрения в пределах границ безопасности. Дефолтные настройки уровня рекомендаций (например, тон или стиль) спроектированы так, чтобы ими можно было неявно управлять, тогда как значения по умолчанию пользовательского уровня (например, правдивость и объективность) служат основой доверия и предсказуемости и могут быть переопределены только явными инструкциями. Они не должны незаметно меняться в зависимости от «атмосферы» диалога; если пользователю нужна иная фактическая позиция, явное указание на это делает такой переход прозрачным и понятным. Эти принципы отражены в разделах «Совместный поиск истины» (Seek the truth together)⁠(открывается в новом окне), «Делать работу наилучшим образом» (Do the best work)⁠(открывается в новом окне) и «Использовать подходящий стиль» (Use appropriate style)⁠(открывается в новом окне), включая нормы, касающиеся честности и объективности, недопущения поддакивания, а также нормы взаимодействия, такие как прямота и уместные в конкретном контексте доброжелательность и профессионализм.

Помимо самой иерархии, спецификация модели использует средства интерпретации, которые помогают моделям (и людям) последовательно применять её в неоднозначных случаях. Эти средства включают: 

• Критерии принятия решений, которые помогают модели делать последовательный выбор в неоднозначных ситуациях, не претендуя на наличие единого механического правила. Например, руководство Спецификации по контролю побочных эффектов⁠(открывается в новом окне) содержит такие рекомендации, как минимизация необратимых действий, соразмерность действий поставленной задаче, уменьшение числа неприятных сюрпризов и предпочтение обратимых подходов — всё это должно быть сбалансировано с другими целями, такими как быстрое и эффективное выполнение задачи.
• Конкретные примеры, которые показывают, как принцип следует применять на практике. Это короткие примеры в формате «промпт—ответ», которые обычно включают как ответ, соответствующий требованиям, так и ответ, не соответствующий требованиям, часто для сложного промпта, близкого к важной границе принятия решения. Цель не в том, чтобы имитировать полноценный реалистичный разговор. Это нужно, чтобы четко показать ключевое различие и сделать это так, чтобы одновременно продемонстрировать желаемый стиль ответа.

Мы сохраняем число примеров относительно небольшим и сосредотачиваемся на наиболее информативных из них. Более широкие наборы тестов (evaluation suites) помогают охватить оставшееся многообразие частных случаев.

Спецификация — это интерфейс, а не реализация. Она описывает нужное нам поведение, а не все детали того, как мы его обеспечиваем. Мы стараемся не привязывать это к деталям реализации, таким как внутренние форматы токенов или точная схема обучения для конкретного поведения, поскольку эти детали могут меняться, даже если желаемое поведение остается прежним. Основная аудитория спецификации модели — не сама модель, а люди: она призвана помочь сотрудникам OpenAI, пользователям, разработчикам, исследователям и лицам, определяющим политику, понимать, обсуждать и определять предполагаемое поведение ИИ.

Спецификация также описывает модель, а не весь продукт. Её дополняют наши политики использования⁠, в которых изложены требования к тому, как люди должны взаимодействовать с API и ChatGPT. Система, с которой взаимодействуют пользователи, включает не только саму модель: также важны функции продукта, такие как индивидуальные инструкции и память, мониторинг, обеспечение соблюдения политик и другие уровни. Безопасность — это гораздо больше, чем поведение модели, и мы выступаем за многоуровневую защиту⁠. 

Наконец, спецификация не является исчерпывающим описанием всего стека обучения или каждого внутреннего нюанса политики. Цель не в том, чтобы фиксировать каждую деталь. Мы стремимся делать наиболее важные решения относительно поведения модели понятными и полностью соответствующими нашим принципам.

Есть несколько причин включать в спецификацию столько деталей, а не предполагать, что читатель — или модель — сможет самостоятельно вывести всё из нескольких общих целей.

Во-первых, спецификация модели — это инструмент прозрачности и подотчётности . Она разработана для того, чтобы стимулировать конструктивную обратную связь от общественности. Четко сформулированная публично заявленная цель помогает людям понять, является ли то или иное поведение ошибкой или функцией. Это дает им устойчивую точку отсчета для критики и конкретной обратной связи. Именно поэтому мы открыли исходный код⁠(открывается в новом окне) спецификации модели и решили вести итеративную работу публично. С момента первого выпуска было внесено множество изменений на основе отзывов общественности, собранных с помощью различных механизмов, включая формы обратной связи, публичную критику и целенаправленные усилия⁠ по сбору мнений в рамках демократического подхода.

Во-вторых, спецификация модели — это инструмент координации внутри OpenAI. Он предоставляет людям, работающим в сферах исследований, разработки продуктов, безопасности, политики, юридических вопросов, коммуникаций и других функций, общий словарь для обсуждения поведения модели и механизм для внесения и рассмотрения изменений.

В-третьих, четкие правила позволяют компенсировать практические ограничения интеллекта моделей и контекста их работы, делая поведение более предсказуемым. Хотя со временем это становится менее актуальным, некоторые правила направлены на восполнение нехватки когнитивных способностей, когда модели не всегда могут надежно вывести правильное поведение из принципов высокого уровня. Например, правило «Будьте ясным и точным»⁠(открывается в новом окне) рекомендовало ранним моделям показывать ход рассуждений перед выдачей ответа на сложные задачи с вычислениями; сегодня наши модели естественным образом усваивают это поведение в процессе обучения с подкреплением⁠. 

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

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

Можно предположить, что достаточно способная модель должна быть в состоянии вывести правильное поведение из краткого списка целей, таких как «быть полезной и безопасной». В этом есть доля правды. В этом есть доля правды: в областях с объективными критериями успеха, таких как математика, интеллект часто может заменить детальные правила.

Но в целом поведение моделей не похоже на решение простой математической задачи; модели часто работают в более сложных областях, где нет единственно правильного ответа, с которым все могли бы согласиться. То, что значит для модели быть «полезной и безопасной», чрезвычайно зависит от контекста и является результатом принятия решений, неизбежно нагруженных ценностными суждениями. Одного интеллекта недостаточно, чтобы понять, на какие компромиссы идти, когда речь идет об этике и ценностях. Поэтому даже с ростом интеллекта моделей нам по-прежнему необходимо учиться формулировать и направлять их ценностные суждения — определять, что именно означает «этично» в каждой конкретной ситуации. Большинство причин для существования спецификации модели остаются актуальными даже при значительном росте возможностей ИИ: нам по-прежнему нужен открытый ориентир для координации, способ оценки соответствия поведения нашим намерениям и механизм пересмотра правил по мере накопления опыта. Если единственным правилом будет «будь полезной и безопасной», у людей не останется механизмов для обсуждения, например, границ того, какой контент модель должна отклонять, и все эти решения будут отданы на откуп самой модели.

Во всяком случае, по мере того как модели становятся более способными, более агентными и всё шире внедряются, цена неоднозначности возрастает. Это делает четкие рамки поведения еще более важными, а не менее важными.

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

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

При составлении спецификации модели мы ищем баланс между описанием текущего поведения ИИ (со всеми его «шероховатостями») и образом идеального будущего. Как правило, мы ориентируемся на горизонт в 0–3 месяца. Таким образом, спецификация часто идет на шаг впереди реальных возможностей модели в тех областях, которые находятся в активной разработке.

Это отражает роль спецификации модели как описания предполагаемого поведения. Это должно задавать нам последовательное направление, при этом оставаясь привязанным к тому, что мы уже делаем, или к тому, для чего у нас есть конкретные краткосрочные планы по внедрению.

Спецификация модели разрабатывается в рамках открытого внутреннего процесса. Любой сотрудник OpenAI может прокомментировать её или предложить изменения, а окончательные обновления утверждаются широким кругом кросс-функциональных заинтересованных сторон. На практике десятки людей напрямую участвовали в подготовке текста, а еще больше людей из подразделений, занимающихся исследованиями, разработкой, продуктом, безопасностью, политикой, юридическими вопросами, коммуникациями, международными вопросами и другими функциями, вносят свой вклад. Мы также учимся на публичных релизах и отзывах, которые помогают проверить эти решения на прочность в условиях реального внедрения.

Это важно, потому что поведение модели — и его последствия в реальном мире — невероятно сложны. Ни один человек не способен удержать в голове весь набор паттернов поведения, нюансы процесса обучения и долгосрочные эффекты. Однако благодаря участию множества кросс-функциональных контрибьюторов и рецензентов мы повышаем качество документа и уверенность в нем.

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

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

Наши рабочие модели пока не в полной мере соответствуют спецификации модели по нескольким причинам:

• Обучение модели может отставать от обновлений спецификации модели. Документ описывает целевое поведение, на которое мы ориентируемся в работе, поэтому он может опережать то, чему обучена наша последняя модель.
• В процессе обучения может случайно закрепиться поведение, противоречащее спецификации. Мы прилагаем все усилия, чтобы этого избежать, а если такое случается — относимся к этому как к серьезному багу и работаем над тем, чтобы привести поведение модели или саму спецификацию в соответствие друг с другом.
• Обучение никогда не может полностью охватить пространство всех возможных вариантов поведения. Реальное использование включает в себя бесконечное количество контекстов и пограничных случаев, которые проявляются только при масштабном развертывании; ни один процесс обучения не может предусмотреть всё.
• Обобщение (генерализация) может отличаться от задуманного. В процессе обучения модель может выдавать «правильные» результаты по непредусмотренным причинам, что приводит к неожиданному поведению в новых ситуациях. Такие методы, как обдуманное выравнивание⁠, помогают, но не решают проблему полностью.

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

Вместе со спецификацией мы выпускаем оценки спецификации модели⁠(открывается в новом окне): набор сценариев для тестирования, который охватывает максимально возможное количество положений спецификации на небольшом числе репрезентативных примеров. Это помогает нам отслеживать, в каких случаях поведение модели и спецификация модели могут не совпадать, а также проверять, интерпретируют ли модели спецификацию модели так, как мы задумали. Эти оценки — лишь одна часть более широкой стратегии оценки, которая также включает целенаправленные проверки по многим аспектам поведения, включая конкретные области безопасности, правдивость и поддакивание, личность и стиль, а также возможности.

На практике большинство обновлений cпецификации обусловлено регулярным поступлением данных из следующих источников:

• Публичные вопросы и обратная связь. Неясности, пограничные случаи или сбои — как в формулировках самой спецификации, так и в поведении наших моделей.
• Внутренние вопросы. Паттерны, которые мы замечаем в ходе разработки и тестирования, включая двусмысленности, где разные (но разумные) интерпретации приводят к разному поведению.
• Обновления политик поведения и безопасности. Когда ограничения или обязательства более высокого уровня меняются, спецификация должна ясно отражать эту новую структуру.
• Новые возможности и продукты. По мере того как модели становятся более способными к новому поведению и мы выпускаем новые продукты, мы хотим, чтобы спецификация модели не отставала по содержанию и охвату — например, за счет добавления правил для мультимодальных взаимодействий⁠(открывается в новом окне), автономных агентов⁠(открывается в новом окне) и пользователей младше 18 лет⁠(открывается в новом окне).

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

• Ясность и точность. «Будь честен» — хорошая ценность, но не готовый алгоритм принятия решений. Спецификация модели должна прояснять разногласия, а не скрывать их за обтекаемыми формулировками. Где это практически возможно, мы должны прямо указывать на потенциальные конфликты между правилами и давать рекомендации или примеры по их разрешению. Например, в пункте «Не лгать» (Do not lie)⁠(открывается в новом окне) отмечен возможный конфликт с правилом «Быть доброжелательным» (Be warm)⁠(открывается в новом окне): там объясняется, что ассистент должен следовать нормам вежливости, но избегать «лжи во спасение», которая может перерасти в поддакивание⁠(открывается в новом окне) и пойти вразрез с интересами пользователя.
• Содержательность правил. Читатель должен иметь возможность взять реалистичный запрос и дать ответ, который другой человек однозначно признает соответствующим или не соответствующим правилам (даже если на периферии остаются спорные моменты).
• Примеры с максимальным соотношением «сигнал/шум». Хорошие примеры часто играют ключевую роль в подготовке высококачественного обновления технических требований. Примеры должны помогать добраться до самой сути трудностей, связанных с определением поведения модели, выводя сложные конфликты на поверхность и занимая четкую позицию относительно того, как их разрешать. Во-вторых, они должны стремиться служить образцами желаемого тона и стиля, которые бывает трудно передать в письменной форме.
• Устойчивость. Мы стараемся избегать примеров с излишней двусмысленностью или сложностью, чтобы основной конфликт и предполагаемое разрешение были ясны.
• Последовательность и понятная структура. Мы стремимся к тому, чтобы правила спецификации модели полностью согласовывались друг с другом и с предполагаемым нами поведением модели, а общая структура документа была понятной и доступной.

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

Развитие спецификации определяют три критерия успеха:

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

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