Forwarded from Neural Kovalskii
LLM/RAG Мониторинг с первого дня - это не роскошь, а необходимость!
Когда я запускал @neuraldeepbot 8 месяцев назад, думал "сделаю MVP, а потом посмотрю"
Результат? Система работала, потом, когда-то, запущу в докере и улучшу
Но с развитием кодовых агентов и IDE таких как Cursor у меня чуть сильнее развязались руки
Сейчас подход кардинально другой — с первого запроса у меня есть:
Детализация реакций по дням (видно на графике)
Процент лайков по каждому этапу развития
Классификация сложности запросов через LLM
Трекинг используемых навыков в ReAct цепочке
И знаете что? Это реально работает!
За 6 дней метрики выросли с 48.8% до 96.0% положительных реакций
ReAct архитектура когда LLM сама решает как искать
Вместо жестко заданного пайплайна "вектора → реранкер → ответ" внедрил ReAct подход:
Конкретные цифры улучшений:
12.08: Запуск наивного RAG бота — 48.8% лайков
13.08: Анализ первых 200 запросов — 76.0% лайков
14.08: Добавил 4 навыка и классификатор — 78.3% лайков
16.08: Переход на GPT-4o-mini — 95.0% лайков
18.08: Финальные улучшения — 96.0% лайков
Аналитика запросов ваш компас в темноте это проблема почти 90% инициатив которые я встречаю
Самые болезненные инсайты пришли из анализа реальных пользовательских запросов:
Проблема №1: "Какой последний пост был?"
Система отвечала защитой из промпта
Фикс: Добавил навык временного поиска
Проблема №2: "Лучшая локальная LLM?"
Тащила посты 2024 года вместо свежих
Фикс: Приоритизация по датам через ReAct
Проблема №3: Нехватка контекста из разных каналов
Добавил данные из @llm_under_hood и @denissexy, @seeallochnaya
Сразу видно улучшение по реакциям!
Мой чек-лист для каждой итерации Q&A системы
Неделя 1: Базовый MVP + мониторинг реакций
Неделя 2: Анализ первых 100-200 запросов глазами (далее зовем LLM что бы сверится)
Неделя 3: Добавление недостающих навыков поиска
Неделя 3: Оптимизация промптов под реальные кейсы
Далее: Еженедельные итерации по метрикам
Техническая кухня что реально двигает метрики
Стек убийца:
ReAct агент для выбора стратегии поиска
gpt-5-mini как основной LLM (переход дал +19% к лайкам!)
SO на всех этапах вызова навыков
FTS + векторный поиск в зависимости от запроса
bge реранкер для финальной фильтрации
Qdrant для хранения эмбеддингов
PGSQL как основная база
teleton
fastapi
python
Система оценок:
Лайк/дизлайк после каждого ответа
Дизлайк = я лично смотрю кейс и думаю что пошло не так
Никаких A/B тестов — итерируем по общим метрикам(но только на старте)
Главные ошибки, которые убивают Q&A системы
"Сделаю идеальную архитектуру, а потом запущу" — НЕТ!
Запускай MVP и итерируй по реальным запросам
Игнорирование мониторинга без метрик ты летишь вслепую
Жесткий пайплайн вместо адаптивного ReAct дает LLM выбирать стратегию поиска
Недооценка важности промптов 80% успеха Q&A системы в правильных промптах
Ребята реально общались со мной через запросы и давали детальные советы по улучшению промптов
Честно говоря, RAG как RPG нужно быстро лечиться (хотфиксы),
крафтить экипировку (промпты), управлять инвентарем (данные)
и качать скиллы через квесты (Cursor). Каждый день фармишь опыт и лут для апгрейда системы
Но с правильным мониторингом и планом итераций
можно довести систему до production-ready за несколько недель вместо месяцев блужданий
Кто строил похожие Q&A системы без четкого понимания сценариев?
Какие метрики отслеживаете?
И главное как быстро итерируете по фидбеку пользователей?
Когда я запускал @neuraldeepbot 8 месяцев назад, думал "сделаю MVP, а потом посмотрю"
Результат? Система работала, потом, когда-то, запущу в докере и улучшу
Но с развитием кодовых агентов и IDE таких как Cursor у меня чуть сильнее развязались руки
Сейчас подход кардинально другой — с первого запроса у меня есть:
Детализация реакций по дням (видно на графике)
Процент лайков по каждому этапу развития
Классификация сложности запросов через LLM
Трекинг используемых навыков в ReAct цепочке
И знаете что? Это реально работает!
За 6 дней метрики выросли с 48.8% до 96.0% положительных реакций
ReAct архитектура когда LLM сама решает как искать
Вместо жестко заданного пайплайна "вектора → реранкер → ответ" внедрил ReAct подход:
User Query →
1) LLM классификатор навыка
Защита
Уточнение
Мета вопросы
RAG поиск
→
2) LLM классификатор сложности
ReAct агент выбирает навыки:
- FTS поиск по ключевым словам
- Векторный поиск (bge embedding)
- Комбинированный поиск
- Временная фильтрация
- Поиск по коментам vs постам
→ Синтез финального ответа
Еще одним полем отечает последовательность запуска (ему так же прописаны связи и возможности)
gpt-5-mini показала себя прям очень хорошо
Кстати все взаимодействия с навыками я построил через SO никакого tool call
Конкретные цифры улучшений:
12.08: Запуск наивного RAG бота — 48.8% лайков
13.08: Анализ первых 200 запросов — 76.0% лайков
14.08: Добавил 4 навыка и классификатор — 78.3% лайков
16.08: Переход на GPT-4o-mini — 95.0% лайков
18.08: Финальные улучшения — 96.0% лайков
Аналитика запросов ваш компас в темноте это проблема почти 90% инициатив которые я встречаю
Самые болезненные инсайты пришли из анализа реальных пользовательских запросов:
Проблема №1: "Какой последний пост был?"
Система отвечала защитой из промпта
Фикс: Добавил навык временного поиска
Проблема №2: "Лучшая локальная LLM?"
Тащила посты 2024 года вместо свежих
Фикс: Приоритизация по датам через ReAct
Проблема №3: Нехватка контекста из разных каналов
Добавил данные из @llm_under_hood и @denissexy, @seeallochnaya
Сразу видно улучшение по реакциям!
Мой чек-лист для каждой итерации Q&A системы
Неделя 1: Базовый MVP + мониторинг реакций
Неделя 2: Анализ первых 100-200 запросов глазами (далее зовем LLM что бы сверится)
Неделя 3: Добавление недостающих навыков поиска
Неделя 3: Оптимизация промптов под реальные кейсы
Далее: Еженедельные итерации по метрикам
Техническая кухня что реально двигает метрики
Стек убийца:
ReAct агент для выбора стратегии поиска
gpt-5-mini как основной LLM (переход дал +19% к лайкам!)
SO на всех этапах вызова навыков
FTS + векторный поиск в зависимости от запроса
bge реранкер для финальной фильтрации
Qdrant для хранения эмбеддингов
PGSQL как основная база
teleton
fastapi
python
Система оценок:
Лайк/дизлайк после каждого ответа
Дизлайк = я лично смотрю кейс и думаю что пошло не так
Никаких A/B тестов — итерируем по общим метрикам(но только на старте)
Главные ошибки, которые убивают Q&A системы
"Сделаю идеальную архитектуру, а потом запущу" — НЕТ!
Запускай MVP и итерируй по реальным запросам
Игнорирование мониторинга без метрик ты летишь вслепую
Жесткий пайплайн вместо адаптивного ReAct дает LLM выбирать стратегию поиска
Недооценка важности промптов 80% успеха Q&A системы в правильных промптах
Ребята реально общались со мной через запросы и давали детальные советы по улучшению промптов
Честно говоря, RAG как RPG нужно быстро лечиться (хотфиксы),
крафтить экипировку (промпты), управлять инвентарем (данные)
и качать скиллы через квесты (Cursor). Каждый день фармишь опыт и лут для апгрейда системы
Но с правильным мониторингом и планом итераций
можно довести систему до production-ready за несколько недель вместо месяцев блужданий
Кто строил похожие Q&A системы без четкого понимания сценариев?
Какие метрики отслеживаете?
И главное как быстро итерируете по фидбеку пользователей?
Forwarded from gonzo-обзоры ML статей
Вышел огромный обзор "Speed Always Wins: A Survey on Efficient Architectures for Large Language Models": https://t.me/gonzo_ML_podcasts/699
В каком-то смысле это продолжение старой доброй “Efficient Transformers: A Survey” 2020 года (https://arxiv.org/abs/2009.06732).
В каком-то смысле это продолжение старой доброй “Efficient Transformers: A Survey” 2020 года (https://arxiv.org/abs/2009.06732).
Telegram
gonzo_ML_podcasts
Speed Always Wins: A Survey on Efficient Architectures for Large Language Models
Authors: Weigao Sun, Jiaxi Hu, Yucheng Zhou, Jusen Du, Disen Lan, Kexin Wang, Tong Zhu, Xiaoye Qu, Yu Zhang, Xiaoyu Mo, Daizong Liu, Yuxuan Liang, Wenliang Chen, Guoqi Li, Yu…
Authors: Weigao Sun, Jiaxi Hu, Yucheng Zhou, Jusen Du, Disen Lan, Kexin Wang, Tong Zhu, Xiaoye Qu, Yu Zhang, Xiaoyu Mo, Daizong Liu, Yuxuan Liang, Wenliang Chen, Guoqi Li, Yu…
Forwarded from Love. Death. Transformers.
помните nanotron? Теперь у нас есть tinytpu.com
Проект по построению мини TPU(это такие специальные тензорные процессоры от гугла) где челы зареверсиженерили и вопсроизвели архитектуру и софт.
Внутри куча нюансов про низкоуровневый софт в которых я ничего не понимаю, но считаю что стоит ознакомится.
https://github.com/tiny-tpu-v2/tiny-tpu
Проект по построению мини TPU(это такие специальные тензорные процессоры от гугла) где челы зареверсиженерили и вопсроизвели архитектуру и софт.
Внутри куча нюансов про низкоуровневый софт в которых я ничего не понимаю, но считаю что стоит ознакомится.
https://github.com/tiny-tpu-v2/tiny-tpu
GitHub
GitHub - tiny-tpu-v2/tiny-tpu: A minimal tensor processing unit (TPU), inspired by Google's TPU V2 and V1
A minimal tensor processing unit (TPU), inspired by Google's TPU V2 and V1 - tiny-tpu-v2/tiny-tpu
Forwarded from GIS AND PEACE (Bella)
Urban Data Science Course
О работе с городскими данными на Python в материалах курса Urban Data Science Калифорнийского университета в Лос-Анджелесе (UCLA)
API, Web Scraping, Data Wrangling, Spatial Relations, Machine Learning, Clustering, Parsing Text, Natural Language Processing, Big Data
К каждому модулю:
🔘 ссылки на интересные статьи
🔘 Jupyter блокноты
🔘 видео
🔘 тесты и домашние задания
И всё это в открытом доступе!
КЛАД! 💎
#geo_cities #geo_py #geo_edu
🌎🕊️ GIS_AND_PEACE
О работе с городскими данными на Python в материалах курса Urban Data Science Калифорнийского университета в Лос-Анджелесе (UCLA)
API, Web Scraping, Data Wrangling, Spatial Relations, Machine Learning, Clustering, Parsing Text, Natural Language Processing, Big Data
К каждому модулю:
И всё это в открытом доступе!
КЛАД! 💎
#geo_cities #geo_py #geo_edu
🌎🕊️ GIS_AND_PEACE
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Заскуль питона (Data Science)
Шпаргалки по визуализации в Python
✋ Всем привет! Аналитикам и другим специалистам в области анализа данных необходимо из семпла данных сделать какое-то исследование, найти закономерность в данных и презентовать это ПМ / руководству и др. Не для каждой задачи нужно строить дашборд, поскольку задача может требовать первичный анализ.
🤔 В начале не придаешь этому значения, так как таблицы для нас содержат уже достаточное количество информации + различные статистики. Но на этом этапе хочется иметь возможность визуализировать базовые или интересные штуковины, с помощью которых можно будет сгенерировать еще гипотез.
Визуализировать можно и через Matplotlib (база всех графиков в Python), Seaborn (более расширенный функционал, чем Matplotlib), Plotly (интерактивные графики).
⬇️ Ниже приведен в коде минимум, которым можно пользоваться. Это должно покрывать большое количество задач (~80%) на распределения, поведение метрики во времени. Конечно, есть и другие виды визуализации, но это базовые. Сюда еще можно отнести boxplot для визуализации.
❤️ Если вдруг, вы хотите делать более красивые графики, испытывать наслаждение при их построении, а также сделать их понятнее, вэлком ниже.
1️⃣ Matplotlib [дока]
🔗 Matplotlib CheatSheet (matplotlib.org)
🔗 Гайд на Kaggle по различным визуализациям
🔗 DataCamp Matplotlib CheatSheet
2️⃣ Seaborn [дока]
🔗 DataCamp Seaborn
🔗 Вот тут очень хорошо описано + есть по другим библиотекам
3️⃣ Plotly [дока]
🔗 Plotly Express, Colab
🔗 Plotly Cheatsheet
🙊 Сам я использую matplotlib и seaborn, потому что они быстро настраиваются, но кому-то заходит и Plotly, так как он при обычной настройке может сделать красоту. Каждому свое)
Ну и конечно же, можно использовать ChatGPT, Cursor и других ребят для отрисовки графиков, смотря какую цель преследуете
Ставьте🐳 , сохраняйте к себе, чтобы не потерять, тренируйтесь и все у вас получится!
Визуализировать можно и через Matplotlib (база всех графиков в Python), Seaborn (более расширенный функционал, чем Matplotlib), Plotly (интерактивные графики).
import matplotlib.pyplot as plt
import numpy as np
# Данные
x = np.linspace(0, 10, 100) # создаём массив от 0 до 10 из 100 точек
y = np.sin(x) # вычисляем sin(x)
data = np.random.randn(1000) # 1000 случайных значений из нормального распределения
# Фигура с 2 графиками (subplots)
fig, ax = plt.subplots(1, 2, figsize=(12, 4)) # создаём фигуру с 1 строкой и 2 графиками
# Первый subplot: гистограмма
ax[0].hist(data, bins=20, color="skyblue", edgecolor="black") # рисуем гистограмму
ax[0].set_title("Гистограмма") # заголовок графика
ax[0].set_xlabel("Значения") # подпись оси X
ax[0].set_ylabel("Частота") # подпись оси Y
ax[0].grid(True) # включаем сетку
# Второй subplot: линейный график
ax[1].plot(x, y, label="sin(x)", color="red") # рисуем линию sin(x)
ax[1].set_xlim(0, 12) # ограничение по оси X
ax[1].set_ylim(-2, 2) # ограничение по оси Y
ax[1].set_xticks([0,2,4,6,8,10]) # задаём кастомные тики по X
ax[1].set_yticks([-2,-1,0,1,2]) # задаём кастомные тики по Y
ax[1].set_xlabel("Ось X") # подпись оси X
ax[1].set_ylabel("Ось Y") # подпись оси Y
ax[1].set_title("Линейный график") # заголовок графика
ax[1].legend() # выводим легенду
ax[1].grid(True) # включаем сетку
Ставьте
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Записки C3PO
У Ленни вышла статья где рассказывается про то, почему AI продукты должны иметь другой цикл разработки. Авторы показали фреймворк CC/CD.
TLDR: как писал много раз ранее, rolling updates с эскалацией сложности системы и evals для оценки технического качества.
Две фундаментальные проблемы AI-продуктов:
1. Недетерминированность - пользователи пишут что угодно вместо нажатия строго определенных заранее кнопок, система отвечает по-разному на одинаковые запросы. Классический QA тут не работает.
2. Компромисс между агентностью и контролем - чем больше автономии даешь ИИ, тем меньше контроля остается у людей.
Что такое CC/CD:
Continuous Development:
- Разбиваем большую цель на версии с растущей автономией (v1: AI-раб → v3: AI-коллега)
- Настраиваем простейшее приложение с логированием всего подряд и возможностью передачи контроля человеку
- Проектируем evals для измерения качества
Continuous Calibration:
- Запускаем на небольшой группе пользователей
- Анализируем реальные данные и паттерны фейлов
- Итеративно фиксим на основе данных
Пример из жизни - автоматизация саппорта:
- v1: Только роутинг тикетов по отделам
- v2: Предложение решений на основе инструкций и/или базы знаний
- v3: Автономное решение с эскалацией сложных кейсов до человека
Главный принцип - не давать ИИ полную автономию сразу. Система должна заслужить доверие через постепенное увеличение ответственности и доказательство надежности на каждом этапе. Это как онбординг нового сотрудника. Сначала простые задачи, потом постепенное расширение полномочий по мере накопления доверия.
По факту, это формализация того, что мы и так делаем в команде с нашими ассистентами и другими ИИ продуктами. Начинаем с простых сценариев, постепенно расширяем полномочия, мониторим каждый чих через evals, много бенчмаркинга.
TLDR: как писал много раз ранее, rolling updates с эскалацией сложности системы и evals для оценки технического качества.
Две фундаментальные проблемы AI-продуктов:
1. Недетерминированность - пользователи пишут что угодно вместо нажатия строго определенных заранее кнопок, система отвечает по-разному на одинаковые запросы. Классический QA тут не работает.
2. Компромисс между агентностью и контролем - чем больше автономии даешь ИИ, тем меньше контроля остается у людей.
Что такое CC/CD:
Continuous Development:
- Разбиваем большую цель на версии с растущей автономией (v1: AI-раб → v3: AI-коллега)
- Настраиваем простейшее приложение с логированием всего подряд и возможностью передачи контроля человеку
- Проектируем evals для измерения качества
Continuous Calibration:
- Запускаем на небольшой группе пользователей
- Анализируем реальные данные и паттерны фейлов
- Итеративно фиксим на основе данных
Пример из жизни - автоматизация саппорта:
- v1: Только роутинг тикетов по отделам
- v2: Предложение решений на основе инструкций и/или базы знаний
- v3: Автономное решение с эскалацией сложных кейсов до человека
Главный принцип - не давать ИИ полную автономию сразу. Система должна заслужить доверие через постепенное увеличение ответственности и доказательство надежности на каждом этапе. Это как онбординг нового сотрудника. Сначала простые задачи, потом постепенное расширение полномочий по мере накопления доверия.
По факту, это формализация того, что мы и так делаем в команде с нашими ассистентами и другими ИИ продуктами. Начинаем с простых сценариев, постепенно расширяем полномочия, мониторим каждый чих через evals, много бенчмаркинга.
Lennysnewsletter
Why your AI product needs a different development lifecycle
Introducing the Continuous Calibration/Continuous Development (CC/CD) framework
Forwarded from Sinекура
Современные LLM, даже рассуждающие, всё равно очень плохи в алгоритмических задачах. И вот, кажется, намечается прогресс: Hierarchical Reasoning Model (HRM), в которой друг с другом взаимодействуют две рекуррентные сети на двух уровнях, с жалкими 27 миллионами параметров обошла системы в тысячи раз больше на задачах, требующих глубокого логического мышления. Как у неё это получилось, и может ли это совершить новую мини-революцию в AI? Давайте разберёмся...
Hierarchical Reasoning Model: как 27М параметров решают судоку и ARC-AGI
(Пост довольно большой, так что приведу тут только введение, дальше читайте по ссылке.)
Возможности современных LLM слегка парадоксальны: модели, которые пишут симфонии и объясняют квантовую хромодинамику, не могут решить судоку уровня "эксперт". На подобного рода алгоритмических головоломках точность даже лучших LLM в мире стремится к нулю.
Это не баг, а фундаментальное ограничение архитектуры. Вспомните базовый курс алгоритмов (или менее базовый курс теории сложности, если у вас такой был): есть задачи класса P (решаемые за полиномиальное время), а есть задачи, решаемые схемами постоянной глубины (AC⁰). Трансформеры, при всей их мощи, застряли во втором классе, ведь у них фиксированная и не слишком большая глубина.
Представьте это так: вам дают лабиринт и просят найти выход. Это несложно, но есть нюанс: смотреть на лабиринт можно ровно три секунды, вне зависимости от того, это лабиринт 5×5 или 500×500. Именно так работают современные LLM — у них фиксированное число слоёв (обычно несколько десятков), через которые проходит информация. Миллиарды и триллионы параметров относятся к ширине обработки (числу весов в каждом слое), а не к глубине мышления (числу слоёв).
Да, начиная с семейства OpenAI o1 у нас есть “рассуждающие” модели, которые могут думать долго. Но это ведь на самом деле “костыль”: они порождают промежуточные токены, эмулируя цикл через текст. Честно говоря, подозреваю, что для самой LLM это как программировать на Brainfuck — технически возможно, но мучительно неэффективно. Представьте, например, что вам нужно решить судоку с такими ограничениями:
— смотреть на картинку можно две секунды,
— потом нужно записать обычными словами на русском языке то, что вы хотите запомнить,
— и потом вы уходите и возвращаетесь через пару дней (полностью “очистив контекст”), получая только свои предыдущие записи на естественном языке плюс ещё две секунды на анализ самой задачи.
Примерно так современные LLM должны решать алгоритмические задачи — так что кажется неудивительным, что они это очень плохо делают!
И вот Wang et al. (2025) предлагают архитектуру Hierarchical Reasoning Model (HRM), которая, кажется, умеет думать нужное время естественным образом... Как у них это получилось?
Hierarchical Reasoning Model: как 27М параметров решают судоку и ARC-AGI
(Пост довольно большой, так что приведу тут только введение, дальше читайте по ссылке.)
Возможности современных LLM слегка парадоксальны: модели, которые пишут симфонии и объясняют квантовую хромодинамику, не могут решить судоку уровня "эксперт". На подобного рода алгоритмических головоломках точность даже лучших LLM в мире стремится к нулю.
Это не баг, а фундаментальное ограничение архитектуры. Вспомните базовый курс алгоритмов (или менее базовый курс теории сложности, если у вас такой был): есть задачи класса P (решаемые за полиномиальное время), а есть задачи, решаемые схемами постоянной глубины (AC⁰). Трансформеры, при всей их мощи, застряли во втором классе, ведь у них фиксированная и не слишком большая глубина.
Представьте это так: вам дают лабиринт и просят найти выход. Это несложно, но есть нюанс: смотреть на лабиринт можно ровно три секунды, вне зависимости от того, это лабиринт 5×5 или 500×500. Именно так работают современные LLM — у них фиксированное число слоёв (обычно несколько десятков), через которые проходит информация. Миллиарды и триллионы параметров относятся к ширине обработки (числу весов в каждом слое), а не к глубине мышления (числу слоёв).
Да, начиная с семейства OpenAI o1 у нас есть “рассуждающие” модели, которые могут думать долго. Но это ведь на самом деле “костыль”: они порождают промежуточные токены, эмулируя цикл через текст. Честно говоря, подозреваю, что для самой LLM это как программировать на Brainfuck — технически возможно, но мучительно неэффективно. Представьте, например, что вам нужно решить судоку с такими ограничениями:
— смотреть на картинку можно две секунды,
— потом нужно записать обычными словами на русском языке то, что вы хотите запомнить,
— и потом вы уходите и возвращаетесь через пару дней (полностью “очистив контекст”), получая только свои предыдущие записи на естественном языке плюс ещё две секунды на анализ самой задачи.
Примерно так современные LLM должны решать алгоритмические задачи — так что кажется неудивительным, что они это очень плохо делают!
И вот Wang et al. (2025) предлагают архитектуру Hierarchical Reasoning Model (HRM), которая, кажется, умеет думать нужное время естественным образом... Как у них это получилось?
Forwarded from Applied AI by David
Как сэкономить 84 350 долларов в год
Столько стоит MBA (программа Master of Business Administration) в MIT, а также огромное количество времени. Я ничего не плачу и получаю персональные рекомендации по улучшению процессов в моей жизни и моих бизнесах. Ниже расскажу как, но перед этим отзывы:
CTO: "Блин это лучшее обучение которое у меня когда-либо было"
CAIO: "Я занимаюсь уже всю неделю не отрываясь"
Остальная команда: 100/10
Друг-предприниматель: "Сделал себе, то что я получаю пользу в контексте моих проектов сразу зарабатывает мне деньги"
Знакомая, окончившая MBA: "эх если бы такое было в моё время я бы уже в 16 запускала первый проект"
Мой друг 160iq+: не стал пробовать, слишком гигантское эго
TLDR РЕЦЕПТ
0. Открываем любую GPT
1. You will become what you hate about yourself — "Я хочу научиться Х, сделай мне тест моего уровня для оценки навыков, чтобы я смог Y"
2. Context is the king — В настройках персонализации chatgpt / claude / cursorrules пишем 300+ слов о себе, опыте, проблемах, ресурсах, проблеме и цели
3. Make yourself 6-monthly over-detailed, over-personalized, gpt-understandable plan — В несколько промптов создаем себе план обучения на 2000+ уроков, которые погрузят нас в каждую тему
4. Корректируем под себя промпт "плана урока"
5-2004. Follow it, make a schedule — начинаем каждый день со стандартного "план урока"+"промпт-тема"
Try now or forget forever - 100% есть фундаментальные навыки, в котором ты - лох, либо можешь перейти на следующую парадигму:
- management
- product
- sales
- networking
- processes
- your tech domain
Накидайте 10 огонечков и скину свои промпты.
Моей команде: буду благодарен если напишите свой опыт в комментах
@aigov2
Столько стоит MBA (программа Master of Business Administration) в MIT, а также огромное количество времени. Я ничего не плачу и получаю персональные рекомендации по улучшению процессов в моей жизни и моих бизнесах. Ниже расскажу как, но перед этим отзывы:
CTO: "Блин это лучшее обучение которое у меня когда-либо было"
CAIO: "Я занимаюсь уже всю неделю не отрываясь"
Остальная команда: 100/10
Друг-предприниматель: "Сделал себе, то что я получаю пользу в контексте моих проектов сразу зарабатывает мне деньги"
Знакомая, окончившая MBA: "эх если бы такое было в моё время я бы уже в 16 запускала первый проект"
Мой друг 160iq+: не стал пробовать, слишком гигантское эго
TLDR РЕЦЕПТ
1. You will become what you hate about yourself — "Я хочу научиться Х, сделай мне тест моего уровня для оценки навыков, чтобы я смог Y"
2. Context is the king — В настройках персонализации chatgpt / claude / cursorrules пишем 300+ слов о себе, опыте, проблемах, ресурсах, проблеме и цели
3. Make yourself 6-monthly over-detailed, over-personalized, gpt-understandable plan — В несколько промптов создаем себе план обучения на 2000+ уроков, которые погрузят нас в каждую тему
4. Корректируем под себя промпт "плана урока"
5-2004. Follow it, make a schedule — начинаем каждый день со стандартного "план урока"+"промпт-тема"
Try now or forget forever - 100% есть фундаментальные навыки, в котором ты - лох, либо можешь перейти на следующую парадигму:
- management
- product
- sales
- networking
- processes
- your tech domain
Накидайте 10 огонечков и скину свои промпты.
Моей команде: буду благодарен если напишите свой опыт в комментах
@aigov2
Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
База собесов про LLM - RAG😎
Продолжение рубрики с прохождением собесов, на очереди одна из самых частых тем в моей работе - RAG.
1️⃣ Как работает RAG?
RAG (Retrieval-Augmented Generation) — это метод, позволяющий большим языковым моделям (LLM) улучшать качество ответов за счет использования актуальной информации из внешних источников, таких как базы данных, документы или API. Этот подход снижает вероятность ошибок модели (галлюцинаций) и обеспечивает более точные и контекстуально обоснованные ответы, даже если сама модель обучалась на устаревших данных.
Концептуально можно выделить несколько ключевых компонентов и этапов, которые обеспечивают работу RAGа:
1. Ввод пользовательского запроса.
2. Запрос преобразуется в векторное представление (эмбеддинг), которое математически описывает смысл запроса. Обычно используется предобученная модель для генерации эмбеддингов.
3. Далее вектор запроса сравнивается с хранящимися в базе векторами для поиска наиболее релевантных данных. В качестве баз для хранения часто используют Qdrant, Pinecone или Weaviate.
4. Из базы данных извлекаются фрагменты текста или документов, которые лучше всего соответствуют запросу. Эти данные формируют контекст для ответа.
5. LLM получает извлеченный контекст и запрос. Из этих данных она генерирует ответ, который после возвращается пользователю.
2️⃣ В чём преимущества использования системы RAG?
Главное преимущество использования RAG - скорость поиска, так как ни регулярки, ни LLM не решает этот вопрос лучше. Но придется тестить много разных моделей для эмбеддингов, и четко оценивать различные метрики расстояния между запросом и документом.
3️⃣ Когда лучше использовать Fine-tuning вместо RAG?
Базовый ответ на этот вопрос, когда не нужен никакой сильный поиск, потому что зачастую после использования RAG системы все равно нужен запрос в LLM для нормального(человечного) ответа. Все равно RAG требует некоторых вычислительных мощностей, поэтому если можно сократить путь, то всего это делайте.
4️⃣ Типы RAG систем
Sparse Retrieval (BM25, TF-IDF)
BM25 основан на методе оценки ключевых слов TF-IDF(Term-Frequency Inverse-Document Frequency), используя модель двоичной независимости из расчета IDF и добавляя штраф за нормализацию, который взвешивает длину документа относительно средней длины всех документов в базе данных.
Чаще всего этот метод используют для реализации быстрых решений, так как он прост в реализации, имеет хорошую скорость и также можно точно настроить под задачу. Но дальше выходят основные ограничения метода: не учитываются семантические свящи между словами и плохая восприимчивость к синонимии и контексту.
Ноутбук для использования
Dense Retrieval(vector embeddings + ANN)
Dense Retrieval сочетает в себе два ключевых компонента:
1. Векторные эмбеддинги для представления запросов и документов в едином векторном пространстве
2. ANN - алгоритмы приближенного поиска ближайших соседей для выборки ближайших векторов
Плотные вектора подходят намного больше для поиска по контексту, но у них возникают проблемы с ключевыми словами. Поэтому финальным решением чаще всего становится Hybrid Retrieval.
Hybrid Retrieval (комбинация sparse + dense)
Хотя dense ретриверы, основанные на сложных моделях встраивания, хорошо понимают семантические связи и намерения пользователя, они иногда могут промахиваться по запросам, требующим точных лексических совпадений. Например, модель может уловить общую тему запроса, но не отдать приоритет документам, содержащим очень конкретный, но менее распространенный код продукта или технический термин, упомянутый пользователем. Напротив, традиционные sparse ретриверы, такие как BM25, отлично находят эти точные термины, но им не хватает более широкого контекстного понимания для поиска семантически похожего, но лексически разного контента. Они работают с ключевыми словами, которые, несмотря на точность, могут быть нестабильны при работе с синонимами, парафразами или сложными запросами на естественном языке. Сочетание плотных и разреженных методов поиска обеспечивает ряд преимуществ для вашей системы RAG
Ноутбук с примером
Продолжение рубрики с прохождением собесов, на очереди одна из самых частых тем в моей работе - RAG.
RAG (Retrieval-Augmented Generation) — это метод, позволяющий большим языковым моделям (LLM) улучшать качество ответов за счет использования актуальной информации из внешних источников, таких как базы данных, документы или API. Этот подход снижает вероятность ошибок модели (галлюцинаций) и обеспечивает более точные и контекстуально обоснованные ответы, даже если сама модель обучалась на устаревших данных.
Концептуально можно выделить несколько ключевых компонентов и этапов, которые обеспечивают работу RAGа:
1. Ввод пользовательского запроса.
2. Запрос преобразуется в векторное представление (эмбеддинг), которое математически описывает смысл запроса. Обычно используется предобученная модель для генерации эмбеддингов.
3. Далее вектор запроса сравнивается с хранящимися в базе векторами для поиска наиболее релевантных данных. В качестве баз для хранения часто используют Qdrant, Pinecone или Weaviate.
4. Из базы данных извлекаются фрагменты текста или документов, которые лучше всего соответствуют запросу. Эти данные формируют контекст для ответа.
5. LLM получает извлеченный контекст и запрос. Из этих данных она генерирует ответ, который после возвращается пользователю.
Главное преимущество использования RAG - скорость поиска, так как ни регулярки, ни LLM не решает этот вопрос лучше. Но придется тестить много разных моделей для эмбеддингов, и четко оценивать различные метрики расстояния между запросом и документом.
Базовый ответ на этот вопрос, когда не нужен никакой сильный поиск, потому что зачастую после использования RAG системы все равно нужен запрос в LLM для нормального(человечного) ответа. Все равно RAG требует некоторых вычислительных мощностей, поэтому если можно сократить путь, то всего это делайте.
Sparse Retrieval (BM25, TF-IDF)
BM25 основан на методе оценки ключевых слов TF-IDF(Term-Frequency Inverse-Document Frequency), используя модель двоичной независимости из расчета IDF и добавляя штраф за нормализацию, который взвешивает длину документа относительно средней длины всех документов в базе данных.
Чаще всего этот метод используют для реализации быстрых решений, так как он прост в реализации, имеет хорошую скорость и также можно точно настроить под задачу. Но дальше выходят основные ограничения метода: не учитываются семантические свящи между словами и плохая восприимчивость к синонимии и контексту.
Ноутбук для использования
Dense Retrieval(vector embeddings + ANN)
Dense Retrieval сочетает в себе два ключевых компонента:
1. Векторные эмбеддинги для представления запросов и документов в едином векторном пространстве
2. ANN - алгоритмы приближенного поиска ближайших соседей для выборки ближайших векторов
Плотные вектора подходят намного больше для поиска по контексту, но у них возникают проблемы с ключевыми словами. Поэтому финальным решением чаще всего становится Hybrid Retrieval.
Hybrid Retrieval (комбинация sparse + dense)
Хотя dense ретриверы, основанные на сложных моделях встраивания, хорошо понимают семантические связи и намерения пользователя, они иногда могут промахиваться по запросам, требующим точных лексических совпадений. Например, модель может уловить общую тему запроса, но не отдать приоритет документам, содержащим очень конкретный, но менее распространенный код продукта или технический термин, упомянутый пользователем. Напротив, традиционные sparse ретриверы, такие как BM25, отлично находят эти точные термины, но им не хватает более широкого контекстного понимания для поиска семантически похожего, но лексически разного контента. Они работают с ключевыми словами, которые, несмотря на точность, могут быть нестабильны при работе с синонимами, парафразами или сложными запросами на естественном языке. Сочетание плотных и разреженных методов поиска обеспечивает ряд преимуществ для вашей системы RAG
Ноутбук с примером
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM