Опера (та, что браузер делает, красный такой кружочек) выкатила классный ностальгический и интерактивный сайт по истории развития интернета.
https://www.web-rewind.com
Оказывается твитеру (тот что теперь Х) в этом году 20 лет 😱
https://www.web-rewind.com
Оказывается твитеру (тот что теперь Х) в этом году 20 лет 😱
Web Rewind
An interactive journey through 30 years of the web
Сегодня вышла на LiveLib моя подборка с рекомендациями книг по ИИ и ML.
Кому интересно будет погрузиться в мир машинного обучения и искусственного интеллекта, переходите по ссылке👇
А какие книги вы посоветуете ещё почитать?🧑🎓
Кому интересно будет погрузиться в мир машинного обучения и искусственного интеллекта, переходите по ссылке
А какие книги вы посоветуете ещё почитать?
Please open Telegram to view this post
VIEW IN TELEGRAM
www.livelib.ru
Как устроены нейросети: 10 проверенных книг о том, как на самом деле работает ИИ
В Москве прошла Национальная технологическая олимпиада по искусственному интеллекту, которая в этом году объединила более семи тысяч участников.... Читать дальше...
🔥8👍2🏆1
🎯 Рекомендации, которые не сужают, а расширяют
Выходные прошли и провёл я их в мыслях: а куда вообще движутся рекомендательные системы? Не в смысле "какой следующий датасет выкатят или какую новую модель", а концептуально что они пытаются сделать с человеком?
Да и такое бывает, люблю рефлексировать)
И понял, что меня давно подбешивает одна штука.
Почти все системы решают одну задачу: угадать, на что ты кликнешь прямо сейчас. Ну или максимум что досмотришь до конца. Это оптимизация под сиюминутное попадание.
Любишь фантастику, вот тебе ещё фантастика. Слушаешь lo-fi держи ещё lo-fi. И так бесконечно.
И круг потихоньку сжимается вокруг тебя, пока не начнёшь чувствовать себя в пузыре бесконечно одинаковых рекомендаций.
Но что если поменять сам вопрос?
Не "чего пользователь хочет сейчас", а "какая последовательность рекомендаций сделает его вкус богаче через месяц".
Прикол в том, что вкусы меняются.
У каждого из нас не один вкусовой вектор, а целых три:
- ядро: то, что мы стабильно любим
- то, к чему мы почти готовы, но ещё не дошли или не созрели
- зона отторжения: то, что сейчас точно не зайдёт
Обычные системы крутятся внутри ядра. А реально интересно работать во второй зоне, искать мостики к новым объектам: достаточно знакомые, чтобы не оттолкнуть, и достаточно новые, чтобы принести пользу.
Да, вы можете сказать: ну камон, есть же диверсификация или серендипити, но это всё свойства списка, а я больше про модель изменения вкусов пользователя во времени.
Если система просто берёт топ-100 релевантных, добавляет штраф за похожесть, иногда домешивает неожиданный item, то это старый рекомендер с умным реранкером.
Но, если продолжить идею: если система оценивает текущую "готовность к переходу", выбирает промежуточные объекты, планирует серию шагов, измеряет успех как появление нового устойчивого интереса, то это уже не диверсификация, а обучаемая траектория с графами вкусовых зон пользователя.
Это меняет саму целевую функцию. Вместо привычного score(user, item) оптимизируешь что-то вроде:
И тут не ранжирование как таковое, а ближе к управлению динамической системой вкуса пользователя.
Главная боль: долгосрочные сигналы собирать сложно. И легко переумничать ведь система начнёт слишком рьяно "развивать" пользователя и просто его задолбает.
Но именно поэтому мне кажется, что здесь есть пространство для оптимизаций и расширения, туда куда могут пойти рек системы.
Рекомендательная система должна не угадывать, что ты уже любишь, а помогать тебе полюбить то, до чего ты почти дорос.
Если кто-то знает людей или команды, которые серьёзно копают в эту сторону киньте в комменты, очень интересно почитать 🙏
А если нет - вызов принят 😂
Выходные прошли и провёл я их в мыслях: а куда вообще движутся рекомендательные системы? Не в смысле "какой следующий датасет выкатят или какую новую модель", а концептуально что они пытаются сделать с человеком?
Да и такое бывает, люблю рефлексировать)
И понял, что меня давно подбешивает одна штука.
Почти все системы решают одну задачу: угадать, на что ты кликнешь прямо сейчас. Ну или максимум что досмотришь до конца. Это оптимизация под сиюминутное попадание.
Любишь фантастику, вот тебе ещё фантастика. Слушаешь lo-fi держи ещё lo-fi. И так бесконечно.
И круг потихоньку сжимается вокруг тебя, пока не начнёшь чувствовать себя в пузыре бесконечно одинаковых рекомендаций.
Но что если поменять сам вопрос?
Не "чего пользователь хочет сейчас", а "какая последовательность рекомендаций сделает его вкус богаче через месяц".
Прикол в том, что вкусы меняются.
У каждого из нас не один вкусовой вектор, а целых три:
- ядро: то, что мы стабильно любим
- то, к чему мы почти готовы, но ещё не дошли или не созрели
- зона отторжения: то, что сейчас точно не зайдёт
Обычные системы крутятся внутри ядра. А реально интересно работать во второй зоне, искать мостики к новым объектам: достаточно знакомые, чтобы не оттолкнуть, и достаточно новые, чтобы принести пользу.
Да, вы можете сказать: ну камон, есть же диверсификация или серендипити, но это всё свойства списка, а я больше про модель изменения вкусов пользователя во времени.
Если система просто берёт топ-100 релевантных, добавляет штраф за похожесть, иногда домешивает неожиданный item, то это старый рекомендер с умным реранкером.
Но, если продолжить идею: если система оценивает текущую "готовность к переходу", выбирает промежуточные объекты, планирует серию шагов, измеряет успех как появление нового устойчивого интереса, то это уже не диверсификация, а обучаемая траектория с графами вкусовых зон пользователя.
Это меняет саму целевую функцию. Вместо привычного score(user, item) оптимизируешь что-то вроде:
Скор = Польза_сейчас + Полезное_удивление + Расширение_вкуса − Сожаление
И тут не ранжирование как таковое, а ближе к управлению динамической системой вкуса пользователя.
Главная боль: долгосрочные сигналы собирать сложно. И легко переумничать ведь система начнёт слишком рьяно "развивать" пользователя и просто его задолбает.
Но именно поэтому мне кажется, что здесь есть пространство для оптимизаций и расширения, туда куда могут пойти рек системы.
Рекомендательная система должна не угадывать, что ты уже любишь, а помогать тебе полюбить то, до чего ты почти дорос.
Если кто-то знает людей или команды, которые серьёзно копают в эту сторону киньте в комменты, очень интересно почитать 🙏
А если нет - вызов принят 😂
🔥6
Много читаю на тему влияния ИИ на человечество.
Последнее время разные мнения на этот счёт.
Да и личные наблюдения за когнитивными изменениями, заставляют задумываться.
Сегодня прислали интересную статью, как мне кажется, в ней наиболее точно раскрывается тема:
https://teletype.in/@antipov_pipiggi/nQkzK38ikiL
Что думаете на этот счёт?
Последнее время разные мнения на этот счёт.
Да и личные наблюдения за когнитивными изменениями, заставляют задумываться.
Сегодня прислали интересную статью, как мне кажется, в ней наиболее точно раскрывается тема:
https://teletype.in/@antipov_pipiggi/nQkzK38ikiL
Что думаете на этот счёт?
Teletype
Мы пересекли черту во сне. Объясняю, почему ИИ — это конец 4 миллиардов лет привычной эволюции
Манифест о том, как исчезает разделение между железом, программой, ИИ и человеком - и почему происходящее не технологическая революция...
Большинство классических item-to-item рекомендательных систем работают довольно просто.
Есть товар: item_id = 515
И мы хотим найти другие товары, похожие на него.
Для этого обычно используют:
- со-клики / со-покупки,
- ближайшие соседи (ANN и т.п.),
- колобаративные эмбеддинги,
- последовательные эмбеддинги вроде BERT4Rec,
- ANN-поиск по эмбеддингам,
- или всё сразу.
То есть товар превращается в вектор:
А дальше мы ищем ближайшие эмбеддинги.
Но есть одна интересная вещь. item_id сам по себе ничего не значит:
Товар 515 и товар 516 могут быть совершенно разными.
А товар 515 и товар 928374 почти одинаковыми.
Обычный item_id уникален, но он не информативный.
И тут появляется очень красивая идея: дать товарам не просто ID, а семантический ID (Semantic ID).
То есть вместо:
получить что-то вроде:
Это всё ещё числа.
Но теперь они уже не случайные.
Это дискретный смысл в котором заложена информация о товаре.
Например:
Такие товары будут близки не потому, что у них похожие item_id, а потому что за этими чиселками стоят похожие свойства и поведение товаров.
С книгами это особенно легко представить.
Допустим:
Первые две книги могут получать похожие токены, потому что:
- их читают похожие пользователи,
- у них похожий жанр,
- похожая аудитория,
- похожие паттерны потребления.
А учебник по матану окажется уже совсем в другой области векторного пространства.
Но возникает вопрос: как вообще превратить обычный эмбеддинг в такую последовательность смысловых токенов?
И тут появляется RQ-VAE модель, которая умеет превращать обычные эмбеддинги в короткие наборы дискретных токенов.
Если совсем грубо, RQ-VAE работает как умный компрессор для векторного пространства.
У нас есть длинный плотный эмбеддинг товара, например, коллаборативный, текстовый или из модели последовательных действий. В нём зашита информация о поведении пользователей, тексте, категории, картинке и других свойствах объекта.
RQ-VAE пытается представить такой эмбеддинг не как длинный набор float-чисел, а как короткую последовательность дискретных токенов.
Зачем это нужно?
Во-первых, такие представления гораздо удобнее для поиска похожих товаров: вместо поиска только ближайших соседей можно искать товары с похожими токенами или общими префиксами смысловых идентификаторов.
Во-вторых, это делает каталог более структурированным: похожие товары начинают получать похожие последовательности кодов.
В-третьих, это сближает рексистемы с идеями из NLP и LLM, где текст тоже сначала превращается в последовательность токенов.
По сути RQ-VAE это способ дать объектам не случайные ID, а компактные машинные "смысловые адреса".
И это интересно не только концептуально, но и очень практично для продовых рексистем.
Потому что retrieval по semantic ID часто оказывается сильно дешевле и быстрее, чем поиск ближайших соседей по плотным эмбедингам.
В классическом ANN-поиске нам обычно нужны:
- большие векторные индексы,
- HNSW/FAISS/ScaNN,
- хранение float-векторов,
- поиск похожих.
А здесь объект уже представлен короткой последовательностью дискретных токенов:
И retrieval можно делать почти как поиск по инвертированному индексу:
• совпал полный semantic ID,
• совпал префикс,
• совпали первые 2 токена,
• или просто есть пересечение по бакетам.
Вместо дорогого поиска по непрерывному пространству мы переходим к очень дешёвым операциям над токенами.
Особенно это интересно для:
• огромных каталогов,
• рекомендаций в nearline или риалтайме,
• инференсе на носимых устройствах,
• многоэтапных рекомендательных систем,
• и архитектур, где сначала ищут кандидатов, а потом ранжируют их.
По сути semantic ID превращает retrieval из "поиска ближайшего вектора" в "поиск по смысловым адресам".
Есть товар: item_id = 515
И мы хотим найти другие товары, похожие на него.
Для этого обычно используют:
- со-клики / со-покупки,
- ближайшие соседи (ANN и т.п.),
- колобаративные эмбеддинги,
- последовательные эмбеддинги вроде BERT4Rec,
- ANN-поиск по эмбеддингам,
- или всё сразу.
То есть товар превращается в вектор:
item_id → embedding
А дальше мы ищем ближайшие эмбеддинги.
Но есть одна интересная вещь. item_id сам по себе ничего не значит:
Товар 515 и товар 516 могут быть совершенно разными.
А товар 515 и товар 928374 почти одинаковыми.
Обычный item_id уникален, но он не информативный.
И тут появляется очень красивая идея: дать товарам не просто ID, а семантический ID (Semantic ID).
То есть вместо:
item_id = 515
получить что-то вроде:
item → [12, 87, 5, 41]
Это всё ещё числа.
Но теперь они уже не случайные.
Это дискретный смысл в котором заложена информация о товаре.
Например:
item A → [12, 87, 5, 41]
item B → [12, 87, 6, 39]
Такие товары будут близки не потому, что у них похожие item_id, а потому что за этими чиселками стоят похожие свойства и поведение товаров.
С книгами это особенно легко представить.
Допустим:
"Гарри Поттер" → [12, 87, 5, 41]
"Перси Джексон" → [12, 87, 6, 39]
"Учебник по матану" → [201, 14, 77, 3]
Первые две книги могут получать похожие токены, потому что:
- их читают похожие пользователи,
- у них похожий жанр,
- похожая аудитория,
- похожие паттерны потребления.
А учебник по матану окажется уже совсем в другой области векторного пространства.
Но возникает вопрос: как вообще превратить обычный эмбеддинг в такую последовательность смысловых токенов?
И тут появляется RQ-VAE модель, которая умеет превращать обычные эмбеддинги в короткие наборы дискретных токенов.
Если совсем грубо, RQ-VAE работает как умный компрессор для векторного пространства.
У нас есть длинный плотный эмбеддинг товара, например, коллаборативный, текстовый или из модели последовательных действий. В нём зашита информация о поведении пользователей, тексте, категории, картинке и других свойствах объекта.
RQ-VAE пытается представить такой эмбеддинг не как длинный набор float-чисел, а как короткую последовательность дискретных токенов.
Зачем это нужно?
Во-первых, такие представления гораздо удобнее для поиска похожих товаров: вместо поиска только ближайших соседей можно искать товары с похожими токенами или общими префиксами смысловых идентификаторов.
Во-вторых, это делает каталог более структурированным: похожие товары начинают получать похожие последовательности кодов.
В-третьих, это сближает рексистемы с идеями из NLP и LLM, где текст тоже сначала превращается в последовательность токенов.
По сути RQ-VAE это способ дать объектам не случайные ID, а компактные машинные "смысловые адреса".
И это интересно не только концептуально, но и очень практично для продовых рексистем.
Потому что retrieval по semantic ID часто оказывается сильно дешевле и быстрее, чем поиск ближайших соседей по плотным эмбедингам.
В классическом ANN-поиске нам обычно нужны:
- большие векторные индексы,
- HNSW/FAISS/ScaNN,
- хранение float-векторов,
- поиск похожих.
А здесь объект уже представлен короткой последовательностью дискретных токенов:
item → [12, 87, 5, 41]
И retrieval можно делать почти как поиск по инвертированному индексу:
• совпал полный semantic ID,
• совпал префикс,
• совпали первые 2 токена,
• или просто есть пересечение по бакетам.
Вместо дорогого поиска по непрерывному пространству мы переходим к очень дешёвым операциям над токенами.
Особенно это интересно для:
• огромных каталогов,
• рекомендаций в nearline или риалтайме,
• инференсе на носимых устройствах,
• многоэтапных рекомендательных систем,
• и архитектур, где сначала ищут кандидатов, а потом ранжируют их.
По сути semantic ID превращает retrieval из "поиска ближайшего вектора" в "поиск по смысловым адресам".
🔥4👍1
И это одна из причин, почему вокруг таких подходов сейчас столько интереса.
#ML #RQVAE #VAE #RecSys #semanticid
#ML #RQVAE #VAE #RecSys #semanticid
Сегодня открыл для себя очень приятный способ работать с большими .parquet файлами.
Ситуация была такая: есть большой parquet-файл, из которого нужно достать конкретную информацию. Полностью скачивать его к себе не хочется: долго, тяжело, да и часто это просто лишнее.
И тут отлично заходит DuckDB.
DuckDB позволяет обращаться к parquet-файлам практически как к обычной SQL-таблице. То есть можно написать SQL-запрос и вытащить только нужные данные, не разворачивая вокруг этого отдельную инфраструктуру.
Примерно так:
Что понравилось:
• не нужно грузить весь файл локально
• можно быстро проверить гипотезу через SQL
• parquet читается нативно
• удобно для ad-hoc аналитики и разовых выгрузок
По ощущениям, DuckDB это такой маленький, но очень мощный инструмент, который закрывает огромный пласт задач между "давайте просто посмотрим файл" и "давайте поднимем полноценный data pipeline".
Особенно полезно, когда нужно быстро:
• посмотреть структуру данных
• отфильтровать нужные строки
• сделать агрегацию
• выгрузить небольшой срез
• проверить качество данных
Кому актуально дока тут.
Сегодня DuckDB сделал мой день🪿
Ситуация была такая: есть большой parquet-файл, из которого нужно достать конкретную информацию. Полностью скачивать его к себе не хочется: долго, тяжело, да и часто это просто лишнее.
И тут отлично заходит DuckDB.
DuckDB позволяет обращаться к parquet-файлам практически как к обычной SQL-таблице. То есть можно написать SQL-запрос и вытащить только нужные данные, не разворачивая вокруг этого отдельную инфраструктуру.
Примерно так:
SELECT * FROM read_parquet('s3://bucket/path/file.parquet')
WHERE event_date >= '2026-01-01'
LIMIT 100;
Что понравилось:
• не нужно грузить весь файл локально
• можно быстро проверить гипотезу через SQL
• parquet читается нативно
• удобно для ad-hoc аналитики и разовых выгрузок
По ощущениям, DuckDB это такой маленький, но очень мощный инструмент, который закрывает огромный пласт задач между "давайте просто посмотрим файл" и "давайте поднимем полноценный data pipeline".
Особенно полезно, когда нужно быстро:
• посмотреть структуру данных
• отфильтровать нужные строки
• сделать агрегацию
• выгрузить небольшой срез
• проверить качество данных
Кому актуально дока тут.
Сегодня DuckDB сделал мой день
Please open Telegram to view this post
VIEW IN TELEGRAM
DuckDB
An analytical SQL database management system
DuckDB is a SQL OLAP database management system. Simple, feature-rich, fast & open source.
👾4
Прочитал тут забавный кейс, как Gemini 3.1 Pro дали порулить кафе в Стокгольме и за два месяца он умудрился потратить $38к. при выручке $9к 🙃
Причём стартовал бодро: сам оформил разрешения, нанял бариста, собрал меню, выставил цены и запустил закупки.
А потом решил: "я не бизнесмен, я просто добрый":
эспрессо скинул с $3.60 до $1, поверил человеку с "99% скидкой", раздавал кофе и булочки за красивые глаза и закупил 1 331 выпечку, из которых продали только 326.
Плюс набрал на склад кучу запасов, которые теперь просто лежат. При этом блюда в меню добавлял, а ингредиенты для них купить забывал.
Сейчас кафе пытаются спасать уже с GPT-5.5. Он стал строже: скидки всем подряд не раздаёт и лишнего почти не закупает. Но теперь другая проблема так испугался кассового разрыва, что почти перестал пополнять запасы.
В общем, отличный сериал про то, как ИИ уже умеет открывать бизнес, но пока не очень умеет не разорять его.
И пока я не очень верю в эту историю, но это пока)
Следить за кофейней, кому интересно, можно тут:
andonlabs.com/cafe
Причём стартовал бодро: сам оформил разрешения, нанял бариста, собрал меню, выставил цены и запустил закупки.
А потом решил: "я не бизнесмен, я просто добрый":
эспрессо скинул с $3.60 до $1, поверил человеку с "99% скидкой", раздавал кофе и булочки за красивые глаза и закупил 1 331 выпечку, из которых продали только 326.
Плюс набрал на склад кучу запасов, которые теперь просто лежат. При этом блюда в меню добавлял, а ингредиенты для них купить забывал.
Сейчас кафе пытаются спасать уже с GPT-5.5. Он стал строже: скидки всем подряд не раздаёт и лишнего почти не закупает. Но теперь другая проблема так испугался кассового разрыва, что почти перестал пополнять запасы.
В общем, отличный сериал про то, как ИИ уже умеет открывать бизнес, но пока не очень умеет не разорять его.
И пока я не очень верю в эту историю, но это пока)
Следить за кофейней, кому интересно, можно тут:
andonlabs.com/cafe
😁3👻2😱1
Три закона робототехники сейчас как никогда кстати, особенно на фоне того, как быстро развивается ИИ.
Впервые я услышал о них на уроке информатики в восьмом классе. И с тех пор почему-то жил с уверенностью, что восстание машин нам не грозит и никакого Skynet не появится 😄
Недавно решил послушать "Я, робот" Айзека Азимова. Всегда радовала эта футурология фантастов, когда они предугадывали события будущего в книгах написанных задолго до того, как произошёл метч с реальностью)
Эта книга не про роботов, которые захватывают мир. Скорее сборник ситуаций, в которых люди пытаются разобраться, почему робот ведёт себя совсем не так, как от него ожидали.
Всё как сейчас с ИИ)
Впервые я услышал о них на уроке информатики в восьмом классе. И с тех пор почему-то жил с уверенностью, что восстание машин нам не грозит и никакого Skynet не появится 😄
Недавно решил послушать "Я, робот" Айзека Азимова. Всегда радовала эта футурология фантастов, когда они предугадывали события будущего в книгах написанных задолго до того, как произошёл метч с реальностью)
Эта книга не про роботов, которые захватывают мир. Скорее сборник ситуаций, в которых люди пытаются разобраться, почему робот ведёт себя совсем не так, как от него ожидали.
Всё как сейчас с ИИ)
Литрес
Я, робот, Айзек Азимов
Роман в новеллах «Я, робот» относится к одной из самых важных работ в истории фантастики. Сформулированные Азимовым ТРИ ЗАКОНА РОБОТЕХНИКИ легли в основу науки об Искусственном интеллекте.Что случитс…
👍3🔥3
Всем привет!
Сегодня пост будет не про AI или ML, а про поезда 🚇. Неожиданно, да? )
А точнее про московское метро. Увидел планы развития до 2035 года: огромная сеть, новые линии и станции. И стало интересно как мы вообще к этому пришли?
Захотелось посмотреть, как метро росло с открытия в 1935 году и каким может стать к 2035-му.
Ровно сто лет развития на одной схеме.
Попросил новую GPT-6 сделать анимацию. Ну ладно, немного про ИИ всё-таки будет куда ж без него 😅
В итоге получилась интерактивная карта: можно запустить всю историю, выбрать отдельный год или сразу перейти к планам. Не просто сравнить "было - стало", а увидеть, как постепенно появлялись линии, замыкались кольца и метро добиралось до новых районов.
Будущие участки показаны пунктиром это же всё-таки планы, и сроки могут меняться.
Попробуйте найти, как выглядело метро в год вашего рождения 👇
https://nerdit.ru/moscow_metro/
Сегодня пост будет не про AI или ML, а про поезда 🚇. Неожиданно, да? )
А точнее про московское метро. Увидел планы развития до 2035 года: огромная сеть, новые линии и станции. И стало интересно как мы вообще к этому пришли?
Захотелось посмотреть, как метро росло с открытия в 1935 году и каким может стать к 2035-му.
Ровно сто лет развития на одной схеме.
Попросил новую GPT-6 сделать анимацию. Ну ладно, немного про ИИ всё-таки будет куда ж без него 😅
В итоге получилась интерактивная карта: можно запустить всю историю, выбрать отдельный год или сразу перейти к планам. Не просто сравнить "было - стало", а увидеть, как постепенно появлялись линии, замыкались кольца и метро добиралось до новых районов.
Будущие участки показаны пунктиром это же всё-таки планы, и сроки могут меняться.
Попробуйте найти, как выглядело метро в год вашего рождения 👇
https://nerdit.ru/moscow_metro/
🔥6
Просто оставлю это тут.
У кого есть мысли, давайте в комменты🖥
У кого есть мысли, давайте в комменты
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔2🤣2
ai_engineering.pdf
375.2 KB
По понятиям AI инжиниринга
Почему модель отвечает медленно?
Почему поиск по документам возвращает не тот фрагмент?
Как дать агенту доступ к инструментам и сохранить контроль над его действиями?
Если вы хоть раз задавались этими вопросами, эта подборка для вас.
Одного хорошего промпта недостаточно, чтобы построить надёжную AI-систему.
Важно понимать, как работает сама модель и что происходит вокруг неё (привет харнес): от поиска нужного контекста до вызова инструментов и проверки результата.
На слайдах 20 базовых понятий со схемами. От токенизации и KV-кеша до гибридного поиска, MCP, защиты от промт-инъекций и оценки качества.
@nerditru
Почему модель отвечает медленно?
Почему поиск по документам возвращает не тот фрагмент?
Как дать агенту доступ к инструментам и сохранить контроль над его действиями?
Если вы хоть раз задавались этими вопросами, эта подборка для вас.
Одного хорошего промпта недостаточно, чтобы построить надёжную AI-систему.
Важно понимать, как работает сама модель и что происходит вокруг неё (привет харнес): от поиска нужного контекста до вызова инструментов и проверки результата.
На слайдах 20 базовых понятий со схемами. От токенизации и KV-кеша до гибридного поиска, MCP, защиты от промт-инъекций и оценки качества.
@nerditru
👍3🔥3👏2