Предыдущие посты серии:
1. Документация по промптам.
Перепробовал разные нейросети, платные тарифы, разные подходы к промптам, но пока не нашёл ничего лучше Claude (Anthropic) и Gemini (Google) для BI-разработки:
— На языке M в Power Query.
— На языке DAX в Power Pivot.
Главные выводы:
1️⃣ Хочешь результат сразу — покупай в нейронке платный тариф.
2️⃣ Хочешь бесплатно — страдай неделями бесплатно, переделывая сотни раз одно и то же.
3️⃣ Генерируй код сразу в нескольких нейронках одновременно и сравнивай результаты:
— Корректность обработки первых 50–100 строк массива:
а) Каждого шага запроса (модуля кода) по отдельности.
б) Всего запроса целиком.
— Корректность обработки нужного столбца, отфильтрованного по условиям (символам, словам, фразам), которые данный код:
а) Должен был обработать.
б) Не должен был обработать.
— Скорость на тестовом массиве на 30–50 тысяч строк.
— Производительность на объёмах в 0,5–1 млн строк.
4️⃣ Почему сразу в нескольких нейронках — потому что неизвестно, где получите код лучше:
— Без ошибок.
— Быстрее работающий.
— Масштабируемый (применимый для обработки больших массивов данных).
Чем больше сравнений делал, тем реже стал пользоваться чем-либо ещё кроме Claude и Gemini, но даже сравнивая их ежедневно, фаворита так и не выявил. Для биай разработки хороши оба.
Итак, общий алгоритм действий:
1️⃣ По одному и тому же промпту генерю код в нескольких нейронках сразу.
2️⃣ Проверяю на наличие ошибок.
3️⃣ Текст ошибки вместе с названием шага запроса, на котором появилась ошибка, копирую нейронке, и говорю исправить.
4️⃣ Проверяю на корректность обработки данных, отфильтровав в разных столбцах разные условия (символы, слова, фразы), которые после обработки:
🥷 Должны были там появиться.
🥷 Не должны были там появиться.
5️⃣ Выбираю корректно и безошибочно отработавший код (при наличии такового).
6️⃣ Выбираю очевидно самый быстрый вариант кода.
7️⃣ Каждую нейронку ещё по несколько раз прошу переписать корректно отработавший код, пользуясь всегда примерно одинаковым подходом к оптимизации скорости запроса.
Дальше приведу много примеров оптимизации скорости отработки кода, но суть их всегда будет заключаться в одном и том же.
Самым внимательным сверхразумам, кто заметит этот общий паттерн в промптах, приведенных в следующих постах, пирожок с полочки в подарок.
Этот подход уже много раз подтверждал свою пригодность, т.к. общий объём кода всё растёт, данных обрабатывается всё больше, функционал автоматизации всё сложнее, но несмотря на общее усложнение алгоритма, весь пайплайн со временем продолжаю только ускорять, детальнее разбираясь в особенностях алгоритмов в целом и Power Query в частности.
Некоторые модули кода я уже просто сбился со счёта, сколько раз переделывал.
Но не смотря на это, потом в рандомный момент или на Ютубе, или в статье, или в комментариях нейронки к очередному модулю кода я внезапно вижу некую абстрактную идею, в голову приходит мысль потестить её в другой части комбайна, И ХОБА — ускорение отработки переделанного запроса с 5 минут до 5 секунд.
А всё почему? А всё потому, что продолжаем список главных выводов:
5️⃣ Графический интерфейс Power Query — зло.
Да, он упрощает визуальное восприятие того, как происходит обработка данных, но это никак не способствует увеличению производительности.
Чем больше привыкаешь к GUI Power Query:
— Тем дольше выполняется каждый запрос, который ты в нём создаёшь.
— Тем больше накапливается технический долг — когда ради быстрого выпуска функционала из-за лени и спешки выбираешь простое, но некачественное решение, которое потребует исправления в будущем, но уже с «процентами».
— Тем дольше придётся потом переписывать весь хардкод на динамически пересчитываемые функции.
— Тем сложнее будет перепридумать логику и архитектуру кода с нуля.
Про GUI поговорим в отдельной серии постов
6️⃣ Нужно учить матчасть вычислений.
Это и рассмотрим дальше.
В следующем посте — о подготовке к созданию какого-либо кода.
via @ppc_bigbrain