На самом деле цель не в том, чтобы писать код ради кода, а в том, чтобы структурировать знания в форме, понятной и человеку, и ИИ. И стремится использовать эти структуры как единый источник документа нам и агенту.
А писать код - промпт в виде структур для агента не всегда нужно (как я понял из комментариев тут требуется отдельный материал с объяснением), но когда мы структурируем это лучше понимается нами же самими и может быть моделью контекста, которую можно переиспользовать, проверять и дополнять.
Вы совершенно правы данный пример не даст лучший результат. Современные модели обучены понимать свободный естественный язык очень хорошо.
Почему всё-таки есть разница. Есть сценарии, где структурирование действительно помогает: - Сложные многошаговые запросы (например, с ролью, контекстом, примерами, ограничениями). Структура снижает риск "перепутать уровни" - модель чётко понимает, где контекст, где инструкция, где пример. - Автоматизация/API-запросы. Форматированные блоки проще парсить и воспроизводить программно.
Данный пример и заявления могут быть громкими и требуют отдельного материала с бэнчмарками, чтобы показать, где структура реально даёт прирост, а где эффект минимален.
Согласен, о том и речь мы фокусируемся на создании четких инструкций. Про тестирование другой моделькой не думаю, что важно, главное, что бы не "перемешивался" контекст.
Я намеренно не говорю про инструменты (реализацию в конкретном инструменте), а хочу обсудить саму философию: создание централизованного источника правил, который будет служить как ИИ, так и команде, то есть шарится, к примеру через гит. А то, что мы пишем локально, используя конкретный инструмент или сниппеты - это вторично. Да и названия самих файлом, полагаю не имеют конкретного значения для ИИ, тут будет полезно посмотреть как обогащаются промпты перед отправкой в LLM. Вот здесь уже стоит смотреть на конкретные инструменты и в целом на то, как работает подход, подобный RAG.
На самом деле цель не в том, чтобы писать код ради кода, а в том, чтобы структурировать знания в форме, понятной и человеку, и ИИ. И стремится использовать эти структуры как единый источник документа нам и агенту.
А писать код - промпт в виде структур для агента не всегда нужно (как я понял из комментариев тут требуется отдельный материал с объяснением), но когда мы структурируем это лучше понимается нами же самими и может быть моделью контекста, которую можно переиспользовать, проверять и дополнять.
Вы совершенно правы данный пример не даст лучший результат.
Современные модели обучены понимать свободный естественный язык очень хорошо.
Почему всё-таки есть разница.
Есть сценарии, где структурирование действительно помогает:
- Сложные многошаговые запросы (например, с ролью, контекстом, примерами, ограничениями). Структура снижает риск "перепутать уровни" - модель чётко понимает, где контекст, где инструкция, где пример.
- Автоматизация/API-запросы. Форматированные блоки проще парсить и воспроизводить программно.
Данный пример и заявления могут быть громкими и требуют отдельного материала с бэнчмарками, чтобы показать, где структура реально даёт прирост, а где эффект минимален.
Согласен, о том и речь мы фокусируемся на создании четких инструкций.
Про тестирование другой моделькой не думаю, что важно, главное, что бы не "перемешивался" контекст.
Я намеренно не говорю про инструменты (реализацию в конкретном инструменте), а хочу обсудить саму философию: создание централизованного источника правил, который будет служить как ИИ, так и команде, то есть шарится, к примеру через гит. А то, что мы пишем локально, используя конкретный инструмент или сниппеты - это вторично. Да и названия самих файлом, полагаю не имеют конкретного значения для ИИ, тут будет полезно посмотреть как обогащаются промпты перед отправкой в LLM. Вот здесь уже стоит смотреть на конкретные инструменты и в целом на то, как работает подход, подобный RAG.