Документация Яндекс Облака¶
ИИ Студия может использовать официальную документацию Яндекс Облака как отдельный источник знаний.
Это полезно в двух принципиально разных сценариях:
- пользователь просто хочет получить актуальную инструкцию;
- пользователь хочет сопоставить свою фактическую инфраструктуру с текущей документацией.
Важная особенность¶
Для поиска по официальной документации не требуется подключать рабочий каталог.
Поэтому вопрос:
Какая роль нужна для чтения Billing Usage API?
можно задать до загрузки авторизованный ключ.
Но вопрос:
Есть ли эта роль у нашей служебной учётной записи?
уже требует доступа к фактическим ресурсам/IAM.
1. Как задавать вопрос по документации¶
Плохо:
Как это настроить?
Хорошо:
Найди в актуальной официальной документации Яндекс Облака инструкцию по созданию авторизованного ключа service account.
Верни:
1. последовательность действий в консоли;
2. CLI-команду;
3. важные ограничения безопасности;
4. ссылку на официальный источник;
5. дату/актуальность страницы, если она доступна.
2. Всегда уточняйте сервис¶
В Яндекс Облаке похожие термины могут существовать в нескольких продуктах.
Например:
может означать примитивную IAM роль, а может обсуждаться конкретная сервисная роль.
Поэтому лучше:
3. Указывайте, что нужен текущий способ¶
Облачные API развиваются.
Хороший запрос:
Проверь актуальную на сентябрь 2026 года документацию Yandex Cloud Billing.
Как сейчас получать детализацию расходов через API?
Отдельно укажи, используется REST или gRPC для Usage API.
Это защищает от инструкции, актуальной несколько лет назад.
4. Просите ссылку на первичный источник¶
Для технически значимых ответов используйте правило:
Особенно для:
- ролей;
- цен;
- сроков поддержки моделей;
- адрес API;
- lifecycle;
- квот;
- ограничений;
- security recommendations.
5. Документация и фактическая инфраструктура¶
Один из сильнейших сценариев Студии:
Посмотри фактическую конфигурацию нашего <ресурс>.
Затем найди актуальную официальную документацию по этой функции.
Сравни.
Пример:
Покажи таблицы маршрутизации рабочего Folder.
Затем найди актуальную документацию по static routes и NAT Gateway.
Объясни нашу конфигурацию на языке документации.
Не предлагай изменения, которые нельзя подтвердить источником.
6. Не смешивайте факт документации и факт инфраструктуры¶
В ответе желательно требовать маркировку:
[Факт YC] — получено из нашей инфраструктуры
[Документация] — правило/описание из официальной документации
[Вывод] — интерпретация модели
Пример:
[Факт YC] VM web-01 имеет публичный IP.
[Документация] публичный IP обеспечивает внешнюю сетевую доступность при выполнении остальных условий сети/SG.
[Вывод] нужно отдельно проверить security group; одного факта наличия IP недостаточно, чтобы утверждать, что сервис открыт всему Интернету.
7. Роли и IAM¶
Очень полезный сценарий:
У нас ошибка PERMISSION_DENIED при обращении к AI Studio.
Найди официальный минимум ролей для text generation и объясни, на какой Folder её нужно назначить.
Затем можно попросить инфраструктурный сервис проверить фактические bindings.
8. Billing¶
Пример:
Найди официальную документацию Billing ConsumptionCore.
Объясни cost, credits и expense.
Затем сопоставь эти определения с цифрами из нашего FinOps overview.
Так модель не придумывает финансовую семантику сама.
9. Yandex AI Studio¶
Просите проверять:
- актуальный model URI;
- context length;
- supported API;
- lifecycle;
- необходимые роли;
- pricing;
- logging/privacy options.
Например:
Проверь официальную карточку YandexGPT Pro 5.1.
Укажи model URI, context и поддерживаемые API.
Не используй сторонние обзоры.
10. Цена — всегда динамическая информация¶
Никогда не полагайтесь на цену, «которую модель помнит».
Правильный запрос:
Открой актуальную страницу тарифов Yandex AI Studio и проверь цену модели <...>.
Укажи валюту страницы и единицу тарификации.
Warning
Страница тарифов может отображать валюту в зависимости от региона/платёжного профиля. Всегда фиксируйте валюту и дату проверки.
11. Сроки поддержки моделей¶
Model Gallery меняется.
Если модель имеет дату окончания доступности, попросите:
Проверь lifecycle этой модели в официальной документации и укажи точную дату окончания поддержки/доступности, если она опубликована.
Не переносите срок одной модели на всё семейство.
12. Документация может быть новее знаний модели¶
Это нормальный сценарий.
Если внутреннее знание модели конфликтует с текущей официальной страницей:
- покажите конфликт;
- отдайте приоритет актуальному официальному источнику для текущей конфигурации;
- зафиксируйте дату источника.
13. Когда официальный источник тоже недостаточен¶
Документация может описывать общий механизм, но не конкретное поведение вашей организации.
Например, роль позволяет операцию, но organizational authorization policy её блокирует.
Тогда ответ должен звучать:
По документации роль разрешает действие, но фактический вызов может быть запрещён политикой авторизации вашей организации.
14. Использование для troubleshooting¶
Хороший шаблон:
Ошибка:
<точный текст>
1. Найди официальный раздел troubleshooting/API errors.
2. Найди требуемые роли.
3. Сопоставь с нашим текущим scope.
4. Не предлагай расширять роль до editor/admin, если можно дать более узкую.
5. Верни пошаговую проверку.
15. Проверка ответа пользователем¶
Для критичного изменения:
- откройте ссылку;
- найдите утверждение на странице;
- проверьте дату обновления;
- проверьте, что речь о нужном сервисе;
- проверьте, что инструкция относится к вашей схеме аутентификации;
- только затем применяйте изменение вручную.
16. Что официальный documentation service не должен делать¶
Он не должен:
- выдавать себя за фактическое состояние вашей инфраструктуры;
- автоматически применять найденную инструкцию;
- создавать ресурс;
- менять роль;
- считать стороннюю статью официальной;
- скрывать конфликт между двумя версиями документации;
- превращать пример документации в доказательство вашего конкретного состояния.
17. Готовые запросы¶
Найти роль¶
Найти актуальный API¶
Какой API сейчас рекомендуется для <задача>?
Проверь текущую официальную документацию и lifecycle старого API.
Проверить ошибку¶
Проверить цену¶
Сравнить с реальной конфигурацией¶
Сначала получи фактические параметры <ресурс> из нашего рабочего Folder.
Затем сравни их с официальной документацией.