Kyryl opens ML

Просто використовуйте PostgreSQL Одна з кращих статей, які я бачив, це "Postgres: A Better Message Queue than Kafka?". Прагматична, продумана і варта перечитування час від часу. Коротко кажучи - використовуйте нудні технології, бенчмаркайте і не вірте в "відомі факти, патерни чи антипатерни". Насправді ви можете використовувати PostgreSQL для всього. "PostgreSQL is Enough" - це дуже смішний список юзкейсів, які ви можете вирішити за допомогою PostgreSQL - спростіть все, використовуючи лише PostgreSQL. Дуже весело і прагматично водночас. P.S. Сподіваюсь, що SurrealDB незабаром перевершить PostgreSQL як універсальний інструмент!

Статті “Як ми працюємо" і чому вони мені подобаються Мені дуже подобаються статті на тему "Як ми працюємо", особливо, коли вони від CEO. Набагато кращі за будь-який опис, відредагований HR, який, в своїй більшості, не відповідає дійсності. Вони будуть корисними, якщо ви хочете приєднатися до компанії чи просто хочете запозичити деякі ідеї для вашої поточної організації. Два чудові приклади, як на мене: 1️⃣ "How We Work" from Railway 2️⃣ "How We Work" from Warp

Argilla on the train! TLDR: Розгорніть Argilla на Railway за допомогою простого шаблону Для тих, хто працює з GenAl і хоче побудувати data moat для свого продукту, зверніть увагу на Argilla - чудова тула для розмітки тексту, яка підтримує багато юзкейсів і має дуже зручний UI. Для того, щоб легко спробувати, почніть з Railway - Heroku не курця, і простого шаблону, який я додав вище.

Великі вектори і великі перемоги! На роботі ми часто бенчмаркаємо різні векторні бази даних, і, звичайно, дивимось на публічні бенчмарки також. Наприклад, від Erik Bernhardsson. І з ними завжди була проблема - невеликий об'єм даних, а саме кількість і розмірність векторів. І недавно Pinecone запустив новий бенчмарк на більший реалістичний сценарій даних. І не тільки запустив, але і усіх там переміг! Одразу на думку приходить одна картинка) Але тим не менш) вітаю з перемогою, цікаво було б побачити там інших вендорів також!

Чудове рев'ю про бази даних у 2023 Людина, за якою варто слідкувати, якщо ви цікавитесь DB - Andy Pavlo, кожен рік випускає рев'ю всього, що сталось за цей час у світі баз даних. Рев'ю за 2023 тут - роздуми про векторні бази даних, в SQL додали графи і багато-багато драми! Цитата: You don't need to watch movies or television shows for entertainment! You can get all the drama you need in your life through databases!

Велике оновлення Seldon і новий тренд в розгортанні ML моделей Давно використовуємо Seldon для інференсу ML моделей, і десь пару місяців назад я помітив, що вони оновили все на версію 2. Багато змін і нових концептів, але найголовніший для мене це оверкомітмент - коли ви додаєте більше моделей на один сервер, ніж він може одночасно запускати. Таким чином ви отримуєте економію на інфраструктурі за рахунок швидкості. Цікавий патерн, який я бачу все частіше і частіше. Більше про це можна почитати в їх документації або в оригінальній статті від авторів Seldon.

Open-source LLM stack Недавно розповідав про open-source LLM стек, і що змінилось в ньому в порівнянні з класичним ML. Якщо вам не вистачає огляду open-source інструментів - ця доповідь саме для вас

Три найбільші сигнали для мене які я виніс для себе з вебінарів у попередньому пості 1️⃣ Rust. Всі хвалять Rust за перформанс і продуктивність команди - дуже сильний сигнал почати його вчити. 2️⃣ ML моделі в базі даних. Ідея тримати ML моделі в базі даних дуже цікава. Я вже не вперше її бачу, в SurrealDB схожа фіча. Звучить дивно, але варто самому спробувати. 3️⃣ Lance формат. Якщо у вас є час лише на один вебінар, подивіться про Lance - найбільш корисний, як на мене!

Коли ML зустрічається з базами даних Дивився дуже цікаву серію вебінарів про застосування ML в базах даних і навпаки, дуже рекомендую. Їх ведучий викладає в Carnegie Mellon University декілька курсів з баз даних і “підсмажує” спікерів протягом цих вебінарів. 👇 Мої субʼєктивні враження: 1. Qdrant - трохи mean СТО розповідає про будову векторної БД. 2. PostgresML - цікава імплементація про те, як тримати свої моделі в базі даних і не пересувати дані без потреби. 3. Akamas і Ottertune - цікаві тули для тюнінгу ваших баз даних замість людини. 4. Lance - напевно, найкращий вебінар з усіх. Надзвичайне враження - чесно, не знаю, хто буде використовувати щось інше для векторів, крім їх формату. Інші мені не дуже запам'ятались або були не такі цікаві. В наступному пості опишу сигнали в індустрії, які я помітив.

Одна велика LLM чи багато маленьких? Питання на мільйон. Чи будуть в майбутньому будувати продукти на основі однієї величезної моделі - GPT-4-Turbo або інших, чи на основі сотень-тисяч менших моделей? Я думаю, що ринок і кількість застосувань достатньо великий для того, щоб обидва підходи знайшли своїх прихильників. Як фанат open source, я би, звичайно, хотів бачити більше другого патерну: велика кількість невеликих LLMs. І тут є пару помилкових уявлень, які я б хотів розвіяти. Якість: напевно, найпростіше - натренована LLM для вашої конкретної задачі зазвичай буде краща за узагальнену LLM, навіть, якщо поступається їй в розмірах. Ціна тренування: навчання LLM за допомогою LoRA (якщо ви не знаєте, що це таке - подивіться тут) - надзвичайно ефективно з точки зору кількості даних (сотні прикладів) і ціни GPU (десятки доларів). Більше конкретних цифр тут. Ціна обслуговування: а оце вже цікаво! Скажімо, ми натренували 100 LLMs за допомогою LoRA за невелику ціну, але для обслуговування всіх цих моделей треба велика інфраструктура, для простоти, скажімо, 100 серверів. І тут на допомогу знову приходить природа методу LoRA! Ми можемо зменшити кількість серверів до одного, а саме будемо підміняти параметри натренованих LLMs в реальному продакшені на кожен запит. Приклад такого рішення. І ціна такого підходу 200ms для динамічної зміни моделей! Ідея надзвичайна крута і в huggingface є низькорівневе API, яке дозволяє вам це заіплементувати собі! Отже, відповіді на питання “Одна велика LLM чи багато маленьких?” ніхто не знає, мій прогноз - обидва підходи спрацюють, але другий робити надзвичайно весело!

Заходить в бар Q&A Chain і Agent Звучить як початок несмішного жарту! Але, якщо серйозно, мені завжди було цікаво порівняти як детермінована система (Chain), буде працювати в порівнянні з агентом (Agent): 🔗 Chain: Задали питання -> дістали релевантний контекст з бази даних -> запитали LLM. 🤖 Agent: Ось база даних і LLM -> роби що хочеш, але відповідай на питання На цих вихідних я протестував це наступним чином - Chain і Agent повинні були відповідати на питання про SurrealDB, використовуючи документацію як базу знань. Питання від простих: “що таке SurrealDB?”, до: “ось SQL запит, скажи, як його виконати в SurrealDB”. Що вийшло в результаті? На мою думку Agent набагато краще впорався з моїми запитами, ніж Chain. Повний код з результатами можна подивитись тут 👇 https://github.com/truskovskiyk/surrealdb-docs-retrieval

Your only moat is data moat і новий продукт для цього Тема захищеності бізнесу (defensibility) або питання “який у вас moat”, дуже часто виникає у розмовах інвесторів. Якщо ви будуєте нові фічі за допомогою GPT4 або аналогів, що завадить вашим конкурентам зробити те саме, і, можливо, навіть швидше за вас? Як не стати просто компанією-обгорткою навколо API від OpenAI? Я не маю точної відповіді, але, можливо, маю перше наближення до неї. Особисто для мене, ваш “moat” це дані: те, як ви їх зберігаєте, як оцінюєте результати, як розмічаєте і, найголовніше, те, як ви потім плануєте використати їх для тренування власної LLM. LangSmith - один з найновіших інструментів (хоча, існує ще дуже багато інших аналогів), який можна використовувати для data moat. Він має функції для моніторингу, евалюації та створення датасетів. Ще не мав досвіду з ним в продакшені, але виглядає дуже круто!

Коли технічний пост стає дуже політизованим та майже спричиняє PR катастрофу У нас в Georgian багато матеріалу, який ми би хотіли опублікувати, але найбільший bottleneck зараз це compliance відділ - люди, які перевіряють всі матеріали на те, щоб не було проблем з публікацією. Які саме можуть бути проблеми - розглянемо на прикладі. Компанія Instacart написала чудовий технічний пост How Instacart Ads Modularized Data Pipelines With Lakehouse Architecture and Spark. Це архівна версія, тому що оригінальний пост видалили. Отже, чудовий пост, корисна інформація - в чому драма? А в тому, що Instacart раніше використовувала Snowflake, а в цьому пості пише, що на додачу використовує Databricks, найбільшого конкурента Snowflake, і що використання Databricks допомогло їм зменшити витрати. Ба більше, CEO Snowflake є в раді директорів Instacart, тобто він є начальником CEO Instacart. Я можу лише уявити проблеми PR відділу Instacart та Snowflake піля цієї публікації і того, як Databricks почали форсити цей пост. В результаті, навіть Snowflake вийши з постом, де пояснюють ситуацію - Snowflake and Instacart: The Facts. Це той тип проблем, про які можна дуже легко забути, розробляючи технічне рішення, але кожне технічне рішення має як прямий бізнесовий вплив, так і величезний непрямий! Повна історія тут: Instacart’s IPO filing sparked an online spat between cloud rivals Snowflake and Databricks

Критерій для вашої retrieval системи В одному з постів я писав про критику retrieval систем і казав про важливість стабільного процесу для їх евалюації. Але як його побудувати, якщо у вас немає датасету, немає даних і ви тільки запускаєте проєкт? Мануальна евалюація буде найточнішим способом, але масштабувати це важко і дорого. Що працює для нас - використання LLM замість людини для оцінювання. Ви можете робити це для вашої retrieval бази даних чи end2end, гарний приклад тут. І практики, які мені подобаються, описані тут. Наскільки гарно працює такий підхід? Емпірично, з мого досвіду - доволі добре. Узгодженість між людиною і LLM досить висока, навіть для таких рішень, як зміна чогось в продакшені. Наприклад, яку модель для векторів використовувати чи як розбивати документи. Це також підтверджують відкриті дослідження - 80% узгодженості LLM з людиною, що є дуже високим показником.

One DB to rule them all Як ви обираєте базу даних для свого проєкту? Чи думаєте ви про дані і яка модель вам потрібна - SQL, як PostgreSQL, Document base, як MongoDB, чи у вас юзейкс, який вимагає графів, як Neo4j? База даних, яку я дуже хочу спробувати в реальному проєкті - SurrealDB! У них надзвичайно амбіційна ціль: поєднати всі ці моделі даних в одну базу даних і додати фічі, такі як full-text search, vector search і багато інтеграцій з ML. Якби мені треба було зараз починати проєкт, щоб не задумуватись про всі можливі юзкейси, які можуть виникнути в майбутньому, я б точно обрав цю базу даних, бо завжди є гнучкість змінити модель і тип запитів, які можна використовувати. + Rust в базах даних завжди виглядає цікаво. Чесно, виглядає як DB, на яку ми заслуговуємо!

Retrieval != Vector Search Знайшов неймовірну статтю, з якою я згоден на 100%, і радий, що твереза думка про Retrieval повертається. Трохи контексту - зазвичай ви можете покращити свої LLM за допомогою двох підходів: 1️⃣ Fine-tuning - коли ви довчаєте модель на нових даних (писав про це тут). 2️⃣ Retrieval Augmented Generation (RAG) - коли ви якимось чином знаходите (Retrieval) потрібну інформацію зі своєї бази даних і додаєте її в промпт LLM (Augmented), яка генерує вам більш точний результат (Generation). Напевно, в усіх прикладах RAG, які ви знайдете в open source, Retrieval відбувається за допомогою векторних баз даних, що є чудовим, але не завжди найкращим способом це робити. Робити RAG на векторах або на існуючій системі Retrieval? - це питання я постійно ставлю кожній компанії, з якою співпрацюю, і ніхто не може дати задовільну відповідь. Чому компанія A/B/C побудувала свій продукт на векторах? Тому що це круто і мало б працювати краще, правда, правда? Але ніхто цього ніколи не перевіряв! SQL/MongoDB/Elastic може бути гарним варіантом Retrieval для вашого юзкейсу. Без належного механізму оцінювання ви не дізнаєтесь. Але стверджувати, що вектори кращі - це просто припущення і спекуляція! ☝️ Retrieval не дорівнює Vector Search, і вам завжди потрібен механізм оцінювання.

Детальне пояснення про “Dagster + LLM + LoRA” Колись я написав пост про Dagster + LLM + LoRA, де використав багато базвордів. А сьогодні ми з командою, яка пише Dagster, випустили блог пост, де все це пояснюємо. Якщо вас цікавить як перестати працювати зі “спагетті кодом” в Jupyter notebooks і структурувати свій ML pipeline - 👉 деталі у блог пості і репозиторії А якщо хочете поспілкуватись про це по зуму і задати будь-які питання - розповідаю про це на конференції через 2 тижні. Промокоди на 2 безкоштовні квитки і 5 знижок в 50% у першому коментарі!

Трохи B.S. (bullshit) від CEO технічних компаній це окей По роботі часто спілкуюсь з СЕО різних компаній, і мені завжди приємно говорити з СЕО, яка/який знає технічну складову свого продукту. Одразу розумієш - ти б порозумівся з цією людиною. Але чи має бути СЕО технічної компанії технічним? Не в сенсі писати код і розбиратись з інфраструктурою, а розуміти високорівнево технічну складову і не нести B.S. під час розмови. На мою думку - ні. Трохи технічного B.S. від СЕО ніколи не завадить, ба більше, інколи навіть СТО розповідають відвертий B.S. з точки зору технічної складової (наприклад, коли роль СТО більше продуктова або організаційна, чи людина дуже давно не практикувала). Але, зазвичай, на мітингах коли це відбувається, немає інженерів. Звісно, не треба впадати в відверте шахрайство як Theranos, Frank чи Nikola, або не розбиратися взагалі і називати AGI - GenAI, наприклад. Але до невеликих перебільшень чи технічних помилок десіжн мейкери ставляться толерантно.

Драми в ML ком’юніті і компанія, за якою варто слідкувати! Обожнюю драми в ML ком’юніті! Одна з останніх, за якими я слідкую, - компанія FriendliAI судиться з Hugging Face, що якось не дуже френдлі з їх боку😅 через одну фічу в веб сервері для LLM від Hugging Face, який ми, до речі, багато де використовуємо. FriendliAI Inc. v. Hugging Face, Inc. - почитайте документ позову, там цікаво, прямо з посиланнями на коміти і тп. Але переможець цього літа, звичайно, компанія Stability AI та їх CEO, який генерує велику кількість драми та уваги до себе. Його дебати з виданням форбс - окремий вид контенту. Але, якщо відкинути драму, цікавий момент трапився цього тижня: колишній Head of Reseach зі Stability AI, який недавно звільнився, оголосив про створення власної компанії - Sakana AI, яка, по опису, скоріше за все, буде розробляти свої foundation models (типу Llama2 та GPT4), що, враховуючи профайл засновника, обіцяє бути дуже цікавим і вартим, щоб за цим слідкувати!