Forwarded from Artificial stupidity
#llm
Начал понемногу ковыряться с теорией по агентским системам и тому, как оно все работает. Потому периодически буду сюда вкидывать что-то из материалов.
Начнем с простого.
Какие есть типы агентов?
Простой рефлекторный агент.
Самый простой агент, который использует нынешнее состояние среды. Просто делают действие на основе раздражителя. У них нет памяти и модели мира, потому они удобны только в случае стабильной наблюдаемой среды.
Пример: Робот-пылесос, который поворачивается при ударе.
Рефлекторный агент на одном модели.
Такой агент хранит информацию о состоянии среды за период и основывает свои действия на сохраненной информации. И, по сути, строит очень-очень простую модель мира.
Пример: Робот-пылесос, который запоминает свой маршрут и окружение, потому может обходить часть препятствий.
Агент, ориентирующийся на цель.
Агент, который оценивает действия по тому, насколько они приближают к цели. Такой тип агентов обычно использует алгоритмы поиска или планирования, чтобы анализировать последовательности шагов и выбирать оптимальные, учитывая будущие последствия.
Пример: Навигационная система, рассчитывающая лучший маршрут.
Утилитарный агент.
Этот тип агентов выбирает действия так, чтобы максимизировать "полезность" — общую ценность исхода по заданной функции. Он оценивает варианты, прогнозирует последствия и учитывает компромиссы, а не просто достигает цели. Фактически, похож на агента с ориентацией на цель, но тут разница в методах достижения. Если одному важно лишь достигнуть цель, то второму еще важно учесть и затраты на ее достижение.
Пример: Чат-бот для продаж, приоритизирующий лиды по вероятности конверсии.
Обючающийся агент.
Это агент, который учится на обратной связи из окружащей среды. Он состит из 4 элеметов: модуль действия, модуль обучения (который как раз корректирует действия), модуль-критик (для оценок) и генератор новых действий (в оригинале это "генератор проблем", но смысл в том, чтобы придумывать новые действия для оценки как раз).
Пример: Внезапно, рексис движок (впрочем, это если у него есть оценщик, он дообучается на наших данных и прикручена часть с эксплорейшеном, тогда все будет подходить).
Мультиагентная система.
Система из нескольких взаимодействующих агентов, которые сотрудничают или конкурируют для достижения цели. Каждый агент независим, и имеет собственные возможности и инструменты. Агенты общаются напрямую или через изменения в среде, решая задачи, слишком сложные для одного агента.
Пример: Набор агентов для написания и редактирования кода. Один ищет уязвимости, второй пишет код, третий делает ревью и пишет описание PR (но можно выдумать еще варианты).
Начал понемногу ковыряться с теорией по агентским системам и тому, как оно все работает. Потому периодически буду сюда вкидывать что-то из материалов.
Начнем с простого.
Какие есть типы агентов?
Простой рефлекторный агент.
Самый простой агент, который использует нынешнее состояние среды. Просто делают действие на основе раздражителя. У них нет памяти и модели мира, потому они удобны только в случае стабильной наблюдаемой среды.
Пример: Робот-пылесос, который поворачивается при ударе.
Рефлекторный агент на одном модели.
Такой агент хранит информацию о состоянии среды за период и основывает свои действия на сохраненной информации. И, по сути, строит очень-очень простую модель мира.
Пример: Робот-пылесос, который запоминает свой маршрут и окружение, потому может обходить часть препятствий.
Агент, ориентирующийся на цель.
Агент, который оценивает действия по тому, насколько они приближают к цели. Такой тип агентов обычно использует алгоритмы поиска или планирования, чтобы анализировать последовательности шагов и выбирать оптимальные, учитывая будущие последствия.
Пример: Навигационная система, рассчитывающая лучший маршрут.
Утилитарный агент.
Этот тип агентов выбирает действия так, чтобы максимизировать "полезность" — общую ценность исхода по заданной функции. Он оценивает варианты, прогнозирует последствия и учитывает компромиссы, а не просто достигает цели. Фактически, похож на агента с ориентацией на цель, но тут разница в методах достижения. Если одному важно лишь достигнуть цель, то второму еще важно учесть и затраты на ее достижение.
Пример: Чат-бот для продаж, приоритизирующий лиды по вероятности конверсии.
Обючающийся агент.
Это агент, который учится на обратной связи из окружащей среды. Он состит из 4 элеметов: модуль действия, модуль обучения (который как раз корректирует действия), модуль-критик (для оценок) и генератор новых действий (в оригинале это "генератор проблем", но смысл в том, чтобы придумывать новые действия для оценки как раз).
Пример: Внезапно, рексис движок (впрочем, это если у него есть оценщик, он дообучается на наших данных и прикручена часть с эксплорейшеном, тогда все будет подходить).
Мультиагентная система.
Система из нескольких взаимодействующих агентов, которые сотрудничают или конкурируют для достижения цели. Каждый агент независим, и имеет собственные возможности и инструменты. Агенты общаются напрямую или через изменения в среде, решая задачи, слишком сложные для одного агента.
Пример: Набор агентов для написания и редактирования кода. Один ищет уязвимости, второй пишет код, третий делает ревью и пишет описание PR (но можно выдумать еще варианты).
Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. Про обмен в команде
Люблю, когда в постах/подкастах/докладах не просто теория «как надо абстрактно в вакууме» налита, а есть еще и адаптация к реальной жизни, к её неидеальности и разнообразию. А еще когда истории из практики.
Сегодня вот такой пост как раз вам принес https://t.me/morkovka_speredi_morkovka_szadi/69.
В абстрактной теории надо было бы сгорающие сторипоинты посчитать, велосити замерить, простои, реальную капасити и навести оптимизаций. А начни автор «эффективно менеджерить» сотрудника, ведь чего это он за 2–3 часа всё делает, а в остальное время чилит, то лично я думаю, что и реального ускорения бы не добился, но еще и отношения бы испортил и больше бы не шел работник навстречу в сложных ситуациях.
Я тоже выступаю за разумный обмен между работником и компанией, руководителем и его подчиненными и его руководителем сверху. Тогда работа получается гибче и морально комфортнее.
Но надо помнить и об экстремумах. Цитата из поста:
«В любых отношениях должен быть обмен.
Если вы только требуете — с вами не будут хотеть работать.
Если вы только отдаете — на вас будут ездить.
Мораль, которую я так люблю: везде должен быть баланс. Так что следите за балансом».
А как у вас в команде? Есть какие-то взаимообменивающиеся вещи? Ну типа днем надо по врачам помотаться, а потом в случае пожара могу подорваться и потушить вечером поздно.м.
Люблю, когда в постах/подкастах/докладах не просто теория «как надо абстрактно в вакууме» налита, а есть еще и адаптация к реальной жизни, к её неидеальности и разнообразию. А еще когда истории из практики.
Сегодня вот такой пост как раз вам принес https://t.me/morkovka_speredi_morkovka_szadi/69.
В абстрактной теории надо было бы сгорающие сторипоинты посчитать, велосити замерить, простои, реальную капасити и навести оптимизаций. А начни автор «эффективно менеджерить» сотрудника, ведь чего это он за 2–3 часа всё делает, а в остальное время чилит, то лично я думаю, что и реального ускорения бы не добился, но еще и отношения бы испортил и больше бы не шел работник навстречу в сложных ситуациях.
Я тоже выступаю за разумный обмен между работником и компанией, руководителем и его подчиненными и его руководителем сверху. Тогда работа получается гибче и морально комфортнее.
Но надо помнить и об экстремумах. Цитата из поста:
«В любых отношениях должен быть обмен.
Если вы только требуете — с вами не будут хотеть работать.
Если вы только отдаете — на вас будут ездить.
Мораль, которую я так люблю: везде должен быть баланс. Так что следите за балансом».
А как у вас в команде? Есть какие-то взаимообменивающиеся вещи? Ну типа днем надо по врачам помотаться, а потом в случае пожара могу подорваться и потушить вечером поздно.м.
Telegram
Морковка спереди, морковка сзади
#истории_из_жизни
Тут в комментариях разгорелся нешуточный холивар на тему "списывать время или нет?" Вопрос и правда очень интересный, давно хочу про него написать на Хабре, но он требует нешуточной подготовки. Поэтому статью обещаю к новому году, но это…
Тут в комментариях разгорелся нешуточный холивар на тему "списывать время или нет?" Вопрос и правда очень интересный, давно хочу про него написать на Хабре, но он требует нешуточной подготовки. Поэтому статью обещаю к новому году, но это…
Forwarded from Korenev AI - GPT в тапочках🩴
Я проводил МК для своего друга-режиссера. У него был запрос на преодоление творческого ступора при создании сценариев.
Прикладываю обработанную транскрибацию, вдруг кого-то натолкнет на полезные мысли
Анализ существующих сценариев
Базовый подход:
Дополнительный анализ:
Можешь спросить: "В чем отличительная особенность этого сценария от большинства фильмов?"
ИИ подсветит неочевидные вещи, которые ты сам не смог формализовать
Генерация идей
На базе драфтов:
Объединяешь короткие драфты понравившихся сценариев
Просишь создать 10-20 веток коротких идей на основе этих особенностей
Указываешь важные для тебя элементы (трансформация героя и т.д.)
Работа с конкретным стилем:
Спрашиваешь про творчество конкретного режиссера (например, Тарантино)
Просишь описать его выдающиеся фильмы и их особенности
На основе этого просишь сочинить сценарий в его стиле
Методики для креатива
Используй креативные методологии:
Работа с книгами/методиками по сценарному делу:
Спрашиваешь: "Знаешь ли ты книгу [название]?"
Просишь перечислить основные постулаты
Просишь сформулировать сценарии на основе этих постулатов
Техника итеративной работы с LLM
Правильный промпт:
Неправильный подход:
Написал → получил чушь → написал новое сообщение "это чушь"
Получается длинная и бесмысленная колбаса, которая ни к чему не приводит
Работа с большими диалогами:
Можешь вернуться в самое начало, исправить текст, что создаст новую ветку обсуждения. Старая сохранится
Если сильно разрослось - попроси сформулировать основной запрос для нового чата
Копировать только релевантную информацию
Генерация вариантов
Массовая генерация:
Про температуру:
Показывает степень креативности
Высокая температура = непредсказуемость (может быть кринж или супер-креатив)
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Korenev AI - GPT в тапочках🩴
Продолжим ликбез для новичков.
Сервисы бесплатны, но в большинстве случаев требуется VPN.
Клод не стал указывать, т.к. новичкам нужно пройти целый квест связанный с регистрацией
Какой бы еще необходимый минимум вы бы сюда добавили?
Будьте креативны
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Miha
RAG из базы знаний Obsidian, может кому пригодится
https://github.com/glowingjade/obsidian-smart-composer
https://github.com/glowingjade/obsidian-smart-composer
GitHub
GitHub - glowingjade/obsidian-smart-composer: AI chat assistant for Obsidian with contextual awareness, smart writing assistance…
AI chat assistant for Obsidian with contextual awareness, smart writing assistance, and one-click edits. Features vault-aware conversations, semantic search, and local model support. - glowingjade/...
Forwarded from Korenev AI - GPT в тапочках🩴
Ребят, поделитесь плз 3-5 самыми полезными фичами в Обсидиане, которые чаще всего юзаете. Так, думаю, мы прекрасно сможем обменяться опытом его использования.
Для меня это:
А еще интересно было бы увидеть человека, который реально внедрил у себя zettelcasten. И вообще, нужен ли этот подход с появлением RAG?
В каментах Михаил @pljas поделился ссылкой на плагин для обсидиана, который существенно расширяет возможности за счет подключения LLM. С ним Обсидиан получает функции Курсора: генерация текста, контроль за изменениями, MCP, RAG!
Рекомендую по ссылке немного поскролить и посмотреть видосы с демонстрацией
Не забудьте отсыпать Михаилу огоньков!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from yulia
Советую пройти курс на степик «быстрый старт в искусственный интеллект» от мфти
Хотя бы базу закроешь
Если нужно еще пандас нампи и более школьный вариант, то курс «ИИ старт» также на степике
Хотя бы базу закроешь
Если нужно еще пандас нампи и более школьный вариант, то курс «ИИ старт» также на степике
Forwarded from IT путь
СОБЕС В МЕГАФОН🟢
SENIOR DATA ENGINEER
На удивление прошёл неплохо. Команда интересная. Собесили 2 лида: лид команды разработки, HR и лид, как я понял, со стороны бизнеса.
Вопросы задавал только лид разработки и HR. Было 3 секции:
1️⃣ О себе (прошлый опыт) + почему уходишь + что ищешь;
2️⃣ Тех вопросы (теория БД);
3️⃣ Лайвкод.
Банально, но адекватно, по делу - и это круто.
Так как общались в границах определённого типа архитектуры БД (DATA_VAULT-2.0), то вопросы были соответствующие:
1️⃣ Мои принципы проектирования ETL, сложные кейсы. (А Я НИЧО НЕ ВСПОМНИЛ СЛОЖНОГО);
2️⃣ Принципы секционирования таблиц. Какие вообще бывают виды партиций (а вот тут я всё нафиг забыл. Ну что сказать... кто вообще теорию держит в голове, кроме студентов ?);
3️⃣ Принципы SCD;
4️⃣ Динамический SQL;
5️⃣ Немного аналитики. Оконки;
6️⃣ Обсуждение плана запроса. Как выполнять, какой из 2 видов является
А дальше мы погнали в задачи.
🌁 🌁 🌁 🌁 🌃 🌁 задача была банальной. Там надо было по классике вывести те отделы, в которых нет сотрудников. Её не буду показывать, так как она и без того самая популярная, пожалуй. Однако, должен признать, мои навыки решения задач весьма хреновые - я решил её не за 1 секунду, как этого ожидают от синеваров, а за минут 5 наверно.
🌁 🌁 🌁 🌁 🌃 🌁 задача тоже многим знакома, но всё же она на "подумать". Задача решается в 2 этапа - определить где ошибка, исправить ошибку.
ИТАК.... Перед нами таблица таргетного слоя, хранящая айди факта и даты его его начала и завершенеия. Построена как раз по одному из SCD принципов.
Каждая строка - это момент жизни одного (в данном случае первого) факта. В каждой строке отображено начало жизни версии факта и окончание. В какой-то момент мы видим, что даты сбиваются. Сразу объясню: эти даты фиксируются автоматически в ETL процессе и дата окончания одной версии является датой начала следующей версии (в следующей строке). Поэтому между окончанием и строй версии и началом новой версии не может быть разрыва. А значит "начало" проблемы мы видим в строке №3. Она должна была начаться с '01.01.2023 11:15:00'.
ЗАДАНИЕ: нам надо написать SQL скрипт, который поставит эти даты правильным образом. Ещё раз - дата конца одной строки - это дата начала следующей строки.
KEY_ID START_DATE END_DATE
-------— ------------------- -------------------
1 01.01.1900 00:00:00 01.01.2022 13:43:00
1 01.01.2022 13:43:00 01.01.2023 11:15:00
1 01.01.2023 13:43:00 18.10.2023 11:08:54
1 01.01.2023 13:44:00 18.10.2023 11:07:54
1 18.10.2023 11:08:54 31.12.2999 23:59:59
На решение этой задачи я тоже потратил много времени. Где-то минут 10. Но зато решил без тренировок, без насмотренности😏
Предлагаю вам самостоятельно решить её в качестве очередной тренировки.
Подсказка: решать проще и лучше через оконку)
РЕШЕНИЕ ДАМ В СЛЕДУЮЩЕМ ПОСТЕ😏
SENIOR DATA ENGINEER
На удивление прошёл неплохо. Команда интересная. Собесили 2 лида: лид команды разработки, HR и лид, как я понял, со стороны бизнеса.
Вопросы задавал только лид разработки и HR. Было 3 секции:
Банально, но адекватно, по делу - и это круто.
Так как общались в границах определённого типа архитектуры БД (DATA_VAULT-2.0), то вопросы были соответствующие:
А дальше мы погнали в задачи.
ИТАК.... Перед нами таблица таргетного слоя, хранящая айди факта и даты его его начала и завершенеия. Построена как раз по одному из SCD принципов.
Каждая строка - это момент жизни одного (в данном случае первого) факта. В каждой строке отображено начало жизни версии факта и окончание. В какой-то момент мы видим, что даты сбиваются. Сразу объясню: эти даты фиксируются автоматически в ETL процессе и дата окончания одной версии является датой начала следующей версии (в следующей строке). Поэтому между окончанием и строй версии и началом новой версии не может быть разрыва. А значит "начало" проблемы мы видим в строке №3. Она должна была начаться с '01.01.2023 11:15:00'.
ЗАДАНИЕ: нам надо написать SQL скрипт, который поставит эти даты правильным образом. Ещё раз - дата конца одной строки - это дата начала следующей строки.
KEY_ID START_DATE END_DATE
-------— ------------------- -------------------
1 01.01.1900 00:00:00 01.01.2022 13:43:00
1 01.01.2022 13:43:00 01.01.2023 11:15:00
1 01.01.2023 13:43:00 18.10.2023 11:08:54
1 01.01.2023 13:44:00 18.10.2023 11:07:54
1 18.10.2023 11:08:54 31.12.2999 23:59:59
На решение этой задачи я тоже потратил много времени. Где-то минут 10. Но зато решил без тренировок, без насмотренности
Предлагаю вам самостоятельно решить её в качестве очередной тренировки.
Подсказка: решать проще и лучше через оконку)
РЕШЕНИЕ ДАМ В СЛЕДУЮЩЕМ ПОСТЕ
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from This is Data
Как эффективно взаимодействовать с ИИ
Недавно я проводил опрос, и 88% подписчиков канала ответили, что используют ИИ-чаты для решения каких-либо задач. А 19% делегируют ИИ даже ежедневную рабочую рутину. Цифры впечатляют.
Но как чаще всего выглядит это общение? Мы задаем какой-то вопрос, пишем призыв «сделай то-то и то-то», чуть уточняем и все. На самом деле можно получать гораздо более качественный результат, для этого существует такая штука, как промпт-инжиниринг.
Промпт-инжиниринг – это искусство создания эффективных запросов (промптов) для взаимодействия с большими языковыми моделями (LLM), такими как ChatGPT.
Умение составить качественный промпт помогает раскрывать весь огромный потенциал ИИ.
Основные техники
1. Zero-shot prompting – запрос без примеров. Модель должна понять задачу и попытаться ответить.
2. Few-shot prompting – запрос с несколькими примерами. Модель получает образцы правильных ответов, что помогает ей лучше понять задачу.
3. Chain-of-thought prompting – пошаговое рассуждение. Модель объясняет свой процесс мышления, что улучшает качество и прозрачность ответа.
4. Role prompting – задание роли. Указание модели определённой роли (например, «ты эксперт по статистике») помогает получить более целенаправленные ответы.
5. Context-enhanced prompting – использование контекста. Предоставление модели дополнительной информации о задаче или ситуации улучшает релевантность ее ответов.
Примеры использования
Zero-shot:
→ Модель даст общий обзор, понятный новичку.
Few-shot:
→ Модель ориентируется на стиль и уровень объяснения.
Chain-of-thought:
→ Модель подробно описывает последовательность действий и логику анализа.
Role + Context-enhanced:
→ Модель выдаёт экспертный разбор с конкретным примером, максимально приближённым к реальной задаче.
Что почитать?
▪️Руководство по промпт-инжинирингу – отличная база с примерами и техниками.
▪️Книга «The Art of Prompt Engineering» – практическое руководство с кейсами и советами.
ИИ-чаты уже стали частью нашей работы и жизни. Пока они не способны заменить человека, но это мощный инструмент автоматизации. Главное – уметь им правильно пользоваться. Экспериментируйте с промптами и выжимайте из ИИ максимум.
#опыт
Недавно я проводил опрос, и 88% подписчиков канала ответили, что используют ИИ-чаты для решения каких-либо задач. А 19% делегируют ИИ даже ежедневную рабочую рутину. Цифры впечатляют.
Но как чаще всего выглядит это общение? Мы задаем какой-то вопрос, пишем призыв «сделай то-то и то-то», чуть уточняем и все. На самом деле можно получать гораздо более качественный результат, для этого существует такая штука, как промпт-инжиниринг.
Промпт-инжиниринг – это искусство создания эффективных запросов (промптов) для взаимодействия с большими языковыми моделями (LLM), такими как ChatGPT.
Умение составить качественный промпт помогает раскрывать весь огромный потенциал ИИ.
Основные техники
1. Zero-shot prompting – запрос без примеров. Модель должна понять задачу и попытаться ответить.
2. Few-shot prompting – запрос с несколькими примерами. Модель получает образцы правильных ответов, что помогает ей лучше понять задачу.
3. Chain-of-thought prompting – пошаговое рассуждение. Модель объясняет свой процесс мышления, что улучшает качество и прозрачность ответа.
4. Role prompting – задание роли. Указание модели определённой роли (например, «ты эксперт по статистике») помогает получить более целенаправленные ответы.
5. Context-enhanced prompting – использование контекста. Предоставление модели дополнительной информации о задаче или ситуации улучшает релевантность ее ответов.
Примеры использования
Zero-shot:
Объясни p-value простыми словами.
→ Модель даст общий обзор, понятный новичку.
Few-shot:
Вот несколько примеров объяснения статистических понятий:
1. Среднее значение – это статистический показатель, который характеризует типичную величину набора числовых данных.
2. Дисперсия – это показатель разброса данных вокруг их среднего значения.
Теперь объясни p-value аналогичным образом.
→ Модель ориентируется на стиль и уровень объяснения.
Chain-of-thought:
Объясни p-value, рассуждая пошагово, чтобы я понял, как его вычисляют и как интерпретируют результаты A/B теста.
→ Модель подробно описывает последовательность действий и логику анализа.
Role + Context-enhanced:
Ты аналитик в финтех-компании. Мы проводим A/B тесты. Объясни p-value так, чтобы я понял его практическое значение и математическую интерпретацию. Приведи пример на основе сравнения двух выборок.
→ Модель выдаёт экспертный разбор с конкретным примером, максимально приближённым к реальной задаче.
Что почитать?
▪️Руководство по промпт-инжинирингу – отличная база с примерами и техниками.
▪️Книга «The Art of Prompt Engineering» – практическое руководство с кейсами и советами.
ИИ-чаты уже стали частью нашей работы и жизни. Пока они не способны заменить человека, но это мощный инструмент автоматизации. Главное – уметь им правильно пользоваться. Экспериментируйте с промптами и выжимайте из ИИ максимум.
#опыт