🚀 Собери приложение без кода за 30 минут

Пошаговый набор сервисов + альтернатива из скрина

1) Сгенерировать PRD (Product Requirements Document)
• ChatPRD — ИИ делает полноценный PRD из вашей идеи:
https://chatprd.ai/
• Feedough PRD Generator — готовит PRD по шаблону:
https://www.feedough.com/ai-product-requirements-document-prd-generator/

2) Сгенерировать мобильное приложение и протестировать в Expo Go
• Create (create.xyz) — text-to-app билдер, собирает React Native/Expo-проект из описания или PRD.
• Rork AI — генерация приложения по тексту/промпту:
https://rork.app/

Как использовать (коротко):
Идея → генерируете PRD → вставляете текст/PRD в билдер → через 10–15 минут получаете проект → открываете на телефоне в Expo Go (iOS/Android).

💡Еще сервисы (AI-билдеры/IDE): chatgpt-5
Replit, Rocket, Loveable, Youware, Bolt, Firebase Studio, Cursor, Trae AI IDE, Gemini CLI, Warp Terminal, Rork Ai, Orchids, Deepsite.

🤖Saramudvlad | забустить 🤖

Буквально 2 дня назад вышла статья Avito 🌍 по 🆎. Разбираем по шагам механику A/B-тестирования: математика, интуиция и код

Почитал, в целом могу сказать, что хорошее чтиво для разбора A/B тестов.

Обычно, я смотрю графически на то, как изменяется MDE (тут это написано в зависимости от длительности эксперимента), также смотрю и по количеству пользователей в эксперименте (10/10, 20/20 и тд), только равные группы пользователей.

🧑‍🎓 Теоретическое

def compare_mde(current_a, current_b, new_a, new_b):
    return np.sqrt(1/current_a + 1/current_b) / np.sqrt(1/new_a + 1/new_b)

# здесь смотрят на то, а как изменится mde, если мы перейдем от 10/10 к 50/50 разбиению
compare_mde(0.1, 0.1, 0.5, 0.5) # ~2.236

💻 Практическое

def check_mde_reduce_from_size(grouped_dataset, current_t, current_c, new_t, new_c):
    """
    Функция для сравнения MDE в текущем варианте сплитования и в новом.
    Параметры:
        - grouped_dataset: сгруппированный поюзерный датасет, на осоновании которого будут сравниваться MDE
        - current_t: доля пользователей в тесте в текущем сетапе
        - current_c: доля пользователей в контроле в текущем сетапе
        - new_t: доля пользователей в тесте в новом сетапе
        - new_c: доля пользователей в контроле в новом сетапе
    Возвращает:
        - отношение MDE_current / MDE_new
    """


    grouped_dataset['group_current'] = np.random.choice(['test', 'control', '-'],
                                                        p=[current_t, current_c, 1 - current_c - current_t],
                                                        size=len(grouped_dataset))
    grouped_dataset['group_new'] = np.random.choice(['test', 'control', '-'],
                                                    p=[new_t, new_c, 1 - new_t - new_c],
                                                    size=len(grouped_dataset))
    metric = 'promotion_revenue'


    test_curr = np.array(grouped_dataset[(grouped_dataset['group_current'] == 'test')][metric])
    control_curr = np.array(grouped_dataset[(grouped_dataset['group_current'] == 'control')][metric])

    test_new = np.array(grouped_dataset[(grouped_dataset['group_new'] == 'test')][metric])
    control_new = np.array(grouped_dataset[(grouped_dataset['group_new'] == 'control')][metric])

    MDE_current = get_relative_MDE(test_curr, control_curr, alpha=0.05, beta=0.2)
    MDE_new = get_relative_MDE(test_new, control_new, alpha=0.05, beta=0.2)
    return MDE_current / MDE_new

Из формулы MDE зачастую мы работаем с равными дисперсиями в выборкам, поэтому можно вынести из под корня константу в виде дисперсии и размера выборки, это вот тут.

Прикольно, что на практических сгенерированных примерах видно, что эти расчеты реально работают и можно использовать для реализации внутри компании, при дизайне / расчета A/B тестов.

Написано еще тут и про прокси-метрики, что их нужно выбирать в зависимости от каждого кейса, про оценку эффекта при переходе от обычной метрики к прокси-метрике, интерпретацию прокси-метрик

+ итоги правильной подготовки сетапа теста, где выбрали

а) сплит 50/50, а не 10/10
б) выбрали прокси-метрику, а не основную (которая обладает меньшей чувствительностью)
в) держать тест не 1, а 7 недель.

🔽 как результат, получили сокращение MDE в 9.2 раза!

Ну и дополнительно рассказали про контр-метрики, в очередной раз упомянули линеаризацию + доверительный интервал для оценки эффекта Ratio-метрик.

В целом, хорошая и ненапряжная статья, которую я вам советую прочитать, если хотите начать разбираться в A/B тестах + подметить для себя что-то новое)

Ставьте 🐳, если понравился пост, делитесь своими мыслями в комментариях.

База собесов про LLM - промптинг💃

Предыдущий пост этой рубрики был встречен очень хорошо по реакциям и репостам, поэтому вторая часть посвященная промптингу к вашему вниманию.

1️⃣ Базовая структура промптов
По сути, есть две основные методологии составления промптов: AUTOMAT и CO-STAR. Давайте начнем с первого:

(А) Act as a …  ― вы определяете роль LLM. Имеет смысл сказать модели, чтобы она действовала как профессионал в предметной области.

(U) User Persona & Audience ― с кем взаимодействует модель, аудитория, уровень ее подготовки.

(T) Targeted Action ― что необходимо сделать.

(O) Output Definition ― определяем выходной формат.

(M) Mode/Tonality/Style ― настроение, стиль. Объясните модели, как читатель должен воспринимать текст.

(A) Atypical Cases ― обработка исключений. Этот раздел для промптов, работающих с разным набором данных. Например, в приложениях, где один и тот же промпт вызывается с разными пользовательскими запросами. Объясните модели, как реагировать, когда пользователь спросил что-то не то.

(T) Topic Whitelisting ― контекст, допустимые обсуждаемые темы. Это раздел также для промптов, работающих с разным набором данных. Думаю, создатели фреймворка разделили последние два пункта в таком порядке в основном ради того, чтобы получился красивый акроним. Указываем модели, о чем мы собираемся говорить.

Теперь CO-STAR. По сути, тот же фреймворк, только в профиль:
Context: Объясните модели, о чем речь, предоставьте подробности и контекст.
Objective: Какая цель? Чего вы хотите добиться? Четко опишите задачу.
Style & Tone: Аналогично AUTOMAT ― укажите эмоциональный тон ответа.
Audience: Ваша аудитория, кто будет это читать, на кого вы ориентируетесь, готовя ответ.
Response: Определите формат вывода

Есть еще множество различных техник промптинга и вряд ли вы когда-нибудь их будете учить наизусть, но главное для меня - это обьяснять задачу LLM, как ребенку: сказать, чем он занимается, почему это важно, дать инструкции и примеры.

2️⃣ Что такое in-context learning?
Его еще называют обучение "на лету", то есть когда мы пытаемся улучшить качество ответа через промпт, без изменений весов LLM.

3️⃣ Типы промптов
Если вы начнете гуглить, то вам выдаст кучу непонятных типов, например сравнительных или ролевых промптов. Но в целом их можно обьединить в три вида: zero-shot, few-shot и chain-of-thought. Разберем каждый из них:

Zero-shot: предполагают отсутствие примеров в запросе. Модель должна самостоятельно понять задачу и сгенерировать соответствующий ответ. Этот подход хорошо подходит для получения общего ответа или выполнения простой команды, где не требуется контекст.

Few-shot: промпт включает несколько примеров решения задачи, что помогает модели лучше понять контекст и требования. Подходит для сложных задач, где важен контекст или требуется специфический стиль ответа.

Сhain-of-thought: модель обрабатывает задачу пошагово, следуя логической цепочке рассуждений. Идеален для ответов, требующих последовательного анализа или расчета.

4️⃣ Как повысить точность и надёжность ответов, а также сделать их проверяемыми в LLM?
Как мы все знаем, что LLM очень любит галюцинировать и выдавать несуществующие факты за реальные. Для нас это может стать большой проблемой, потому что это достаточно сложно отличить. Поэтому есть несколько вариантов, как это можно избежать:
1. RAG
Базовый поиск по векторам по базе документов, при котором LLM не ищет или придумывает данные, а сразу принимает реальные данные из нашей базы данных
2. Делать еще один запрос в LLM для проверки фактов
Базовая идея проверить один ответ другим запросом в LLM, но если вы делаете продукт для клиента, то это станет огромной проблемой, так как один запрос в LLM +3 секунды.
3. Делать структурированные выводы информации
Одной из лучших вещей, что есть в langchain считается structered_output, который дает возможность писать ответы в LLM в нужном формате.

Промпты, наверное, самая простая тема в собесах, так что если на этом посте будет больше 30 репостов, то сразу выпущу вопросы с собеса про RAG. Обязательно ставьте реакции, автору будет приятно💗