TL;DR
File-Native Context Engineering — принцип организации контекста для LLM: вместо того чтобы запихивать всё в один промпт, ты раскладываешь знания по файлам (схемы данных, документацию, правила), а модель сама ищет нужное через file operations. Исследование проверило это на задаче генерации SQL: 9,649 экспериментов, 11 моделей, 4 формата (YAML, Markdown, JSON, TOON), схемы от 10 до 10,000 таблиц. Сравнивали два подхода: File Agent (модель читает файлы по требованию через grep/read) vs Prompt Baseline (вся схема БД сразу в промпте).
Главная находка бьёт по универсальным рецептам: file-based подход работает по-разному для разных моделей. Frontier-модели (Claude, GPT, Gemini) стали точнее на +2.7% когда искали в файлах вместо чтения из промпта. Open-source модели показали смешанные результаты: одни (DeepSeek, Llama Scout) сработали примерно одинаково, другие (Qwen, Llama Maverick) провалились с файлами и потеряли до 22% точности. Причина: разное качество обучения работе с инструментами. Формат почти не влияет на точность (YAML 75.4%, Markdown 74.9%, JSON 72.3%), но влияет на эффективность: YAML съел на 28-60% меньше токенов, чем остальные.
Метод решает проблему масштаба через партиционирование по доменам: вместо одного файла с 10,000 таблиц — несколько файлов по ~250 таблиц (продажи, клиенты, склад). Модель сначала ищет в каком домене нужная таблица, потом читает только этот файл. Точность навигации осталась высокой даже на 10,000 таблиц. Неожиданный эффект: компактный формат TOON (на 25% меньше по размеру файла) съел в 7 раз больше токенов на больших схемах — "grep tax". Модели не знают синтаксис TOON, делают много неудачных попыток поиска, каждая попытка добавляет токены в контекст.
Схема метода
File-Native Architecture (применительно к ChatGPT/Claude Projects):
ПОДГОТОВКА:
1. Структурируй знания → файлы по темам/доменам
- schema.yaml — структура данных
- navigator.md — обзор и описания
- rules.md — бизнес-правила
2. Выбери формат → YAML для компактности, MD для читаемости
3. Партиционируй если >100 объектов → файлы по доменам (~250 объектов на файл)
ИСПОЛЬЗОВАНИЕ В ЧАТЕ:
1. Загрузи файлы в проект/чат
2. Дай задачу → модель сама найдёт нужные файлы
3. Модель читает только релевантное → меньше "lost in the middle"
Для frontier моделей (GPT-4+, Claude Opus/Sonnet, Gemini Pro) — работает из коробки. Для open-source — проверь сначала на малых данных.
Пример применения
Задача: Ты ведёшь онлайн-магазин на 300+ товаров в 15 категориях. Нужно быстро отвечать на вопросы про товары, остатки, характеристики — но запихивать весь каталог в промпт неудобно.
Подготовь файлы:
catalog_navigator.md:
# Навигатор по каталогу
## Структура
- electronics.yaml — электроника (смартфоны, ноутбуки, наушники)
- clothing.yaml — одежда (футболки, джинсы, обувь)
- home.yaml — для дома (посуда, текстиль, декор)
...
## Как искать
Если вопрос про характеристики → смотри в соответствующий .yaml
Если про остатки → поле stock_quantity
Если про цены → поле price_rub
electronics.yaml:
category: Электроника
tables:
- name: smartphones
description: Смартфоны всех брендов
columns:
- name: model
type: string
description: Модель телефона
- name: price_rub
type: integer
description: Цена в рублях
- name: stock_quantity
type: integer
description: Остаток на складе
- name: ram_gb
type: integer
description: Оперативная память в ГБ
- name: laptops
description: Ноутбуки
columns:
- name: model
- name: price_rub
- name: processor
- name: screen_inches
Загрузи файлы в проект → пиши вопросы:
"Какие смартфоны с 8+ ГБ памяти есть в наличии до 50,000 рублей?"
Результат: Модель прочитает navigator.md → поймёт что нужен electronics.yaml → откроет его → найдёт таблицу smartphones → прочитает структуру → выдаст результат с фильтрацией по ram_gb ≥ 8, price_rub ≤ 50000, stock_quantity > 0. Вместо обработки всех 300 товаров в промпте — прочитала только релевантный кусок.
Почему это работает
Слабость LLM: "Lost in the middle" — модели хуже используют информацию из середины длинного контекста. Если запихнуть схему на 10,000 таблиц в промпт, модель может пропустить нужную таблицу если она оказалась в середине списка. Плюс большой контекст = много токенов = дорого и медленно.
Сильная сторона LLM: Frontier-модели отлично используют инструменты (file read, search) — это часть их обучения. Они умеют разбивать задачу на шаги: "найди в каком файле это → прочитай файл → найди в файле нужное → используй".
Как метод использует это: File-native подход превращает один большой контекст в навигируемую базу знаний. Модель читает только то что нужно сейчас. Navigator.md даёт карту → модель ориентируется → читает конкретный файл → получает точный кусок данных. Это решает "lost in the middle" и экономит токены. Но работает только если модель натренирована на tool use — поэтому open-source модели проваливаются.
Рычаги управления:
- Гранулярность файлов: один файл на 10 доменов vs 10 файлов по домену → больше файлов = точнее поиск, но больше навигационных шагов
- Формат: YAML съедает меньше токенов при retrieval (compact key-value), Markdown читабельнее для человека
- Navigator.md: чем подробнее описания доменов → тем точнее модель выбирает файл с первой попытки
- Размер партиций: 50 vs 500 объектов на файл → меньше партиции = меньше шума в каждом файле, но больше навигационных шагов
Шаблон промпта
Структура файлов для file-native context:
1. Navigator файл (navigator.md или _index.yaml):
# Навигатор: {название системы}
## Структура знаний
- {файл_1}.yaml — {что содержит}: {краткое описание}
- {файл_2}.yaml — {что содержит}: {краткое описание}
...
## Как искать
Если вопрос про {тип_задачи_1} → смотри {файл_1}
Если вопрос про {тип_задачи_2} → смотри {файл_2}
## Форматы
Все .yaml файлы используют структуру:
{описание формата данных}
2. Файлы с данными (YAML для компактности):
domain: {название домена}
description: {что описывает}
entities:
- name: {имя сущности}
description: {что это}
fields:
- name: {поле}
type: {тип}
description: {что означает}
- name: {поле_2}
type: {тип}
description: {что означает}
- name: {имя сущности_2}
fields:
...
Как использовать: 1. Создай navigator.md — карту всех файлов 2. Раздели данные по доменам/темам в отдельные .yaml/.md 3. Загрузи все файлы в ChatGPT Project / Claude Project / через file upload 4. Пиши задачи — модель сама найдёт нужный файл через navigator
Партиционирование для больших объёмов (>500 объектов):
- Разбивай по доменам: ~250 объектов на файл
- Называй файлы говорящими именами: sales_schema.yaml, customers_schema.yaml
- В navigator.md — чёткие границы доменов
🚀 Быстрый старт — вставь в чат с загруженными файлами:
У меня есть {описание данных/системы}. Помоги структурировать это в file-native формат:
1. Раздели по доменам (оптимально ~250 объектов на файл)
2. Создай navigator.md с картой файлов
3. Для каждого домена создай .yaml файл по шаблону выше
Моя система: {описание}
Модель спросит про структуру данных, связи, логику разделения — потому что ей нужно понять границы доменов для эффективного партиционирования. Она возьмёт шаблон и создаст структуру под твои данные.
Ограничения
⚠️ Модель-специфичность: Open-source модели (особенно Qwen, Llama Maverick) проваливаются с file-based подходом и теряют до 22% точности. Всегда проверяй на малых данных перед масштабированием. Frontier модели (Claude 3.5+, GPT-4+, Gemini 1.5+) работают стабильно.
⚠️ Домен применения: Исследование тестировали на SQL generation — structured, unambiguous задача. Для творческих задач где контекст = вдохновение (писать в стиле автора X) эффект может быть другим. Работает лучше всего для справочной информации: схемы, документация, правила, каталоги.
⚠️ Grep tax для кастомных форматов: Если используешь свой формат (не YAML/JSON/Markdown) — модель потратит в разы больше токенов на поиск, потому что не знает паттернов. На 10,000 таблиц TOON (кастомный формат) съел в 7 раз больше токенов чем YAML.
⚠️ Барьер на некоторых платформах: Работает отлично в ChatGPT Projects, Claude Projects, API с file search. Не работает в обычном чате без file upload (придётся копипастить).
Как исследовали
Команда взяла TPC-DS — стандартный бенчмарк схемы базы данных (24 таблицы, retail domain: клиенты, продажи, склад). Создали 100 SQL-запросов разной сложности: от простых (L1: "найди покупателя") до сложных (L5: многошаговые запросы с подзапросами и оконными функциями). Задача модели: сгенерировать корректный SQL по natural language вопросу.
Проверили 11 моделей (Claude Opus/Haiku, GPT-4.5/mini, Gemini Pro/Flash, DeepSeek, Kimi, Llama 4, Qwen) в двух режимах: (1) File Agent — модель ищет в schema.yaml через grep/read, (2) Prompt Baseline — вся схема сразу в промпте. По 4 форматам: YAML, Markdown, JSON, TOON. Оценивали через Jaccard similarity результатов запросов: если модель получила то же что ground truth — success.
Почему результаты получились такими: Frontier модели (+2.7% с файлами) выиграли потому что избежали "lost in the middle" — не читали всю схему, а выбирали релевантное. Open-source модели провалились потому что плохо обучены на tool use: Qwen делал лишние grep-попытки, терял контекст, путался. DeepSeek справился лучше — видимо, больше примеров file operations в обучении.
Что удивило: TOON (компактный формат, на 25% меньше файл) съел в 7 раз больше токенов на 10,000 таблиц. Логика: модели не знают синтаксис TOON → пробуют паттерны из YAML/JSON → каждая неудачная попытка добавляет токены → на больших схемах накапливается "grep tax". При этом формат не повлиял на точность — только на efficiency. Это показало что file size ≠ runtime tokens: важна не компактность файла, а знакомость паттернов для эффективного поиска.
Инсайт для практики: Не оптимизируй формат ради размера файла — оптимизируй ради grep-friendly структуры. YAML выиграл не потому что компактен, а потому что модели знают паттерны (tables:, columns:, name:). Масштабирование работает не через уменьшение файла, а через партиционирование: на 10,000 таблиц модель читала только ~250 из нужного домена — контекст оставался bounded.
Оригинал из исследования
YAML Schema Format (использовался в эксперименте):
tables:
- name: store_sales
description: Sales transactions at physical stores
columns:
- name: ss_sold_date_sk
type: integer
description: Date key for sale transaction
- name: ss_item_sk
type: integer
description: Item key, references item table
- name: ss_customer_sk
type: integer
description: Customer key
- name: ss_quantity
type: integer
description: Quantity sold
- name: ss_sales_price
type: decimal
description: Price at which item was sold
foreign_keys:
- column: ss_sold_date_sk
references: date_dim.d_date_sk
- column: ss_item_sk
references: item.i_item_sk
- column: ss_customer_sk
references: customer.c_customer_sk
- name: customer
description: Customer dimension
columns:
- name: c_customer_sk
type: integer
description: Customer surrogate key
- name: c_current_addr_sk
type: integer
description: Current address key
- name: c_first_name
type: string
- name: c_last_name
type: string
Navigator.md structure (из исследования):
# Schema Navigator
## Overview
TPC-DS retail data warehouse schema with 24 tables across 4 domains:
- Sales (store_sales, web_sales, catalog_sales)
- Customers (customer, customer_address, customer_demographics)
- Items (item, warehouse, inventory)
- Time (date_dim, time_dim)
## How to search
For questions about:
- Sales transactions → store_sales, web_sales, catalog_sales
- Customer information → customer, customer_address
- Product details → item, warehouse
- Time periods → date_dim, time_dim
## Relationships
All sales tables link to:
- date_dim via *_sold_date_sk
- item via *_item_sk
- customer via *_customer_sk
Контекст: Исследователи использовали эту структуру для всех YAML-экспериментов. Navigator.md был одинаков для всех форматов, менялась только структура основных schema-файлов.
Адаптации и экстраполяции
💡 Адаптация для бизнес-процессов: Не только для схем БД — применимо для любых structured знаний.
Пример: база знаний для поддержки клиентов
support_navigator.md:
# База знаний техподдержки
## Структура
- billing_rules.yaml — правила тарификации, подписки, возвраты
- technical_specs.yaml — характеристики продуктов, совместимость
- common_issues.yaml — типовые проблемы и решения
- escalation_rules.yaml — когда эскалировать на L2/L3
## Как искать
Если вопрос про оплату/возврат → billing_rules.yaml
Если про "не работает" → common_issues.yaml, раздел по продукту
Если про характеристики → technical_specs.yaml
common_issues.yaml:
product: Мобильное приложение iOS
issues:
- symptom: "Не приходят пуш-уведомления"
causes:
- Выключены в настройках iOS
- Не дано разрешение при первом запуске
- Бета-версия приложения
solution: |
1. Настройки → {Название приложения} → Уведомления → включить
2. Если не помогло → переустановить приложение (разрешение спросит заново)
3. Если beta → обновить на стабильную из App Store
escalate_if: "После шагов 1-3 проблема осталась"
- symptom: "Тормозит интерфейс"
causes:
- iOS версии ниже 15
- Мало памяти на устройстве
solution: |
1. Проверь iOS: Настройки → Основные → Об этом устройстве
2. Если iOS 14 → предложи обновление
3. Проверь хранилище → Настройки → Основные → Хранилище
Загружаешь в проект → чат становится L1 support с мгновенным доступом к процедурам.
🔧 Техника: партиционирование по частоте использования → оптимизация токенов
Вместо партиционирования только по доменам — раздели на hot (часто нужное) и cold (редко):
_index.yaml:
partitions:
hot:
file: frequent_queries.yaml
description: 20% сущностей которые в 80% вопросов
use_case: ["pricing", "availability", "топ-10 товаров"]
cold:
file: full_catalog.yaml
description: Полный каталог для редких запросов
use_case: ["специфичные характеристики", "редкие категории"]
Эффект: большинство запросов читает только hot файл (меньше, релевантнее) → меньше токенов → быстрее → дешевле. Фоллбэк на cold только если в hot не нашли.
💡 Экстраполяция: комбинация с Chain-of-Thought для сложных запросов
Задача: {сложный запрос требующий данные из нескольких доменов}
Шаг 1: Декомпозиция
Разбей задачу на подзадачи. Для каждой подзадачи определи какие файлы нужны.
Шаг 2: Navigation
Для каждого файла:
- Прочитай navigator.md раздел про этот файл
- Найди нужную сущность через grep
- Прочитай только релевантный раздел
Шаг 3: Synthesis
Скомбинируй данные из всех источников, ответь на исходный вопрос.
Доступные файлы: {список из navigator.md}
Это комбинирует file-native retrieval с явным рассуждением — для задач где нужно собрать данные из 3+ доменов.
Ресурсы
Structured Context Engineering for File-Native Agentic Systems: Evaluating Schema Accuracy, Format Effectiveness, and Multi-File Navigation at Scale (2025)
- TPC-DS Benchmark: https://www.tpc.org/tpcds/
- Model Context Protocol: https://modelcontextprotocol.io/
- TOON Format: https://toonformat.dev/
- Spider Benchmark (text-to-SQL): arXiv:1809.08887
- "Lost in the Middle" (Liu et al., 2024): arXiv:2307.03172
- Context Engineering Survey (Mei et al., 2025): arXiv:2507.13334
Автор: Damon McMillan, HxAI Australia