Проверка AI-процесса на маленькой выборке
Этот навык помогает оптимизировать процесс разработки AI, начиная с минимально возможного ввода и постепенно увеличивая масштаб. Он позволяет избежать дорогостоящих ошибок и эффективно управлять затратами.
Экосистема: Универсальный
Инструкция
--- name: skeleton-first description: "Prove a data/AI/agent workflow end to end on a tiny sample, find cheap wins, then scale in cost-gated steps within budget." category: workflow risk: safe source: self source_type: self date_added: "2026-10-11" author: Dan He tags: [llm, cost, pipeline, etl, rag, dbt, snowflake, budget, data-engineering] tools: [claude, codex, cursor] --- # Сначала скелет: сначала докажите рабочий процесс дешево, затем масштабируйте Агенты, как правило, строят каждую стадию в полном размере, прежде чем что-либо будет запущено от начала до конца. В работе с данными и AI это приводит к дорогим ошибкам: неверный запрос обрабатывает всю таблицу, неверное зерно обнаруживается после создания двадцати моделей, большой склад сжигает кредиты на запрос, который возвращает неправильный ответ. Этот навык меняет порядок работы: 1. Сделайте **весь путь** рабочим на **наименьшем возможном вводе** с **самыми дешевыми настройками**. 2. Подтвердите это с помощью теста. 3. Масштабируйте в **ступенях с ограничением по стоимости**, измеряя и прогнозируя затраты перед каждой из них. 4. Только затем добавляйте функции, **по одной за раз**, повторно выполняя тесты после каждой. ## Когда использовать - Рабочий процесс с 2+ стадиями (ввод -> преобразование -> модель/LLM -> вывод) или что-либо, что касается оплачиваемых вычислений: кредиты склада, токены LLM, встраивания, вызовы API. - Новые или незнакомые данные, новый инструмент или SDK, архитектура, которая ранее не работала в этой среде. - Пользователь просит "построить X от начала до конца", "настроить конвейер", "обработать все документы", "создать модели". Пропустите это для: исправлений в одном файле, одного запроса, работы, уже доказанной в полном масштабе, или когда пользователь явно говорит перейти сразу к полному масштабу (тогда все равно сначала укажите прогнозируемую стоимость). ## Шаг 0 - Определите "это работает" перед строительством Запишите и покажите пользователю в 3-5 строках: - **Самый тонкий путь от начала до конца**: каждая стадия присутствует, минимум для каждой. Пример: 1 исходная таблица -> 1 преобразование -> 1 вызов LLM -> 1 строка вывода. - **Один тест на проход/не проход**, который человек может проверить, например, "для этих 3 образцовых строк вывод имеет столбцы A, B, C, и значение для строки 2 равно X". Предпочитайте тесты с известным правильным ответом. - **Бюджет**: максимальные расходы и время на всю работу и для скелета (скелет должен стоить почти ничего). Если пользователь не предоставил бюджет, предложите один и скажите об этом. ## Шаг 1 - Напишите лестницу Планируйте работу как ступени. Каждая ступень добавляет ровно одну вещь и имеет ограничение. | Ступень | Добавляет | Размер ввода | Ограничение для прохождения | | --- | --- | --- | --- | | L0 скелет | каждая стадия, заглушенная или минимальная | 1 запись | тест проходит от начала до конца | | L1 | реальная логика на самой слабой стадии | 10 записей | тест проходит, стоимость за запись измерена | | L2 | масштаб | ~1% или 100 записей | контроль качества, прогнозируемая полная стоимость в пределах бюджета | | L3 | полный запуск | 100% | итоги согласованы, тест все еще проходит | | L4+ | одна функция за раз | по мере необходимости | все предыдущие тесты все еще проходят | Покажите лестницу пользователю перед строительством, если задача не маленькая. Держите это коротким. ## Шаг 2 - Постройте L0, ходячий скелет - Каждая стадия существует и соединена; ни одна не отшлифована. - Жестко закодируйте или заглушите все, что не находится на критическом пути (конфигурация, повторные попытки, интерфейс, логирование, выходящее за рамки печати). - Используйте самые дешевые настройки повсюду (см. Рычаги затрат). - Запустите это. Если это не сработает, исправьте путь; не начинайте добавлять функции. - **Посмотрите на образец перед масштабированием.** Прочитайте несколько сырых записей и измерьте, за что вы платите. Большинство дешевых выигрышей скрываются здесь: дублирующиеся записи (кэш по хешу содержимого), повторяющийся шаблон в каждой записи (заголовки, подвал, юридические уведомления, подписи, шаблонные разделы), пустые или недействительные входные данные, за которые API все равно выставляет счет. Подсчитайте, сколько из затрат составляет каждая из них; удаление подвала, который составляет 70% каждого документа, стоит больше, чем любая настройка позже. Не разрешается до тех пор, пока L0 не пройдет: второй источник, вторая модель или таблица, параллелизм, настройка, интерфейс, абстракции, обработка крайних случаев, которые еще не были замечены. ## Шаг 3 - Масштабируйте в ступенях с ограничением по стоимости На каждой ступени: 1. Запустите на размере ввода ступени. 2. Запишите: записи на входе/выходе, ошибки, время, стоимость (токены, кредиты, вызовы API). 3. **Прогнозируйте следующую ступень**: стоимость за запись x следующий размер, время за запись x следующий размер. 4. **Ограничение**: продолжайте только если тест проходит, ошибки понятны, и прогноз в пределах бюджета. Когда прогноз превышает бюджет, бюджет является ограничением, вокруг которого нужно проектировать, а не причиной вернуть работу. Сначала ищите более дешевый путь, который все еще проходит тест: удалите избыточность, найденную в образце, отправляйте меньше на запись (релевантные разделы, усечение), кэшируйте, используйте более дешевую модель или бесплатный локальный метод для части работы. Подтвердите более дешевый путь на той же маленькой ступени, пересчитайте прогноз и продолжайте, если это подходит. Остановитесь и сообщите пользователю с цифрами и вариантами только тогда, когда ни один более дешевый путь не проходит тест, или когда это изменит то, что пользователь запрашивал, таким образом, что это, вероятно, будет иметь значение для них (скажите, какой компромисс вы сделали в любом случае). Увеличивайте примерно в 10 раз на ступень (1 -> 10 -> 100 или 1% -> полный). Никогда не переходите от скелета сразу к полному запуску. Ведите журнал выполнения в рабочей папке (например, `RUNLOG.md`): | Ступень | Ввод | Результат | Ошибки | Время | Стоимость | Прогнозируемая следующая | Решение | | --- | --- | --- | --- | --- | --- | --- | --- | ## Шаг 4 - Добавляйте функции по одной за раз - Одно изменение за шаг: новый источник, новая модель, новый инструмент, изменение запроса. - После каждого изменения повторно выполняйте каждый существующий тест (регрессия). Если что-то, что прошло, теперь не проходит, исправьте это перед добавлением чего-либо еще. - Когда тесты были написаны тем же агентом, который построил систему, попросите (или создайте через независимого субагента) несколько удерживаемых тестов, которые строитель не видел, прежде чем заявлять о качестве. ## Рычаги затрат Общие - Сначала образец: `LIMIT`, `SAMPLE`, несколько файлов, одна страница результатов. - Самая дешевая модель, которая может пройти тест; более сильная модель только для стадии, которая не проходит. - Сухие запуски: компиляция, `EXPLAIN`, проверка конфигурации без выполнения. - Ограничьте расходы на вызов: `max_tokens`, тайм-ауты, низкая параллельность до тех пор, пока не будет доказано. - Кэшируйте все, что детерминировано (встраивания, разобранные файлы, ответы API), чтобы повторные запуски были бесплатными. - Подсчитайте токены на образце и умножьте перед полным запуском. - Разбирайте структуру детерминированно, когда она существует (заголовки, таблицы, шаблоны); вызывайте LLM только для прозы. Код Snowflake / Cortex - Самый маленький склад (XS) с коротким авто-остановом; масштабируйте склад только после того, как логика будет правильной. - `SAMPLE` / `TABLESAMPLE` или `LIMIT` на источниках; проверьте зерно и количество строк на образце. - `EXPLAIN` перед дорогими запросами; предпочитайте временные или временные таблицы для промежуточных шагов. - Функции Cortex AI: сначала запустите на нескольких строках, проверьте вывод, оцените токены (например, `SNOWFLAKE.CORTEX.COUNT_TOKENS`, где доступно) перед применением к таблице. - dbt: создайте одну модель с `--select`; используйте `--empty` (dbt 1.8+) для проверки компиляции и выполнения DAG без данных; `--defer` для повторного использования родительских производств вместо их перестройки. LLM / RAG / агенты - Вводите 1 документ, затем 10, перед корпусом; измеряйте секунды и стоимость за кусок и экстраполируйте. - Оцените на 5-10 вопросах с известными ответами перед добавлением инструментов, повторных ранжировщиков или критиков. - Добавляйте одного агента или инструмент за раз; ведите журнал, какой инструмент вызывает каждый ответ, используемый. ## Отчетность на каждом ограничении Сообщите пользователю кратко: - Что запустилось (ступень, размер ввода) и прошел ли тест. - Стоимость и время на данный момент, а также прогноз для следующей ступени. - Рекомендованное вами решение (продолжить, исправить или остановиться) и все, что требует их решения. ## Антипаттерны - Строительство каждой стадии в полном размере, а затем запуск в первый раз. - Запуск LLM или функции AI по всей таблице, чтобы "посмотреть, что произойдет". - Добавление второго источника данных до того, как первый пройдет свой тест. - Настройка или добавление интерфейса до того, как путь будет работать. - Написание множества инструментов или правил, которые соответствуют одному тестовому вопросу (переобучение); вместо этого исправляйте классы ошибок и подтверждайте на удерживаемых тестах. - Заявление о успехе на тестах, написанных тем же агентом, который построил систему. - Остановка на прогнозе, превышающем бюджет, не попытавшись сначала сделать работу соответствующей бюджету. ## Пример Пользователь: "Пометьте все 400 тикетов в tickets.csv с категорией, используя наш LLM-эндпоинт." ```text Step 0 path: CSV -> 1 LLM call -> tagged.csv | test: 10 hand-checked tickets correct | budget: $2 (proposed) Sample: 3 tickets have empty bodies (API bills then errors) -> skip; only 220 of 400 texts are unique -> cache by hash Spent so far: L0 1 ticket pass $0.004 L1 10 tickets 10/10 $0.04 -> full run projected $0.88 (with dedupe) < $2, continue L2 100 12/12 $0.25 -> continue L3 400 pass $0.88 total (naive run would have cost $1.60) ``` ## Ограничения - Нужен способ измерения затрат (журнал, представление выставления счетов, подсчет токенов или история запросов); без этого прогнозы являются оценками и должны быть помечены как таковые. - Маленькие ступени могут пропустить проблемы, которые появляются только в масштабе (ограничения по скорости, редкие типы записей, перекошенные разделы); сохраняйте ограничение на полный запуск и согласовывайте итоги. - Добавляет несколько минут и некоторые токены на задачу; не стоит для одноразовых запросов, исправлений в одном файле или работы, уже доказанной в полном масштабе. - Тесты, написанные тем же агентом, могут быть слишком легкими; используйте удерживаемые тесты или проверку человеком перед заявлением о качестве. - Рычаги затрат, перечисленные для Snowflake и dbt, являются отправными точками; проверьте текущие цены и функции вашей платформы. ## Завершение означает - Полный запуск завершен в пределах бюджета. - Каждый тест с каждой ступени все еще проходит. - Журнал выполнения показывает затраты, время и решения по каждой ступени. - Пользователь знает реальную стоимость за единицу, поэтому будущие запуски предсказуемы. - Промежуточные выходные данные с ранних ступеней (образцы CSV, частичные индексы) удаляются или четко помечаются, чтобы для пользователя остался только конечный результат.Источник на GitHub