Forwarded from Инжиниринг Данных (Dmitry)
Microsoft опубликовал большой курс по Generative AI.
https://github.com/microsoft/generative-ai-for-beginners/tree/main
Снизу по ссылке будут дополнительные ссылки на другие курсы.
Самые горячие кейсы по GenAI, с которыми сталкиваюсь:
- Text to Insights (уже несколько проектов по Snowflake + Cortex Analyst и один по BigQuery + TextQL). Такие проекты для больших компаний (enterprise), больше похоже на продажу AI на уровне директора/VP аналитики другим директорам/VP бизнес подразделений, ну типа мы AI driven
- Developer Performance с использование Cursor или Claude Code. GitHub CoPilot пока не дотягивает. Компания покупают лицензии и дают своим инженерам. В репозиториях обязательно файлы с правилами для GenAI.
- PR reviews, часто с Claude Code и Cursor. Опять же можно добавить правила (best practices) для PR review, чтобы фиксить согласно заданным требованиям (правилам)
- RAG - компании строят чат боты по внутренней и внешней документации и базе знаний, чтобы клиенту было проще найти ответ на свой вопрос.
- MCP интеграции, например DataHub (дата каталог) может ходить в Snowflake (хранилище данных), Cursor может писать запросы и на базе них создавать dbt модели.
Это прям, что мои команды используют. Все сходятся на позиции, что prompt (context) engineering очень важен, и нужно знать основы и следовать рекомендациям вендоров.
PS и конечно это все идет в мою любимую рубрику - увлекательные истории для вашего будущего собеседования:)
https://github.com/microsoft/generative-ai-for-beginners/tree/main
Снизу по ссылке будут дополнительные ссылки на другие курсы.
Самые горячие кейсы по GenAI, с которыми сталкиваюсь:
- Text to Insights (уже несколько проектов по Snowflake + Cortex Analyst и один по BigQuery + TextQL). Такие проекты для больших компаний (enterprise), больше похоже на продажу AI на уровне директора/VP аналитики другим директорам/VP бизнес подразделений, ну типа мы AI driven
- Developer Performance с использование Cursor или Claude Code. GitHub CoPilot пока не дотягивает. Компания покупают лицензии и дают своим инженерам. В репозиториях обязательно файлы с правилами для GenAI.
- PR reviews, часто с Claude Code и Cursor. Опять же можно добавить правила (best practices) для PR review, чтобы фиксить согласно заданным требованиям (правилам)
- RAG - компании строят чат боты по внутренней и внешней документации и базе знаний, чтобы клиенту было проще найти ответ на свой вопрос.
- MCP интеграции, например DataHub (дата каталог) может ходить в Snowflake (хранилище данных), Cursor может писать запросы и на базе них создавать dbt модели.
Это прям, что мои команды используют. Все сходятся на позиции, что prompt (context) engineering очень важен, и нужно знать основы и следовать рекомендациям вендоров.
PS и конечно это все идет в мою любимую рубрику - увлекательные истории для вашего будущего собеседования:)
Forwarded from Dimension AI | Dmitry Sirakov
Hybrid: SGR + Tools - закрываем дыры, не ломая протокол
После горячих обсуждений и двух предыдущих постов (пост 1, пост 2) я решил показать рабочий гибридный паттерн и сделать вклад в опенсорс-подход к SGR (линк в конце поста).
TLDR пост1 и пост2: SGR пишет ответ через «поля» и якоря [благодаря чему, приводит к более предсказуемым и верным ответам], но в чистом виде легко размывает семантику tool-calling (если мы ее задействуем): в истории появляются вызовы инструментов, которых не было в объявленном наборе и не передались в чат-темплейт, а если неаккуратно обрабатывать вызовы - нас ждёт еще больше проблем. И всё это расходится с практиками провайдеров и публичными бенчмарками по агентости.
Что я сделал:
Я вынес рассуждение в отдельный инструмент generate_reasoning и заставляю модель вызывать его принудительно сразу после любого пользовательского сообщения с помощью управления tool_choice. Внутри reasoning используется SGR: цель, план, ограничения, проверка предпосылок, сигналы о том, нужно ли звать инструменты и какие именно. Далее "агент", опираясь на получившееся рассуждение, вызывает только те функции, которые явно объявлены в tools, строго через нативный механизм вызовов.
Ключевые свойства подхода:
1. Никакого «динамического tools из воздуха». Всё, чем пользуется модель, заранее объявлено; в истории нет инструментов, которых нет в tools. Контроль с помощью tool_choice.
2. История сообщений валидна и читаема: отдельно видно этап рассуждения и отдельно - действия и финальный ответ.
3. Совместимость с практиками провайдеров и бенчами: снижается риск tool-hallucination, корректнее проходит проверка релевантности функций.
4. Контроль внимания вместо хаоса: сначала гарантированное рассуждение, потом действия. Это делает маршрутизацию детерминированной и устойчивой. Тк много трейновых датасетов, как и в каких ситуациях вызывать тулы, мы используем очень много компьюта в свою пользу: не только будущая корректная оценка цепочек ризонинга (для метрик), но и адаптивный выбор тулов.
Почему это устойчивее, чем «SGR-only»:
- Нативные tool_calls, а не эмуляция вызовов через content (да, можно этого избежать, подкладывая вызов SGRв tool_calls, но не решается следующий пункт:
- Меньше неожиданностей для модели: нет сценария «ответил JSON -> внезапно прилетел tool», когда tools пусты.
- Проще поддерживать качество: reasoning становится обычным шагом workflow. Его вообще можно вынести на значительно более мощные модели или наоборот, более слабые. Позволяет нам давать больше контроля.
Получается стабильный и интерпретируемый паттерн: чат-темплейт согласован с историей, вызовы инструментов не идут «против шерсти», а модель ведёт себя предсказуемо.
Рекомендую попробовать гибрид SGR + Tools на своих задачках
линк на код
поддержите реакциями ❤️
После горячих обсуждений и двух предыдущих постов (пост 1, пост 2) я решил показать рабочий гибридный паттерн и сделать вклад в опенсорс-подход к SGR (линк в конце поста).
TLDR пост1 и пост2: SGR пишет ответ через «поля» и якоря [благодаря чему, приводит к более предсказуемым и верным ответам], но в чистом виде легко размывает семантику tool-calling (если мы ее задействуем): в истории появляются вызовы инструментов, которых не было в объявленном наборе и не передались в чат-темплейт, а если неаккуратно обрабатывать вызовы - нас ждёт еще больше проблем. И всё это расходится с практиками провайдеров и публичными бенчмарками по агентости.
Что я сделал:
Я вынес рассуждение в отдельный инструмент generate_reasoning и заставляю модель вызывать его принудительно сразу после любого пользовательского сообщения с помощью управления tool_choice. Внутри reasoning используется SGR: цель, план, ограничения, проверка предпосылок, сигналы о том, нужно ли звать инструменты и какие именно. Далее "агент", опираясь на получившееся рассуждение, вызывает только те функции, которые явно объявлены в tools, строго через нативный механизм вызовов.
Ключевые свойства подхода:
1. Никакого «динамического tools из воздуха». Всё, чем пользуется модель, заранее объявлено; в истории нет инструментов, которых нет в tools. Контроль с помощью tool_choice.
2. История сообщений валидна и читаема: отдельно видно этап рассуждения и отдельно - действия и финальный ответ.
3. Совместимость с практиками провайдеров и бенчами: снижается риск tool-hallucination, корректнее проходит проверка релевантности функций.
4. Контроль внимания вместо хаоса: сначала гарантированное рассуждение, потом действия. Это делает маршрутизацию детерминированной и устойчивой. Тк много трейновых датасетов, как и в каких ситуациях вызывать тулы, мы используем очень много компьюта в свою пользу: не только будущая корректная оценка цепочек ризонинга (для метрик), но и адаптивный выбор тулов.
Почему это устойчивее, чем «SGR-only»:
- Нативные tool_calls, а не эмуляция вызовов через content (да, можно этого избежать, подкладывая вызов SGRв tool_calls, но не решается следующий пункт:
- Меньше неожиданностей для модели: нет сценария «ответил JSON -> внезапно прилетел tool», когда tools пусты.
- Проще поддерживать качество: reasoning становится обычным шагом workflow. Его вообще можно вынести на значительно более мощные модели или наоборот, более слабые. Позволяет нам давать больше контроля.
Получается стабильный и интерпретируемый паттерн: чат-темплейт согласован с историей, вызовы инструментов не идут «против шерсти», а модель ведёт себя предсказуемо.
Рекомендую попробовать гибрид SGR + Tools на своих задачках
линк на код
поддержите реакциями ❤️
Forwarded from Заскуль питона (Data Science)
90% задач аналитик решает в SQL. Но остаются те самые 10%, где без Python никак
Я собрал Google Colab, где в одном месте покрыта большая часть методов (практические все), которые реально нужны аналитику: от базовых конструкций (строки, списки, словари) до pandas/numpy, работы с API, визуализации, Spark и Airflow и др.
Ставьте
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Zero to Vibe[coding]
Чтобы вы могли поиграться на выходных, ловите инструкцию как подружить Figma и Cursor за 1 минуту.
Forwarded from Zero to Vibe[coding]
📖 В конце рабочей недели этот пост попадёт вам в самое сердечко, потому что вокруг так много интересного, а сил и времени всё это почитать уже нет, правда? 🌚
🧚 NotebookLM и Нейроэксперт
Эти инструменты помогут вам не сойти с ума в следующих ситуациях:
1. у вас в руках pdf-документ на десятки страниц, а вы даже не знаете, есть ли в нём полезное для вас;
2. несколько статей на тему, в которую надо срочно погрузиться;
3. микс из статей, pdf, копипастов текста (а если брать NotebookLM, то прибавьте к этому Google Drive и ролики с YouTube) -- чтоб разобраться в теме максимально основательно!
Как это работает:
- Грузите нужные вам данные в эти инструменты (оба работают на вебе и бесплатные, но как обычно в мире GPT -- есть лимиты, проконсультируйтесь с тарифами). NDA не грузите;
- Получаете саммари документов, чтобы понять о чём речь;
- Чатитесь с загруженными документами: если данных в документе есть, то вы получите ответ на свой вопрос со ссылкой на конкретный абзац, чтобы всё проверить, а если нет, то сервис так про это и скажет.
Отдельно круто то, что:
- закинуть данные вы можете на английском, а задавать вопросы и получать ответы -- на русском;
- если в документе картинки с графиками или табличками, LLM их тоже "прочитает" и сможет использовать для ответов.
Плюсы и минусы вариантов:
📘 NotebookLM сильно фукнциональнее. Например, он может сделать майндмеп контента, квиз по контенту или флэш-карточки для заучивания. Есть инстурументы для подкастеров и видео-блоггеров, но я у мамы не могу быть ими всеми, так что обзора не будет 🙂
Минусы: 1) плохо доступен из России без VPN... 2) ответы пишет тяжеловатым языком.
📕 Нейроэксперт пока попроще, без квизов и майндмепов, но хорошо справляется с базовым -- ответить на вопросы по документам, чтобы сэкономить ваше время. И прекрасно доступен из России. А ещё он как-то очень легко и понятно пишет ответы.
Минусы: пока невозможность попасть в нужное место исходного документа по ссылке, есть только цитата. Иногда не хватает контекста для правильного понимания.
Лайфхак для жизни:
- закидываете в такой сервис договор с банком и просите перечисли всё, что в нём плохо для вас, как для клиента;
- ура, вы знаете всё, что от вас пытались скрыть сноски, звездочки, мелкий шрифт и канцелярский язык.
🧚 NotebookLM и Нейроэксперт
Эти инструменты помогут вам не сойти с ума в следующих ситуациях:
1. у вас в руках pdf-документ на десятки страниц, а вы даже не знаете, есть ли в нём полезное для вас;
2. несколько статей на тему, в которую надо срочно погрузиться;
3. микс из статей, pdf, копипастов текста (а если брать NotebookLM, то прибавьте к этому Google Drive и ролики с YouTube) -- чтоб разобраться в теме максимально основательно!
Как это работает:
- Грузите нужные вам данные в эти инструменты (оба работают на вебе и бесплатные, но как обычно в мире GPT -- есть лимиты, проконсультируйтесь с тарифами). NDA не грузите;
- Получаете саммари документов, чтобы понять о чём речь;
- Чатитесь с загруженными документами: если данных в документе есть, то вы получите ответ на свой вопрос со ссылкой на конкретный абзац, чтобы всё проверить, а если нет, то сервис так про это и скажет.
Отдельно круто то, что:
- закинуть данные вы можете на английском, а задавать вопросы и получать ответы -- на русском;
- если в документе картинки с графиками или табличками, LLM их тоже "прочитает" и сможет использовать для ответов.
Плюсы и минусы вариантов:
📘 NotebookLM сильно фукнциональнее. Например, он может сделать майндмеп контента, квиз по контенту или флэш-карточки для заучивания. Есть инстурументы для подкастеров и видео-блоггеров, но я у мамы не могу быть ими всеми, так что обзора не будет 🙂
Минусы: 1) плохо доступен из России без VPN... 2) ответы пишет тяжеловатым языком.
📕 Нейроэксперт пока попроще, без квизов и майндмепов, но хорошо справляется с базовым -- ответить на вопросы по документам, чтобы сэкономить ваше время. И прекрасно доступен из России. А ещё он как-то очень легко и понятно пишет ответы.
Минусы: пока невозможность попасть в нужное место исходного документа по ссылке, есть только цитата. Иногда не хватает контекста для правильного понимания.
Лайфхак для жизни:
- закидываете в такой сервис договор с банком и просите перечисли всё, что в нём плохо для вас, как для клиента;
- ура, вы знаете всё, что от вас пытались скрыть сноски, звездочки, мелкий шрифт и канцелярский язык.
Forwarded from Data Дзен с Олегом Дмитриевым
Дашборд без бара = работа в трубу 🛑
Неделю делал дашборд — а заказчик так и не понял, где растут продажи»
Потому что вместо ответа дал ему «аналитику». Фильтры, карты, справочники — но не то, зачем он пришёл.
Барчарт — не скучно. Это честно📊
Он не украшает данные. Он говорит прямо: «Вот где больше. Вот где меньше». И именно за это тебя начинают слушать — не как исполнителя, а как специалиста.
Даже барчарт врёт — если не знать три тихих правила🤔
➡️ всегда с нуля (иначе +5% выглядит как взрыв)
➡️ сортировка по значению — не по алфавиту
➡️ никаких «толстых» столбцов для «важных» категорий.
Это манипуляция, даже если ты не хотел.
Когда стоит отказаться от барчарта ?
Если нужно показать тренд во времени — берите линию. Если сравниваете части целого — подумайте о круговой. Если много категорий — таблица.
Главное: график отвечает на вопрос, а не задает новые📌
А у тебя был момент, когда ты заморочился с визуализацией — а потом понял: достаточно было одного бара?
P.S. Напишите в комментах, насколько комфортен такой формат постов🙏
#база_для_визуализации
Неделю делал дашборд — а заказчик так и не понял, где растут продажи»
Потому что вместо ответа дал ему «аналитику». Фильтры, карты, справочники — но не то, зачем он пришёл.
Барчарт — не скучно. Это честно
Он не украшает данные. Он говорит прямо: «Вот где больше. Вот где меньше». И именно за это тебя начинают слушать — не как исполнителя, а как специалиста.
Даже барчарт врёт — если не знать три тихих правила
Это манипуляция, даже если ты не хотел.
Однажды я сделал дашборд по аптечным продажам — и провалил задачу»
Были плиточные карты, топ-10 регионов, количество аптек и юрлиц… Но не было самого главного: какие позиции продаются. Заказчик спросил: «А что именно растёт в Татарстане?» — и я не смог ответить. Пришлось переделывать всё с нуля. Просто добавил барчарт по ТОП-5 SKU — и вопрос исчез.
Когда стоит отказаться от барчарта ?
Если нужно показать тренд во времени — берите линию. Если сравниваете части целого — подумайте о круговой. Если много категорий — таблица.
Главное: график отвечает на вопрос, а не задает новые
А у тебя был момент, когда ты заморочился с визуализацией — а потом понял: достаточно было одного бара?
P.S. Напишите в комментах, насколько комфортен такой формат постов
#база_для_визуализации
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM