Forwarded from LLM под капотом
Почему в последнее время в канале больше постов про AI+Coding, чем про продукты с LLM под капотом?
Потому, что актуальных проблем с AI+Coding сейчас больше, чем с разработкой продуктов. Тут есть две причины.
Во-первых, паттерны самых типовых и удачных проектов для внедрения в бизнес - уже известны. Это: (1) Data Extraction и (2) Search Assistants
Мы их уже обсуждали в канале не раз (см оглавление разборов кейсов). Берется LLM посовременней (лучше сразу VLM, если надо с PDF работать), добавляется туда обязательно Structured Output, а в схему прописывается Custom Chain-of-Thought в виде Checklist. Все!
Этого достаточно для реализации больших и дорого выглядящих проектов вроде “автоматизация поиска ошибок во входящих purchase orders”, “медицинский ассистент для приема больных”, “сопоставление номенклатур компонентов между поставщиками (чтобы следить за рынком и продавать быстрее)” и тому подобное.
Да, есть всякие copilots, RAGs, reasoning workflows, agents, но там требуется куда больше телодвижений, риски больше, а прибыльность меньше.
Так что знакомые мне компании и команды пока скучно копошатся и осваивают открывшийся им объем работ с относительно безрисковыми подходами. Принципиально новых кейсов пока нет, но вот дел очень много. Все упирается в разработку и нехватку специалистов, которые могут комфортно разрабатывать системы с LLM под капотом.
И вот это как раз ведет ко второй причине - AI+Coding - это как раз тот инструмент, который может частично компенсировать нехватку “грубой” рабочей силы и разгрузить специалистов. AI не заменяет разработчиков, просто позволяет занять им место “повыше” - вместо проверки вариантов вручную, исследований, поиска проблем, можно сэкономить время и отдать задачи джунам в виде десятка AI Agents. Это ускоряет итерации и улучшает прибыльность. Примерно получается ускорение 5x-7x (дальше - упираемся в самих специалистов).
Но есть нюанс - тут надо многому учиться, а это - процесс небыстрый. Разработчикам надо учиться как использовать современные AI инструменты эффективно, чтобы они помогали, а не наворачивали дел. А мне самому надо учиться тому, как эти команды разработчиков учить. Ведь мало что-то наглядно показать, надо еще помочь уложить в систему, закрепить полученный материал, отработать на практике и проверить.
Поэтому у меня в последние месяцы голова болит больше про AI+Coding, чем про продукты с LLM под капотом. Реализация единичных AI продуктов в компаниях сейчас уже не такая большая проблема, как масштабирование всего этого процесса вширь.
И что-то говорит, что дальше будет еще веселее.
Ваш, @llm_under_hood 🤗
Потому, что актуальных проблем с AI+Coding сейчас больше, чем с разработкой продуктов. Тут есть две причины.
Во-первых, паттерны самых типовых и удачных проектов для внедрения в бизнес - уже известны. Это: (1) Data Extraction и (2) Search Assistants
Мы их уже обсуждали в канале не раз (см оглавление разборов кейсов). Берется LLM посовременней (лучше сразу VLM, если надо с PDF работать), добавляется туда обязательно Structured Output, а в схему прописывается Custom Chain-of-Thought в виде Checklist. Все!
Этого достаточно для реализации больших и дорого выглядящих проектов вроде “автоматизация поиска ошибок во входящих purchase orders”, “медицинский ассистент для приема больных”, “сопоставление номенклатур компонентов между поставщиками (чтобы следить за рынком и продавать быстрее)” и тому подобное.
Да, есть всякие copilots, RAGs, reasoning workflows, agents, но там требуется куда больше телодвижений, риски больше, а прибыльность меньше.
Так что знакомые мне компании и команды пока скучно копошатся и осваивают открывшийся им объем работ с относительно безрисковыми подходами. Принципиально новых кейсов пока нет, но вот дел очень много. Все упирается в разработку и нехватку специалистов, которые могут комфортно разрабатывать системы с LLM под капотом.
И вот это как раз ведет ко второй причине - AI+Coding - это как раз тот инструмент, который может частично компенсировать нехватку “грубой” рабочей силы и разгрузить специалистов. AI не заменяет разработчиков, просто позволяет занять им место “повыше” - вместо проверки вариантов вручную, исследований, поиска проблем, можно сэкономить время и отдать задачи джунам в виде десятка AI Agents. Это ускоряет итерации и улучшает прибыльность. Примерно получается ускорение 5x-7x (дальше - упираемся в самих специалистов).
Но есть нюанс - тут надо многому учиться, а это - процесс небыстрый. Разработчикам надо учиться как использовать современные AI инструменты эффективно, чтобы они помогали, а не наворачивали дел. А мне самому надо учиться тому, как эти команды разработчиков учить. Ведь мало что-то наглядно показать, надо еще помочь уложить в систему, закрепить полученный материал, отработать на практике и проверить.
Поэтому у меня в последние месяцы голова болит больше про AI+Coding, чем про продукты с LLM под капотом. Реализация единичных AI продуктов в компаниях сейчас уже не такая большая проблема, как масштабирование всего этого процесса вширь.
И что-то говорит, что дальше будет еще веселее.
Ваш, @llm_under_hood 🤗
Forwarded from Quant Valerian
Майндсет тимлида и его руководителя
Большинство тимлидов занимают ролевую модель папочки для своих сотрудников. Это такие маленькие, сплоченные коллективы, которые чувствуют, что живут в страшном и жестоком мире, где все, кто не входит в команду, пытаются их обмануть, сожрать и унизить. Тимлиды же никого подпускают к своим ребятам, закрывают их грудью, принимая на себя все летящие снаружи вопросы, претензии и задачи. Любой ценой нужно недопустить, чтобы злой проджект навалил в спринт своих задач побольше. Всеми силами экономить энергию и время своих ребят, отбивая задачи в смежников или в небытие. И сотрудники таких тимлидов, обычно, любят, потому что чувствуют, как за них врубаются, потому что имеют время на технические, интересные задачки, потому что общий враг, в принципе, хорошо сплочает коллективы.
А вот тимлид тимлидов смотрит на картину несколько иначе. Со стороны выглядит, что он делает то же самое: отбивает какие-то задачи и проекты в смежников или небытие, отдувается перед топами на всевозможных разносах, защищая команды. Но на самом деле, есть очень существенное отличие. Если о нем не задумываться, то поведение М2 менеджера может казаться тимлидам нелогичным.
Разница очень простая, но очень важная. М2 думает, как должно быть хорошо и правильно. Если он отбивает задачу в смежников, то не для защиты своих команд от переработок, а потому что считает, что это выгоднее для компании (или проекта) в целом. Например, экспертиза должны находиться в другом месте или смежники могут сделать быстрее, а уже горит. Если он отбивает задачу совсем, то, вероятно, считает, что она только навредит. Может, ROI плохой, может, не вписывается в целевую архитектуру, может, противоречит стратегии.
Вообще видение такое, что вокруг не враги, а люди, с ограниченными контекстами. И ты сам с ограниченным контекстом. И вам надо достичь какой-то общей большой цели, но вы каждый видите свои пути. И вот надо всем объяснить, что ты не враг. Показать свой контекст. Убедить их показать свои тебе. И дальше договариваться, как же поступить оптимально. И это непрерывная работа.
Но иногда, даже держа в голове эти мысли, тимлид может решить, что М2 ведёт какую-то хитрую политическую игру, ведь решения всё ещё не логичны. Может и так. Но скорее всего, М2 просто подумал на много шагов вперед и учел риски, которые тимлиду даже в голову не приходили (он банально меньше знает вширь, но больше вглубь, да).
В целом, я, например, даже пытаюсь объяснять свои решения тимлидам. Но, во-первых, не всегда об этом думаю, во-вторых, не всегда нахожу силы, в-третьих, всё равно иногда вижу реакцию типа "ага, ну я понял, как _на_самом_деле_, но буду транслировать твою версию, я тебя раскусил".
М2 это работать почти никак не мешает. Просто иногда тимлидов заносит и надо их поправлять. А вот тимлиду изменение майндсета на М2 может помочь вырасти на следующую ступеньку.
P.S.:
Kind reminder, что вы можете связаться со мной через бота в описании, он звездочек не просит.
Большинство тимлидов занимают ролевую модель папочки для своих сотрудников. Это такие маленькие, сплоченные коллективы, которые чувствуют, что живут в страшном и жестоком мире, где все, кто не входит в команду, пытаются их обмануть, сожрать и унизить. Тимлиды же никого подпускают к своим ребятам, закрывают их грудью, принимая на себя все летящие снаружи вопросы, претензии и задачи. Любой ценой нужно недопустить, чтобы злой проджект навалил в спринт своих задач побольше. Всеми силами экономить энергию и время своих ребят, отбивая задачи в смежников или в небытие. И сотрудники таких тимлидов, обычно, любят, потому что чувствуют, как за них врубаются, потому что имеют время на технические, интересные задачки, потому что общий враг, в принципе, хорошо сплочает коллективы.
А вот тимлид тимлидов смотрит на картину несколько иначе. Со стороны выглядит, что он делает то же самое: отбивает какие-то задачи и проекты в смежников или небытие, отдувается перед топами на всевозможных разносах, защищая команды. Но на самом деле, есть очень существенное отличие. Если о нем не задумываться, то поведение М2 менеджера может казаться тимлидам нелогичным.
Разница очень простая, но очень важная. М2 думает, как должно быть хорошо и правильно. Если он отбивает задачу в смежников, то не для защиты своих команд от переработок, а потому что считает, что это выгоднее для компании (или проекта) в целом. Например, экспертиза должны находиться в другом месте или смежники могут сделать быстрее, а уже горит. Если он отбивает задачу совсем, то, вероятно, считает, что она только навредит. Может, ROI плохой, может, не вписывается в целевую архитектуру, может, противоречит стратегии.
Вообще видение такое, что вокруг не враги, а люди, с ограниченными контекстами. И ты сам с ограниченным контекстом. И вам надо достичь какой-то общей большой цели, но вы каждый видите свои пути. И вот надо всем объяснить, что ты не враг. Показать свой контекст. Убедить их показать свои тебе. И дальше договариваться, как же поступить оптимально. И это непрерывная работа.
Но иногда, даже держа в голове эти мысли, тимлид может решить, что М2 ведёт какую-то хитрую политическую игру, ведь решения всё ещё не логичны. Может и так. Но скорее всего, М2 просто подумал на много шагов вперед и учел риски, которые тимлиду даже в голову не приходили (он банально меньше знает вширь, но больше вглубь, да).
В целом, я, например, даже пытаюсь объяснять свои решения тимлидам. Но, во-первых, не всегда об этом думаю, во-вторых, не всегда нахожу силы, в-третьих, всё равно иногда вижу реакцию типа "ага, ну я понял, как _на_самом_деле_, но буду транслировать твою версию, я тебя раскусил".
М2 это работать почти никак не мешает. Просто иногда тимлидов заносит и надо их поправлять. А вот тимлиду изменение майндсета на М2 может помочь вырасти на следующую ступеньку.
P.S.:
Kind reminder, что вы можете связаться со мной через бота в описании, он звездочек не просит.
Forwarded from Pattern Guru. Шаблоны проектирования. Архитектура ПО
Фабричный метод — это порождающий паттерн проектирования, который определяет общий интерфейс для создания объектов в суперклассе, позволяя подклассам изменять тип создаваемых объектов.
from __future__ import annotations
from abc import ABC, abstractmethod
class Creator(ABC):
"""
Класс Создатель объявляет фабричный метод, который должен возвращать объект
класса Продукт. Подклассы Создателя обычно предоставляют реализацию этого
метода.
"""
@abstractmethod
def factory_method(self):
"""
Обратите внимание, что Создатель может также обеспечить реализацию
фабричного метода по умолчанию.
"""
pass
def some_operation(self) -> str:
"""
Также заметьте, что, несмотря на название, основная обязанность
Создателя не заключается в создании продуктов. Обычно он содержит
некоторую базовую бизнес-логику, которая основана на объектах Продуктов,
возвращаемых фабричным методом. Подклассы могут косвенно изменять эту
бизнес-логику, переопределяя фабричный метод и возвращая из него другой
тип продукта.
"""
# Вызываем фабричный метод, чтобы получить объект-продукт.
product = self.factory_method()
# Далее, работаем с этим продуктом.
result = f"Creator: The same creator's code has just worked with {product.operation()}"
return result
"""
Конкретные Создатели переопределяют фабричный метод для того, чтобы изменить тип
результирующего продукта.
"""
class ConcreteCreator1(Creator):
"""
Обратите внимание, что сигнатура метода по-прежнему использует тип
абстрактного продукта, хотя фактически из метода возвращается конкретный
продукт. Таким образом, Создатель может оставаться независимым от конкретных
классов продуктов.
"""
def factory_method(self) -> Product:
return ConcreteProduct1()
class ConcreteCreator2(Creator):
def factory_method(self) -> Product:
return ConcreteProduct2()
class Product(ABC):
"""
Интерфейс Продукта объявляет операции, которые должны выполнять все
конкретные продукты.
"""
@abstractmethod
def operation(self) -> str:
pass
"""
Конкретные Продукты предоставляют различные реализации интерфейса Продукта.
"""
class ConcreteProduct1(Product):
def operation(self) -> str:
return "{Result of the ConcreteProduct1}"
class ConcreteProduct2(Product):
def operation(self) -> str:
return "{Result of the ConcreteProduct2}"
def client_code(creator: Creator) -> None:
"""
Клиентский код работает с экземпляром конкретного создателя, хотя и через
его базовый интерфейс. Пока клиент продолжает работать с создателем через
базовый интерфейс, вы можете передать ему любой подкласс создателя.
"""
print(f"Client: I'm not aware of the creator's class, but it still works.\n"
f"{creator.some_operation()}", end="")
if __name__ == "__main__":
print("App: Launched with the ConcreteCreator1.")
client_code(ConcreteCreator1())
print("\n")
print("App: Launched with the ConcreteCreator2.")
client_code(ConcreteCreator2())
Forwarded from Korenev AI - GPT в тапочках🩴
Пообщался с Клодом на тему идей для ИИ-сервисов. В промпте попросил изучить опыт Y Combinator и Product Hunt, и при описании идей помнить про product market fit (соответствие продукта рынку, далее - PMF)
Ответы:
Самый быстрорастущий сегмент - инструменты для улучшения существующих AI-систем компаний
Рекомендую сфокусироваться на создании инструментов, которые усиливают существующие AI-системы, а не конкурируют с ними напрямую. Это главный тренд Y Combinator W25.
Основываясь на анализе успешных кейсов из Product Hunt и Y Combinator, вот 15 идей продуктов, усиливающих существующие AI-системы с доказанным product-market fit:
AI Output Validator
Проблема: Компании используют ChatGPT/Claude для генерации контента, но 30% выходных данных содержат фактические ошибки или галлюцинации
Решение: API-сервис, который проверяет AI-генерированный контент на факты, консистентность и соответствие бренду
Модель: $49/месяц для стартапов, $299/месяц enterprise
PMF: Browser Use получил 28,000 загрузок за неделю, показывая спрос на инструменты контроля AI
Prompt Performance Analytics
Проблема: Компании тратят тысячи долларов на API OpenAI/Anthropic, не понимая какие промпты работают
Решение: Дашборд отслеживающий эффективность промптов, A/B тестирование, оптимизация затрат
Модель: 2% от сэкономленных API-затрат
PMF: 25% YC стартапов используют AI для 95% кода - им критически нужна оптимизация
AI Agent Memory Layer
Проблема: AI-агенты "забывают" контекст между сессиями, компании теряют историю взаимодействий
Решение: Универсальная память для любых AI-агентов с векторным поиском и контекстным извлечением
Модель: $0.001 за сохраненное взаимодействие
PMF: Abundant из YC W25 показал спрос на улучшение AI-агентов
Multi-AI Orchestrator
Проблема: Компании используют 5-10 разных AI-инструментов (ChatGPT для текста, Midjourney для изображений, ElevenLabs для голоса)
Решение: Единый API orchestrating между всеми AI-сервисами с оптимизацией маршрутизации
Модель: $99/месяц + 10% markup на API-вызовы
PMF: Melies (из анализа Product Hunt) интегрирует множество AI для создания фильмов
AI Cost Guard
Проблема: Неконтролируемые AI-агенты могут сжечь $10,000+ за ночь на API-вызовах
Решение: Real-time мониторинг и автоматические лимиты для всех AI API с алертами
Модель: Freemium с $29/месяц Pro для неограниченных endpoints
PMF: С ростом "vibe coding" критически важен контроль затрат
Compliance Filter for AI
Проблема: AI генерирует контент нарушающий GDPR, HIPAA или корпоративные политики
Решение: Middleware фильтрующий input/output AI на соответствие регуляциям
Модель: $199/месяц для healthcare, $499/месяц для финансов
PMF: YC W25 показал рост AI в традиционных индустриях требующих compliance
AI Training Data Marketplace
Проблема: Компании хотят fine-tune модели, но не имеют качественных датасетов
Решение: Маркетплейс проверенных, лицензированных данных для обучения по индустриям
Модель: 20% комиссия с транзакций
PMF: FLUX успех показал спрос на специализированные модели
Prompt Templates Store
Проблема: Каждая компания изобретает велосипед с промптами для типовых задач
Решение: Магазин проверенных, оптимизированных промптов с метриками эффективности
Модель: $4.99 за промпт или $49/месяц безлимит
PMF: Flowdrafter показал что простые, focused решения побеждают
AI Output Humanizer
Проблема: AI-контент легко детектируется и выглядит "роботизированным"
Решение: Сервис добавляющий человеческие нюансы в AI-генерированный контент
Модель: $0.02 за 100 слов
PMF: С ростом AI-детекторов критически важна "гуманизация"
Cross-AI Context Bridge
Проблема: Переключение между ChatGPT, Claude, Gemini требует копирования всего контекста
Решение: Браузерное расширение синхронизирующее контекст между всеми AI-чатами
Модель: $9.99/месяц
PMF: Пользователи Product Hunt активно используют множество AI одновременно
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Korenev AI - GPT в тапочках🩴
AI Performance Benchmarker
Проблема: Непонятно какая модель лучше для конкретной бизнес-задачи
Решение: Автоматическое тестирование задачи на 10+ моделях с отчетом
Модель: $19 за бенчмарк
PMF: Artificial Analysis популярность показывает спрос на сравнения
Smart AI Router
Проблема: GPT-4o избыточен для простых задач, но GPT-3.5 недостаточен для сложных
Решение: Автоматический роутинг запросов к оптимальной модели по цене/качеству
Модель: Экономим 40% затрат, берем 50% от экономии
PMF: При $10-30/месяц за AI критична оптимизация
AI Hallucination Insurance
Проблема: Бизнес боится использовать AI для критичных задач из-за риска ошибок
Решение: Страховка покрывающая убытки от AI-галлюцинаций с проверкой выходных данных
Модель: 2% от объема обрабатываемых AI транзакций
PMF: Новая ниша с огромным потенциалом для B2B
Collaborative AI Workspace
Проблема: Команды не могут эффективно работать с AI вместе, дублируют промпты
Решение: Shared workspace для командной работы с AI, история, шаблоны, права доступа
Модель: $15/пользователь/месяц
PMF: YC тренд на AI-first команды требует коллаборации
AI Output Version Control
Проблема: Компании теряют track изменений в AI-генерированном контенте
Решение: Git для AI outputs с diff, merge, rollback функциональностью
Модель: $29/месяц для команд до 10 человек
PMF: С 95% AI-генерированным кодом критичен контроль версий
Сохрани - миллионером станешь! ну или хотябы тысячанером😄
Если есть желание инвестировать в ИИ-проекты - просьба написать мне @KottAlex
Проблема: Непонятно какая модель лучше для конкретной бизнес-задачи
Решение: Автоматическое тестирование задачи на 10+ моделях с отчетом
Модель: $19 за бенчмарк
PMF: Artificial Analysis популярность показывает спрос на сравнения
Smart AI Router
Проблема: GPT-4o избыточен для простых задач, но GPT-3.5 недостаточен для сложных
Решение: Автоматический роутинг запросов к оптимальной модели по цене/качеству
Модель: Экономим 40% затрат, берем 50% от экономии
PMF: При $10-30/месяц за AI критична оптимизация
AI Hallucination Insurance
Проблема: Бизнес боится использовать AI для критичных задач из-за риска ошибок
Решение: Страховка покрывающая убытки от AI-галлюцинаций с проверкой выходных данных
Модель: 2% от объема обрабатываемых AI транзакций
PMF: Новая ниша с огромным потенциалом для B2B
Collaborative AI Workspace
Проблема: Команды не могут эффективно работать с AI вместе, дублируют промпты
Решение: Shared workspace для командной работы с AI, история, шаблоны, права доступа
Модель: $15/пользователь/месяц
PMF: YC тренд на AI-first команды требует коллаборации
AI Output Version Control
Проблема: Компании теряют track изменений в AI-генерированном контенте
Решение: Git для AI outputs с diff, merge, rollback функциональностью
Модель: $29/месяц для команд до 10 человек
PMF: С 95% AI-генерированным кодом критичен контроль версий
Сохрани - миллионером станешь! ну или хотябы тысячанером
Если есть желание инвестировать в ИИ-проекты - просьба написать мне @KottAlex
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Всеволод Викулин | AI разбор
Почему в AI много демок и мало внедрений
Я думаю, весь AI это ровно про это.
Как вы думаете, когда начали ездить первые self driving cars? В 90-х годах двадцатого века. Они ездили по настоящей дороге, могли поворачивать. Бибикали. Иногда даже успешно.
Можете посмотреть на список прогнозов Илона Маска, когда уже появится автономный транспорт. Пока мы ждем.
Почему так
AI вероятностная штука. Модели просто выучить самые частотные закономерности в данных, она будет идеально работать на простых кейсах. Эти простые кейсы проще всего и показать в демке: взял два примера, показал, что работает, поднял раунд, пошел масштабироваться. Это еще называется cherry picking: выбираем для демок только самые сладкие вишенки.
В реальном продукте есть длиннющий хвост сложных примеров. Адский ливень, безумное движение соседних машин, стадо коров на дороге... На таких аномальных примерах поведение системы может резко ломаться. Такие примеры не показывают на демках, но они регулярно появляются у пользователей, которые потом начинают отписываться от вашего продукта.
Как демку превратить в продукт
Серия шагов:
1) Научиться замерять качество.
В разных сценариях, в метель, в дождь и песчаную бурю. Чтобы вы точно знали, с какой вероятностью ваша система развалится.
2) Оценить риски.
Сколько будет стоить каждый тип ошибки. Для чат бота ошибиться в вопросе, как пройти в библиотек, не тоже самое, что случайно списать ваши деньги. Зная вероятность ошибки - считай риск.
3) Если не принял риск - подключай человека.
В автономном транспорте есть 6 уровней автоматизации. При чем реально автономны только последние 2 уровня.
Для AI-приложений можно делать также. Отлично работает паттерн “human in the loop”, о котором мы говорим в постах по LLM System Design.
Обязательная литература
- Обзорная статья, как бороться с ненадежностью LLM
- Пост про правильный UI для повышения надежности агентов
Любые вопросы обязательно пишите в комментарии.
Если нужно обсудить конкретно ваш случай - пишите вопрос в личные сообщения.
Существует целый класс задач, в которых очень просто сделать демо, но невероятно сложно сделать настоящий продукт. (Андрей Карпатый)
Я думаю, весь AI это ровно про это.
Как вы думаете, когда начали ездить первые self driving cars? В 90-х годах двадцатого века. Они ездили по настоящей дороге, могли поворачивать. Бибикали. Иногда даже успешно.
Можете посмотреть на список прогнозов Илона Маска, когда уже появится автономный транспорт. Пока мы ждем.
Почему так
AI вероятностная штука. Модели просто выучить самые частотные закономерности в данных, она будет идеально работать на простых кейсах. Эти простые кейсы проще всего и показать в демке: взял два примера, показал, что работает, поднял раунд, пошел масштабироваться. Это еще называется cherry picking: выбираем для демок только самые сладкие вишенки.
В реальном продукте есть длиннющий хвост сложных примеров. Адский ливень, безумное движение соседних машин, стадо коров на дороге... На таких аномальных примерах поведение системы может резко ломаться. Такие примеры не показывают на демках, но они регулярно появляются у пользователей, которые потом начинают отписываться от вашего продукта.
Как демку превратить в продукт
Серия шагов:
1) Научиться замерять качество.
В разных сценариях, в метель, в дождь и песчаную бурю. Чтобы вы точно знали, с какой вероятностью ваша система развалится.
2) Оценить риски.
Сколько будет стоить каждый тип ошибки. Для чат бота ошибиться в вопросе, как пройти в библиотек, не тоже самое, что случайно списать ваши деньги. Зная вероятность ошибки - считай риск.
3) Если не принял риск - подключай человека.
В автономном транспорте есть 6 уровней автоматизации. При чем реально автономны только последние 2 уровня.
Для AI-приложений можно делать также. Отлично работает паттерн “human in the loop”, о котором мы говорим в постах по LLM System Design.
Обязательная литература
- Обзорная статья, как бороться с ненадежностью LLM
- Пост про правильный UI для повышения надежности агентов
Любые вопросы обязательно пишите в комментарии.
Если нужно обсудить конкретно ваш случай - пишите вопрос в личные сообщения.
Forwarded from r/ретранслятор
Реддитор поделился промтом для ChatGPT, который заметно повышает качество ответов:
Когда чат-бот чего-то не знает, то обычно начинает угадывать — и это может серьёзно всё испортить.
Данный промт активирует у ChatGPT внутренний механизм проверки — он начинает оценивать риск ошибки и искать недостающую информацию, что резко повышает точность и осмысленность ответа.
Сохраняйте и пробуйте
r/#ChatGPTPromptGenius
Прежде чем ответить, оцени неопределённость своего ответа. Если она больше 0.1, задай мне уточняющие вопросы, пока она не станет 0.1 или ниже.
Когда чат-бот чего-то не знает, то обычно начинает угадывать — и это может серьёзно всё испортить.
Данный промт активирует у ChatGPT внутренний механизм проверки — он начинает оценивать риск ошибки и искать недостающую информацию, что резко повышает точность и осмысленность ответа.
Сохраняйте и пробуйте
r/#ChatGPTPromptGenius
Forwarded from Никита и его пшд (Nikita Durasov)
Ну и раз я вчера упомянул, что пока еще разбираюсь с последними проектами в универе, то вот один из них — у нас взяли статью на ✨ ICML в Ванкувере ✨ про новый Test-Time Training (если вкратце, то главная идея в том, что во время инференса мы апдейтим веса модели, оптимизируя какой-нибудь self-supervised лосс — это помогает модели быть более generalizable).
На самом деле, сама идея очень интересная и, как мне кажется, набирает обороты. Я сам пытаюсь её как-нибудь раскачивать (например, через эту torch-ttt либу, чекайте), о чём тоже хочу написать пару постов. Из более модного: я знаю, что TTT сейчас начали активно применять для увеличения длины контекстов у LLM-ок — об этом тоже как-нибудь напишу. Из моего опыта, TTT довольно часто может значительно улучшать перформанс модели на corrupted или out-of-distribution данных, а применять его довольно просто — это мы подробно обсудили в статье.
А вот тут будет призыв к действию: для нашей статьи я подготовил кучу материалов, включая видос ниже, где постарался в целом покрыть всю идею TTT. Я потратил слишком много времени в Manim-е, всё это верстая, поэтому просмотры / лайки будут highly appreciated. Ссылки на страницу статьи, посты, код и всё вот это — оставлю ниже.
Кому будет интересно, можете попробовать идею в этом ноутбуке.
📄 Paper: https://arxiv.org/abs/2410.04201
🧠 Project page: https://www.norange.io/projects/ittt/
💻 Code: https://github.com/nikitadurasov/ittt
🎬 Video: https://www.youtube.com/watch?v=eKGKpN8fFRM
🧩 torch-ttt class: https://torch-ttt.github.io/_autosummary/torch_ttt.engine.it3_engine.IT3Engine.html
🔬 Notebook: https://colab.research.google.com/github/nikitadurasov/ittt/blob/main/exps/mnist/it3_torch_ttt.ipynb
На самом деле, сама идея очень интересная и, как мне кажется, набирает обороты. Я сам пытаюсь её как-нибудь раскачивать (например, через эту torch-ttt либу, чекайте), о чём тоже хочу написать пару постов. Из более модного: я знаю, что TTT сейчас начали активно применять для увеличения длины контекстов у LLM-ок — об этом тоже как-нибудь напишу. Из моего опыта, TTT довольно часто может значительно улучшать перформанс модели на corrupted или out-of-distribution данных, а применять его довольно просто — это мы подробно обсудили в статье.
А вот тут будет призыв к действию: для нашей статьи я подготовил кучу материалов, включая видос ниже, где постарался в целом покрыть всю идею TTT. Я потратил слишком много времени в Manim-е, всё это верстая, поэтому просмотры / лайки будут highly appreciated. Ссылки на страницу статьи, посты, код и всё вот это — оставлю ниже.
Кому будет интересно, можете попробовать идею в этом ноутбуке.
📄 Paper: https://arxiv.org/abs/2410.04201
🧠 Project page: https://www.norange.io/projects/ittt/
💻 Code: https://github.com/nikitadurasov/ittt
🎬 Video: https://www.youtube.com/watch?v=eKGKpN8fFRM
🧩 torch-ttt class: https://torch-ttt.github.io/_autosummary/torch_ttt.engine.it3_engine.IT3Engine.html
🔬 Notebook: https://colab.research.google.com/github/nikitadurasov/ittt/blob/main/exps/mnist/it3_torch_ttt.ipynb
YouTube
[ICML 2025] IT³: Idempotent Test-Time Training
Introducing IT3: Idempotent Test-Time Training — a simple, universal method for improving model performance under distribution shift. No complex auxiliary losses and no architectural constraints. By enforcing idempotence, we achieve consistent gains across…
Forwarded from Заскуль питона (Data Science)
[Статья, EN] 7 Ecommerce A/B Testing Case Studies to Learn From
Это разбор реальных экспериментов от брендов: Clarks, Swiss Gear, SmartWool и других, которые проводили A/B-тесты с целью улучшения пользовательского опыта и увеличения конверсии в e-commerce. Ниже будет приведен краткий разбор кейсов (картинки в посте)🔽
🟣 Clear Within
Гипотеза: Переместим кнопку "Add to Cart" выше, чтобы повысить конверсии - пользователи увидят её сразу, без прокрутки.
🎯 Результат: +80% к добавлениям в корзину
📌 Выводы:
1. Размещение ключевых элементов, таких как кнопка "Добавить в корзину", должно быть сразу видно без прокрутки
2. Даже небольшие изменения в дизайне могут значительно повлиять на конверсию
3. Важно оптимизировать конверсию до масштабирования рекламных кампаний
🟡 Clarks
Гипотеза: Акцент на бесплатную доставку повысит доверие и склонит к покупке
🎯 Результат: +2.6% CR, +£2.8 млн выручки
📌 Выводы:
1. Яркое выделение бонусов, таких как бесплатная доставка, влияет на решение о покупке
2. Дизайн и пользовательский опыт имеют значение
3. Незначительные изменения в оформлении информации могут привести к значительному росту выручки
🔵 Beckett Simonon — +5% CR от сторителлинга
Гипотеза: Добавим сторителлинг о ценностях бренда - повысим вовлечённость и доверие
🎯 Результат: +5% к конверсии, ROI +237% годовых
📌 Выводы:
1. Клиенты положительно реагируют на честное, ценностное позиционирование
2. Истории, визуалы и смысловое наполнение сайта могут существенно повлиять на поведение пользователей
3. Соответствие ценностей бренда ожиданиям покупателей увеличивает доверие и лояльность
🟢 SmartWool
Гипотеза: Улучшение дизайна PDP повысит доход на посетителя
🎯 Результат: +17.1% к среднему доходу на посетителя (ARPU)
📌 Выводы:
1. Следование лучшим практикам в дизайне улучшает пользовательский опыт и увеличивает продажи
2. Единый стиль отображения товаров и чёткая подача информации влияют на решение о покупке
3. Инвестиции в дизайн страниц окупаются за счёт роста выручки и удовлетворённости клиентов
🟣 Metals4U
Гипотеза: Покажем сроки доставки и добавим лого платёжных систем → снизим тревожность
🎯 Результат: +4.8% CR, через 12 месяцев: +34% общая конверсия → +£2.2 млн выручки
📌 Выводы:
1. Прозрачная информация о доставке уменьшает неуверенность и снижает фрикции
2. Простые элементы — логотипы платёжных систем и сообщения о безопасности — значительно уменьшают количество отказов от покупки
3. Улучшение через итерации и эксперименты позволяет устойчиво масштабироваться
🟡 T.M. Lewin
Гипотеза: Уберём барьеры — чётко опишем политику возврата, покажем бандлы сразу
🎯 Результат: +7% продаж, +50% CR от возвратного блока
📌 Выводы:
1. Прозрачность условий возврата снижает сомнения и увеличивает готовность к покупке
2. Выгоды и скидки (например, мульти-покупка) должны быть чётко видны и легко доступны
3. Приоритизация по данным помогает находить точки наибольшего трения в пользовательском пути
🔵 Swiss Gear
Гипотеза: Оптимизируем дизайн карточек, упростим восприятие информации - пользователи будут покупать чаще
🎯 Результат: +52% CR в обычные дни, +137% CR в пиковые (Holiday season)
📌 Выводы:
1. Простота дизайна и акценты на ключевой информации помогают пользователям быстрее принять решение
2. Визуальная иерархия (цвета, шрифты) помогает выделить важное
3. Тестирование и подготовка страниц перед пиковыми периодами даёт экспоненциальный эффект
✅ Общие выводы по всем кейсам:
1. UX и структура страниц напрямую влияют на метрики: от кнопок до визуальной иерархии
2. Прозрачность и доверие (доставка, возвраты, логотипы) критичны для покупки
3. Ценностное позиционирование и сторителлинг усиливают восприятие бренда
4. Даже мелкие UI-изменения могут сильно повлиять на метрики
5. Итерации и эксперименты = устойчивый рост без кардинальных переделок
6. Чистота дизайна снижает фрустрацию и помогает принять решение
Понравился формат поста / хотите подобного рода посты? Ставьте реакции🔥 , пишите комментарии (лучший фидбек от вас)
Это разбор реальных экспериментов от брендов: Clarks, Swiss Gear, SmartWool и других, которые проводили A/B-тесты с целью улучшения пользовательского опыта и увеличения конверсии в e-commerce. Ниже будет приведен краткий разбор кейсов (картинки в посте)
Гипотеза: Переместим кнопку "Add to Cart" выше, чтобы повысить конверсии - пользователи увидят её сразу, без прокрутки.
1. Размещение ключевых элементов, таких как кнопка "Добавить в корзину", должно быть сразу видно без прокрутки
2. Даже небольшие изменения в дизайне могут значительно повлиять на конверсию
3. Важно оптимизировать конверсию до масштабирования рекламных кампаний
Гипотеза: Акцент на бесплатную доставку повысит доверие и склонит к покупке
1. Яркое выделение бонусов, таких как бесплатная доставка, влияет на решение о покупке
2. Дизайн и пользовательский опыт имеют значение
3. Незначительные изменения в оформлении информации могут привести к значительному росту выручки
Гипотеза: Добавим сторителлинг о ценностях бренда - повысим вовлечённость и доверие
1. Клиенты положительно реагируют на честное, ценностное позиционирование
2. Истории, визуалы и смысловое наполнение сайта могут существенно повлиять на поведение пользователей
3. Соответствие ценностей бренда ожиданиям покупателей увеличивает доверие и лояльность
Гипотеза: Улучшение дизайна PDP повысит доход на посетителя
1. Следование лучшим практикам в дизайне улучшает пользовательский опыт и увеличивает продажи
2. Единый стиль отображения товаров и чёткая подача информации влияют на решение о покупке
3. Инвестиции в дизайн страниц окупаются за счёт роста выручки и удовлетворённости клиентов
Гипотеза: Покажем сроки доставки и добавим лого платёжных систем → снизим тревожность
1. Прозрачная информация о доставке уменьшает неуверенность и снижает фрикции
2. Простые элементы — логотипы платёжных систем и сообщения о безопасности — значительно уменьшают количество отказов от покупки
3. Улучшение через итерации и эксперименты позволяет устойчиво масштабироваться
Гипотеза: Уберём барьеры — чётко опишем политику возврата, покажем бандлы сразу
1. Прозрачность условий возврата снижает сомнения и увеличивает готовность к покупке
2. Выгоды и скидки (например, мульти-покупка) должны быть чётко видны и легко доступны
3. Приоритизация по данным помогает находить точки наибольшего трения в пользовательском пути
Гипотеза: Оптимизируем дизайн карточек, упростим восприятие информации - пользователи будут покупать чаще
1. Простота дизайна и акценты на ключевой информации помогают пользователям быстрее принять решение
2. Визуальная иерархия (цвета, шрифты) помогает выделить важное
3. Тестирование и подготовка страниц перед пиковыми периодами даёт экспоненциальный эффект
1. UX и структура страниц напрямую влияют на метрики: от кнопок до визуальной иерархии
2. Прозрачность и доверие (доставка, возвраты, логотипы) критичны для покупки
3. Ценностное позиционирование и сторителлинг усиливают восприятие бренда
4. Даже мелкие UI-изменения могут сильно повлиять на метрики
5. Итерации и эксперименты = устойчивый рост без кардинальных переделок
6. Чистота дизайна снижает фрустрацию и помогает принять решение
Понравился формат поста / хотите подобного рода посты? Ставьте реакции
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM