Mistral: Voxtral TTS, Forge, Leanstral, & what's next for Mistral 4 — w/ Pavan Kumar Reddy & Guillaume Lample

Mistral: Voxtral TTS, Forge, Leanstral и что дальше у Mistral 4 — с Pavan Kumar Reddy и Guillaume Lample

Mistral идёт без остановки — частые успешные релизы моделей легко заставляют забыть, что в прошлом году они привлекли крупнейший в истории европейский AI-раунд. Эпизод про Mistral назрел давно, и нам очень повезло поработать с Sophia и Howard, чтобы поговорить с Pavan (руководитель Voxtral) и Guillaume (Chief Scientist, сооснователь) по случаю запуска на этой неделе Voxtral TTS:

Mistral не может сказать это напрямую, но бенчмарки намекают, что это по сути TTS-модель уровня ElevenLabs с открытыми весами (технически это многоязычная low-latency TTS-модель с открытыми весами на 4B параметров на базе Ministral, которая имеет win rate 68.4% против ElevenLabs Flash v2.5). Вклад заключается не только в открытых весах, но и в открытых исследованиях: мы также уделяем приличную часть подкаста обсуждению их архитектуры, которая сочетает авторегрессивную генерацию семантических речевых токенов с flow matching для акустических токенов (что обычно применяется только в области генерации изображений, как показано на воркшопе по Flow Matching на NeurIPS от ведущих авторов, на которых мы ссылаемся в подкасте).

Можно ознакомиться с статьёй здесь, а полный эпизод доступен на YouTube!

Таймкоды

00:00 Приветствие и гости00:22 Анонс Voxtral TTS01:41 Архитектура и кодек02:53 Понимание против генерации05:39 Flow Matching для аудио07:27 Голосовые агенты в реальном времени13:40 Эффективность и стратегия моделей14:53 Видение голосовых агентов17:56 Корпоративное развёртывание и приватность23:39 Файнтюнинг и персонализация25:22 Корпоративная персонализация голоса26:09 Модели длинной речи26:58 Достижения real-time энкодеров27:45 Масштабирование контекста для TTS28:53 Что делает модели маленькими30:37 Компромиссы объединения модальностей33:05 Миссия открытого кода35:51 Lean и формальные доказательства38:40 Перенос reasoning и агенты40:25 Следующие фронтиры в обучении42:20 Найм и AI для науки44:19 Forward Deployed инжиниринг46:22 Цикл обратной связи с клиентами48:29 Завершение и благодарности

Расшифровка

swyx: Ок, добро пожаловать в Latent Space. Мы в студии с нашим со-ведущим Vibhu. Добро пожаловать. Спасибо. Тоже взволнован этой беседой, так же как и Guillaume и Pavan из Mistral. Добро пожаловать. Рад быть здесь.

Guillaume: Спасибо.

swyx: Pavan, ты руководишь аудио-исследованиями в Mistral, а Guillaume — ты Chief Scientist,

Анонс Voxtral TTS

swyx

Ведущий

(00:05) Окей. (00:05) Добро пожаловать в Latent Space. (00:06) Мы в студии с нашим верным со-ведущим Vibhu. (00:09) Добро пожаловать.

Vibhu

Ведущий

(00:11) Очень рад этому.

swyx

Ведущий

(00:12) А также Guillaume и Pavan из Mistral. (00:15) Добро пожаловать. (00:16) Рад быть здесь. (00:17) Спасибо, что пригласили.

(00:18) Pavan, ты руководишь аудио-исследованиями в Mistral, а Guillaume — ты Chief Scientist. (00:23) Что мы сегодня анонсируем, ради чего мы координируем этот релиз с вами?

Guillaume

Гость

(00:26) Да, мы выпускаем Voxtral TTS. Это наша первая аудиомодель, которая генерирует речь. Это не наша первая аудиомодель. У нас было несколько релизов до этого.

(00:35) Летом был Voxtral, наша первая аудиомодель, но это была модель для транскрипции, ASR. Несколько месяцев спустя мы выпустили обновление поверх неё с поддержкой большего числа языков. А также много базовых функций для наших клиентов: context biasing, точность, таймстампы и транскрипция. У нас также есть real-time модель, которая может транскрибировать не только в конце уровня.

(00:56) Не нужно заполнять весь аудиофайл, она может работать и в реальном времени. А здесь это естественное расширение в аудио — то есть генерация речи. Да, мы поддерживаем девять языков, и это довольно маленькая модель, 3B модель, очень быстрая и при этом state-of-the-art. Работает на том же уровне, что и базовая модель, но гораздо эффективнее по стоимости — лишь часть стоимости наших конкурентов.

(01:22) И мы также выпускаем работу, на которой основана эта модель.

swyx Какой решающий фактор?

Guillaume Хороший вопрос.

swyx

Их будет больше. Да, Pavan, какие-нибудь исследовательские заметки добавишь?

Архитектура и кодек

Pavan: Это новая архитектура, которую мы разработали внутри.

Мы перепробовали несколько внутренних архитектур и остановились на архитектуре auto-regressive flow matching. А также у нас новый собственный нейросетевой аудиокодек. Который преобразует это аудио в латентные токены — семантические и акустические. И да, это новая часть этой модели, и мы очень рады, что она получилась такого хорошего качества. Как упомянул Guillaume, это 3B модель. Она основана на модели, которую мы выпустили буквально несколько месяцев назад, и в основном предназначена для TTS, но текстовые возможности тоже на месте. Да.

swyx: Так что есть о чём поговорить.

Я всегда люблю всё, что связано с новыми кодировками и подобным, потому что это, очевидно, даёт большую эффективность, но также иногда баги. Ты раньше был в Gemini и работал над post-training для языковых моделей, а у многих будет меньше опыта с аудиомоделями в целом по сравнению с чисто языковыми.

Что тебе пришлось переосмыслить с нуля, когда ты пришёл в Mistral и начал этим заниматься?

Понимание против генерации

Pavan: когда речь идёт о, я думаю, есть две корзины: понимание аудио и генерация аудио [00:03:00].

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

К твоему вопросу о том, как аудио подаётся в модель: в модели понимания это очень похоже на Pixtral модели, которые мы тоже выпустили,

swyx: да.

Pavan: Это

swyx: потрясающе.

Pavan: Это было довольно... это был первый проект, над которым я работал после прихода в Mistral. Это было очень приятно. И Voxtral был очень похож по духу.

То есть мы подаём аудио через аудио-энкодер, аналогично изображениям через vision-энкодер, и он производит непрерывные эмбеддинги, которые подаются как токены в основную трансформер-модель — декодерный трансформер. Да. На выходе модели просто текст. То есть на стороне вывода ничего делать не нужно в моделях такого типа.

Я думаю, интересная часть в генерации — это то, что на выходе теперь нужно производить аудио. И подход, который мы используем, — это нейросетевой аудиокодек, который преобразует аудио в эти латентные токены. Существует много исследований и моделей, основанных на этом подходе.

И мы приняли несколько иные дизайн-решения вокруг этого. Но в конечном итоге нейросетевой аудиокодек преобразует аудио в набор латентов с частотой 12.5 Гц. И каждый латент содержит семантический токен и набор акустических токенов. И идея в том, что вы берёте эти дискретные токены и подаёте их на вход.

Есть несколько способов использовать это на каждом фрейме, но мы просто суммируем эмбеддинги. Это как иметь несколько разных словарей. Объединяем их все, потому что они все соответствуют одному аудиофрейму на стороне ввода. Сторона вывода — это интересная часть. На стороне вывода, не знаю, самая ли это популярная, но одна из

популярных техник — это depth transformer [00:05:00], потому что у вас K токенов на каждом шаге времени, тогда как с текстом у вас просто один токен на каждом шаге времени. Так что вы просто предсказываете токен из словаря, да, вы получаете вероятность

swyx: Это очень прямолинейный текст. Очень

Pavan: прямолинейный.

swyx: Да.

Pavan: Но если у вас K токенов, то наивным подходом было бы предсказать все они параллельно. Это не работает. По крайней мере, работает не очень хорошо, потому что у аудио больше энтропии. И одна из техник, которую используют, — это depth transformer, где у вас есть почти маленький трансформер, или это может быть LSTM, но люди используют трансформеры, и вы предсказываете K токенов авторегрессивно.

То есть у вас идёт две авторегрессии.

Flow Matching для аудио

Pavan: То, что мы сделали по-другому, — вместо этого авторегрессивного K-шагового предсказания у нас flow matching модель. Вместо моделирования как дискретного набора токенов, мы обучили кодек быть одновременно дискретным и непрерывным, чтобы иметь эту гибкость.

Мы пробовали и дискретный вариант, который тоже работает хорошо, но непрерывный работает просто лучше. Да, мы взяли этот flow matching, это [00:06:00] flow matching head, который берёт латент из основного трансформера и, как при диффузии, делает denoising, но в этом flow matching это оценка скорости.

То есть вы идёте от шума t вплоть до аудио-латента, который соответствует 80-миллисекундному аудио, а затем отправляется через декодер, чтобы получить обратно 80-миллисекундный аудиофрейм.

swyx: Да. Это первое применение flow matching в аудио? Потому что обычно я встречаю это в области изображений.

Pavan: Да. В некотором смысле есть flow matching модели в аудио, но я думаю, эта конкретная комбинация — могу ошибаться, может быть. Нет. Я не видел. Я не видел много работ в этом, так что думаю, это ново, и сообщество гораздо больше, они, я думаю, продвигают много этих работ по диффузии и flow matching, и интересно перенять некоторые идеи оттуда в аудио, и

swyx: да.

Pavan: Да, лично для меня это интересная часть, которую интересно пробовать. Один более общий момент — в отличие от текста, даже в vision, думаю, это верно, но в [00:07:00] аудио в литературе нет.

Победителя пока нет, нет такого «вот так нужно делать». Это всё ещё, я думаю, люди итерируют и выясняют, какой общий рецепт лучший. Я уверен, есть модели, которые полностью end-to-end, как NATO audio. NATO audio, но всё ещё не пришли к точке схождения, где это правильный способ думать.

Это и делает эту область довольно интересной для исследования.

Голосовые агенты в реальном времени

Vibhu: Какие способы посмотреть на это?

Vibhu: Есть способы, где можно делать диффузию для генерации аудио, но если вы хотите real-time генерацию, это большая вещь с подходом, который, я полагаю, вы взяли. Да. И как вы оцениваете разные оси того, что вам важно?

Pavan: Хороший вопрос. Я думаю, мы — можно делать просто flow matching диффузию для всего аудио. Мы даже не пошли по этому пути, потому что одно из основных применений — это голосовые агенты, и мы хотим real-time стриминг, и это сценарий использования. Это не единственный сценарий, но один из основных, к которому мы хотим прийти.

Так что мы [00:08:00] выбрали авторегрессивный подход для этого. И внутри авторегрессивного пространства, опять же, можно делать по чанкам или можно делать... мы выбрали — лично я предпочитаю операции, которые проще, и мы попробовали: можем ли мы просто добавить аудио как ещё одну голову к нашей обычной трансформер-декодер модели, потому что это делает легче в перспективе end-to-end моделирование нативного аудио-текста.

Да. И это работает довольно хорошо. Так что мы пошли по этому пути и попробовали немного, но сам flow matching head — у нас был дискретный диффузионный подход, который тоже работает хорошо, но flow matching работает лучше.

swyx: Мне просто было любопытно, как вы вообще думаете об этом общем направлении исследований.

Когда вы работаете с аудио-командой, вы задаёте какие-то high-level параметры и позволяете им исследовать что угодно, или как это устроено между вами?

Guillaume: Нет, я думаю, это работает так, что мы приоритизируем вместе, что является самыми важными фичами, потому что в аудио можно сделать многое [00:09:00].

Да, я думаю, мы пытаемся. Это как мы должны делать вещи, например. В конечном итоге мы хотим построить полностью дуплексную модель, но мы не собираемся начинать сразу с этого, как делают некоторые в проектах, но

swyx: просто чтобы подтвердить, full-duplex означает, что она может говорить, пока я говорю, или

Guillaume: да.

Окей. Аудио. Да. Да. То есть в итоге мы туда придём, но для нас мы решили идти шаг за шагом. Так что мы начинаем с того, что важнее всего. Я думаю, поддерживать клиентов — транскрипция — самый популярный сценарий. Затем генерация речи, чуть раньше неё.

А затем уже больше, но попробовать объединить всё вместе. Но мы посчитали важным разделить вещи и оптимизировать каждую способность по одной, прежде чем мы

swyx: измерим это всё вместе. И супер-omni модель. Но

Guillaume: очень интересно, потому что как сказал Pavan, когда работаешь над другими доменами, есть много областей, где, думаю, не так интересно.

Например, во многих местах это по сути просто данные или создание новых сред, много [00:10:00] относительно простых вещей. Но вещи, где, думаю, исследование, возможно, не такое интересное. Тогда как в аудио так много способов реально построить эту модель, так много способов подойти к ней. Это и делает её, думаю, действительно интересной.

И что мы также пробовали для генерации речи — мы попробовали несколько подходов. Что интересно — даже несмотря на то, что они были чрезвычайно разными, под капотом всё равно похожие частицы, но flow matching оказался гораздо более естественным. Так что мы этим довольны.

swyx: Есть ли интуиция, почему flow matching просто моделирует речь лучше в каком-то естественном фундаментальном латентном измерении?

Pavan: Нет, я думаю, главное в том, что даже на конкретном шаге времени есть распределение вещей.

swyx: Да.

Pavan: Которые нужно предсказать, как способ интонирования. Вы уже знаете слово, которое произносите. Да. В пространстве ввода слово, скажем, мапится в один токен для простоты.

В большинстве случаев так и есть. Так что нет большой... вы просто выбираете слово, но в аудио даже одно и то же слово, даже вашим собственным голосом, может быть произнесено [00:11:00] так по-разному. И я думаю, любой подход, который моделирует это распределение, и flow matching — один из них.

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

И нельзя предсказать среднее, потому что это соответствует какой-то размытой речи или что-то вроде. Надо выбрать один. И тогда резкая

swyx: условная инференция.

Pavan: Да, именно.

swyx: Это всё покрывается под disfluencies, что, кажется, обычный термин искусства. Паузы, интонации. Кстати, мне нужно поблагодарить Sophia за организацию всего этого, включая некоторые из этих действительно хороших заметок, потому что

Pavan: Да.

swyx: я меньше знаком с аудио.

Pavan: Нет. Я думаю, disfluencies — это определённо одно из таких. Disfluencies — это больше про

swyx: это эмм-ы и подобное.

Pavan: Да, эм. И также повторения, как

swyx: да.

Pavan: Когда у вас «full of words», вы думаете, и повторяете слово.

swyx: Окей. Тогда как интонация — это другое, это [00:12:00] uptalk и всё такое.

Окей.

Pavan: Да. То есть много энтропии. И моделирование этого как распределения. И любая техника, которая помогает с этим, и depth transformer — это условный способ моделирования. А трансформеры действительно хорошо с этим справляются, даже если это мини-трансформер. Так что это тоже хорошо сработало у нас.

Просто основное опасение, когда у вас depth transformer: если у вас K токенов, нужно сделать K авто-шагов, верно? Даже если это маленькая штука, это K шагов, что очень тяжело по вакантности, скажем. А с flow matching мы смогли значительно это сократить. Так что мы делаем инференс за квад-шагов или 16 шагов, и это работает довольно хорошо.

И есть ещё более обычные техники, чтобы снизить это ещё больше, в крайнем случае до одного шага — мы пока этого не делаем, но фреймворк хотя бы поддаётся более эффективному. И да.

swyx: И ребята из image-сообщества это сделали.

Pavan: Да.

swyx: Невероятная работа, ребята. Да.

Pavan: Теперь вы просто отправляете промпт и получаете изображение.

swyx: Да. Удивительно, но недостаточно. Думаю, image-лаборатории используют эти техники в продакшене. Думаю, ощущение, что много исследовательских демо, но [00:13:00] ничего такого, что я мог бы использовать на телефоне сегодня.

Guillaume: Что было бы интересно — поскольку столько всего сделано в vision-сообществе по сравнению с аудио, есть так много long-infra. Да.

И так много вещей, которые мы можем сделать, чтобы улучшить это дальше. Так что это наша первая версия, но у нас столько способов сделать её гораздо лучше и гораздо эффективнее по стоимости, так что

swyx: да.

Guillaume: Так что это не новая область, конечно, но всё ещё столько всего можно сделать.

Идеально. Это

swyx: здорово. Я должен также упомянуть для тех, кто новичок в flow matching: создатель, его имя Alex, он провёл на NeurIPS, кажется, две NeurIPS назад очень хороший воркшоп. Один час про flow matching, рекомендую посмотреть.

Это другое дело, да?

Эффективность и стратегия моделей

swyx: По эффективности — я представляю, что причина, по которой это open weights, причина, по которой вы выбрали бэкбон 3.6B — у вас 3.4B, вы пытаетесь подогнать под какие-то аппаратные ограничения. Какие они?

Guillaume: Не обязательно, я думаю, нам важно в наших моделях, чтобы они были эффективными.

У нас есть [00:14:00] много отдельных моделей. Например, эта очень маленькая, очень эффективная. У нас также есть маленькая OCR-модель доступная. Очень эффективная. И я думаю, в проекте подход компаний — иметь общую модель, которая делает всего понемногу.

Но это также будет дорого. Здесь мы говорим: если вас волнует этот конкретный сценарий, можно использовать эту модель, она делает только это. Она в этом чрезвычайно хороша. И очень эффективна. Поэтому мы и можем — мы делаем OCR, действительно хорошие в этом.

И это будет гораздо более cost-effective, чем общая модель, которая содержит много возможностей, которые вам на самом деле не нужны. Да. Мы делаем общие модели, но также более кастомизированные.

Открытые веса и бенчмарки

Vibhu: Как она сравнивается с другими TTS моделями? Мы выпускаем open weights.

Мы просто её выкатываем. Думаю, она довольно хороша.

Pavan: Да, думаю, довольно хороша. Это определённо одна из лучших. Точно. Я бы сказал, что это лучшая open-source модель, но

Vibhu: расшифруйте сами.

swyx: Да.

Видение голосовых агентов

Vibhu: Почему сейчас? Как это вписывается в общее видение Mistral? Как вы видите голосовых агентов?

Как вы видите голос? Думаю, каждый год я слышу — окей, ты [00:15:00] голос, ты голос. Много архитектурных штук. Много end-time, которые вы решаете, но где вы видите голос?

Guillaume: У нас было столько клиентов, которые просили голос. Поэтому мы тоже хотели его построить.

Что интересно в этой области — в каком-то смысле, если взять что-то простое вроде транскрипции, не похоже, что это что-то очень сложное для модели. По сути, это распознавание паттернов. Это классификация — модели очень хорошо классифицируют, верно?

Тем не менее, когда вы с ними разговариваете, это ещё не на том уровне, верно? Вы не говорите с ними так же, как с человеком. О чём-то люди, возможно, не осознают — на английском всё ещё гораздо лучше, чем на любом другом языке, даже по сравнению с французским. Если говорить с моделью на французском, видишь, как люди разговаривают — они говорят очень медленно.

Они артикулируют максимально. Так что это не естественно, верно? Мы ещё не дошли до этого. И думаю, может быть, следующее поколение этого не будет знать. Но люди... наш век будет всегда сохранять эту склонность говорить очень медленно, когда они разговаривают с этой моделью. Хотя, может быть, года через два, может, в следующем году это уже не будет нужно.

Но интересно видеть, что даже для языков [00:16:00] вроде французского, испанского, немецкого, где нет проблем с ресурсами для распознавания. Аудио там полно, но всё равно не так хорошо. И как следствие. Потому что для этого, я полагаю, было вложено не столько энергии и усилий, как в других модальностях, таких как vision или coding.

Но прогресса ещё много можно сделать. Думаю, это просто вопрос работы, и путь к этому ясен.

Pavan: Это немного завораживает, потому что я работал над Google Assistant какое-то время назад, но если шагнуть назад, это завораживает.

Это было не так давно. Лет четыре или пять назад, а теперь это полностью audio in, audio out, и function calling, и всё происходит полностью end-to-end. И очень естественно,

swyx: да,

Pavan: естественно. И ещё есть куда расти. Guillaume говорил, даже несмотря на всё предыдущее, это не как разговор с человеком.

Когда вы говорите с любым из этих агентов, ботов или voice-режимов, всё равно есть разрыв. Думаю, это отличная часть, и я чувствую, что даже с существующим [00:17:00] стеком мы должны вскоре быть способны прийти к очень естественным разговорным способностям.

И мы тоже надеемся туда добраться.

Guillaume: Это как бы следующий шаг, верно? Потому что когда вы разговариваете с этими агентами, обычно люди просто пишут им, и иногда им это очень ясно — например, вы хотите написать код, но у вас есть очень чёткое представление о том, как вы хотите, чтобы модель реализовала задуманное.

Так что здесь вы можете тратить много времени на написание. Это не очень эффективно, тогда как аудио — это действительно естественный интерфейс, которого пока нет, но думаю, это просто станет нормой.

Vibhu: Каково это — строить, обслуживать, делать инференс — мы много видим, что очень легко взять LLM с полки, обслуживать их.

Файнтюнить, развёртывать. Знаю, у вас есть Forge, у вас целый стек кастомизации, развёртывания. Есть ли задержка в получении этого канала дистрибуции. Вы помогаете? То есть промптинг — LLM можно сделать краткими, многословными, всё такое.

Они построены на LLM бэкбонах, эти модели. Как вы видите всё это?

Корпоративное развёртывание и приватность

Guillaume: Да, это многое из того, что мы делаем с нашими клиентами. Очень [00:18:00] часто они приходят к нам по разным причинам. Думаю, одна причина — иногда у них много опасений по приватности.

У них есть данные, которые очень чувствительны. Они не хотят, чтобы данные покидали компании, хотят, чтобы они оставались внутри компании. Так что мы развёртываем модель у них в-house. На premise или в private cloud. Чтобы они не беспокоились, что они переданы третьей стороне с возможностью утечки.

Иногда у многих компаний есть разная чувствительность данных. Иногда канальный чат может отправить в облако, должен там оставаться. Это создаёт гетерогенные workflows, которые раздражают. Эти данные нельзя отправлять в облако, эти можно. Здесь, когда мы развёртываем модель для них, у них нет этой заботы. Они не беспокоятся, что это утечёт. Всё намного проще. Мы помогаем им сделать это, в основном. Это одно из value proposition. Но другое — очень часто, когда клиенты используют off-the-shelf закрытую модель, очень грустно, что они не используют данные, которые они собирали четыре года или десятилетия.

Так много данных. Иногда триллионы токенов [00:19:00] данных в очень специфическом домене. Их домен — данные, которые вы не найдёте в публичном интернете. Данные, к которым закрытые модели не имеют доступа, на которых было бы действительно хорошо обучить. Если используются closed-source модели, они по сути не пользуются всеми этими знаниями.

Всеми этими данными, которые они собирали годами, можно всегда подавать в контекст во Франции, но это никогда не так хорошо, как если действительно обучить модель на анализе. Это, по сути, то, что мы помогаем им делать. Мы предоставляем покупки, в основном то, что мы анонсировали на GTC на этой неделе.

Мы предоставляем им платформу с множеством инструментов для обработки данных, обучения на них. Да, это на самом деле то же самое, что мы используем в команде science. Так что это действительно протестированная инфраструктура с эффективным training cut base.

Для качественного pre-training, fine-tuning, даже делая SFT, RL. Мы помогаем им делать это, используя те же инструменты, что строит и использует наша команда science. Поскольку это инструменты, которые мы используем уже два года, они хорошо протестированы, действительно сложные.

Это то же самое, что мы даём им, давая компании то же самое [00:20:00], что мы используем внутри для построения собственного AI, и это действительно делает огромную разницу. Думаю, иногда клиенты и многие в целом не осознают, насколько модель становится лучше, когда вы дообучаете её на собственных данных.

И вы можете — ваша модель здесь, вы начинаете оттуда. У вас есть closed source модель примерно здесь, но если вы действительно дообучите, можете уйти гораздо дальше. И тогда у вас огромное преимущество. Модель обучена на всех знаниях вашей компании, она знает всё.

Не нужно подавать 10K токенов контекста при каждом запросе. Это намного проще. Использование closed source модели — это действительно грустно, потому что вы не используете все эти данные и будете использовать ту же модель, что и все ваши старые конкуренты, тогда как вы используете всё, что собирали годами, что действительно ценно.

Так что мы помогаем клиентам это делать. У нас много решений. Я имею в виду, у нас инженеры, которые приходят в компанию и смотрят на проблемы, с которыми сталкиваются клиенты, смотрят, с чем они борются, что нужно сделать, чтобы решить. Мы помогаем им решать вместе.

То есть наш подход немного другой, но здесь, [00:21:00] в некоторых других компаниях и конкурентах, мы не просто релизим endpoint и продаём что-то поверх, или не просто даём checkpoint. Мы действительно работаем очень тесно с клиентами. Смотрим на их проблемы, помогаем их решать.

Делаем действительно индивидуальные решения для клиентов. Несколько примеров — иногда у нас клиенты, которые хотели действительно хорошую модель, действительно производительную в некоторых, например, азиатских языках. Если взять модели с полки, они могут говорить, могут писать на этом языке, но не потрясающе.

Этот язык был бы около нуля или 1% от смеси. Так что он был включён во время обучения, но очень мало. Что мы сделали — мы обучили новую модель для них, но этот язык составил 50% смеси, так что он гораздо сильнее. Она знает диалекты, знает всё.

Это пример того, что мы можем делать, и это действительно индивидуально. У нас были клиенты, которые хотели 3B модель, которая делает аудио с очень хорошим function calling. Что-то, что хотели поставить в машину. Они хотели, чтобы это было офлайн, потому что в машине не всегда есть доступ к интернету.

Так что [00:22:00] мы можем строить решения. В интернете нет модели из коробки на этот счёт. У вас есть очень общая модель, generalist, сильная модель. Но для таких вещей всегда нужны конкретные решения. И по другим причинам.

Иногда они приходят к нам, потому что они экспериментировали с какой-то closed source моделью, сделали прототип, довольны тем, что построили. Работает хорошо, довольны производительностью, и потом хотят пойти в продакшен и анализируют. Но это чрезвычайно дорого.

Не получится это пушить. Тогда они возвращаются к нам, что мы можем помочь им построить то же самое, но используя что-то гораздо более дешёвое. И здесь иногда можем сделать что-то в 10 раз дешевле, просто дообучив модель, и это будет лучше on-prem на их старом сервере и также гораздо дешевле.

Так что да,

swyx: вот и pitch. Бери все

деньги.

Vibhu: И помимо этого, вы выпускаете open weight модели, чтобы люди могли делать это сами. Чувствую, недостаточно людей выходят из своей зоны комфорта.

swyx: Они не пойдут, они попросят его сделать как эксперта. Я

Guillaume: думаю, изначально мы не знали, [00:23:00] мы хотели полностью этого в начале компании. Думаю, наша стратегия была не совсем такой, как сегодня, но мы недооценили изначально сложность развёртывания этих моделей и подключения их ко всему, чтобы быть уверенными, что у них есть доступ к знаниям компании. И это было — мы видели, как клиенты борются с этим, но это было ещё три года назад, и теперь всё гораздо сложнее, потому что теперь у вас не просто текст SFT на простом instruction following.

У вас reasoning, агенты, инструменты. У вас мультимодальность, аудио, так что всё гораздо сложнее, чем раньше. И даже тогда клиентам было сложно. Так что им действительно нужна поддержка, и поэтому мы предоставляем forward deployed позиции. Процесс

Файнтюнинг и персонализация

swyx: Мне любопытно — есть ли также фaйнтюнинг голоса, который люди делают?

Pavan: В этом Forge у нас также единый фреймворк. И надежда — speech-to-text, который мы выпустили ранее в этом году. И даже Voxtral chat, который мы выпустили в прошлом году. И я думаю, есть [00:24:00] большая, богатая экосистема людей, делающих fine-tuning Whisper, и люди хотят того же с Voxtral, потому что он гораздо сильнее, чем Whisper.

И платформа предлагает такой fine-tuning, который может быть любого типа. Например, иногда люди хотят поддержать новые языки для этого — tail-языки, которые мы надеемся покрыть нативно, но если есть язык, где есть данные, и вы хотите дообучить, думаю, это хороший сценарий.

Или другие сценарии — тот же язык, например английский, но в очень domain-specific виде.

swyx: Да. Терминология, жаргон, медицинские штуки.

Pavan: Именно. И также специфические акустические условия — много шума или что-то. И модель будет работать прилично в большинстве условий, но всегда можно сделать лучше.

Это некоторые сценарии, где можно улучшить ещё больше. Это хороший сценарий, а для text-to-speech — мы только что выпускаем, так что поддержка скоро будет. Думаю, похожий сценарий.

Персонализация голоса

Pavan: Немного другое — то, как вы хотите расширить [00:25:00] text-to-speech модель: персонализация голоса, voice adaptation для предприятий.

Многим предприятиям нужен очень специфический тон, очень специфическая личность для такого голоса. И всё это — хорошие сценарии для fine-tuning.

swyx: Это я хотел спросить — мы никогда не говорили о клонировании голоса. Насколько это важно?

Я могу клонировать голос известного человека. Окей. Но

Pavan: основной сценарий был бы для корпоративной персонализации. Предприятиям нужно много кастомизации. Вы не хотите один и тот же голос для всех предприятий. Каждое предприятие хочет кастомизированный, специализированный голос, представляющий и их бренд, и их соображения безопасности. Думаю, то, что вы развернули бы как эмпатического ассистента в контексте healthcare, будет очень отличаться от того, что было бы в customer support боте, и отличаться от более разговорных аспектов.

Я думаю, такие [00:26:00] кастомизации можно ожидать от предприятий. И это основной сценарий, по крайней мере с нашей стороны.

Vibhu: Мой базовый пример — вы не хотите звонить в customer service и слышать тот же самый голос. Это будет странно.

Модели длинной речи

Модели длинной речи

Vibhu: Но также на технической стороне — в Voxtral было несколько вещей, которые показались мне интересными.

Он большой фанат этой статьи. Он сказал, очень хорошая статья. Сказал, это лучшая ASR-статья, которую он когда-либо читал. Я достаточно хайпил эту voice статью. Мы её освещали. Где-то, но большая вещь — Whisper известен 30-секундной генерацией, 30-секундной обработкой. Вы расширили это до 40 минут. В статье было много хороших деталей о том, как это сделано.

Даже мелкие ниши — например, padding. Нужно иметь этот padding, генерация синтетических данных вокруг этого. Хочу узнать, можете ли поделиться тем же про новую text-to-speech. Как вы генерируете long-form, связную речь?

Как вы это делаете? И есть ли gems? Будет статья?

Pavan: Да. Будет технический отчёт. Окей. Да, там будет много деталей.

Real-time достижения энкодеров

Pavan: Но я думаю, [00:27:00] резюме — некоторые соображения в этой статье были потому, что мы начали с Whisper-энкодера как отправной точки, а теперь у нас собственные энкодеры — например, real-time модель, которую мы выпустили в январе.

Также есть технический отчёт для этой real-time модели, это dual-stream архитектура. Интересная архитектура, стоит посмотреть. И там у нас causal-энкодер, и я не думаю, что в сообществе есть сильный многоязычный causal-энкодер. Так что мы посчитали, это хороший вклад.

Это хороший энкодер, который люди могут адаптировать. И мы обучили его с нуля. Думаю, наш стек теперь достаточно зрел, что мы можем обучать супер-сильные энкодеры. И некоторые соображения, вроде padding и подобного, — это функция Whisper-энкодера.

А теперь, когда мы обучаем энкодеры in-house, дизайн-соображения другие.

Масштабирование контекста для TTS

Pavan: А на вопрос о text-to-speech, думаю, это также опирается на оригинальный авторегрессивный декодер-бэкбон. Думаю, очень похожие соображения. Long-context — это даже не long con [00:28:00], потому что модель обрабатывает аудио на 12.5 Гц, так что одна секунда мапится в 12.5 токенов.

Так что одна минута — это около 7.8 токенов... до 10 минут в контекстном окне 8K, а полчаса — в 30K. Это 32K контекст — то, на чём мы очень комфортно обучаемся. Можем расширить даже дольше. 148K. Окей. Можно естественно видеть, как это можно расширить до даже более длинных генераций.

Да. Нам нужен правильный рецепт данных и алгоритм, чтобы работать связно через такой длинный контекст. Техники в чём-то очень похожи на моделирование long-context для текста. Ключевые отличия — просто делать flow matching авторегрессивно вместо предсказания текстового токена.

swyx: Окей. Думаю, это большая часть голосовых вопросов, которые у нас были. Но

Что делает модель маленькой

Vibhu: У меня большой вопрос про Mistral Small. Что такое small? Как мы определяем [00:29:00] small? Что это? Помню дни Mistral 7B на моём ноутбуке. Едва влезала на ноутбук. Я мог запустить её на большом ноутбуке, но

Guillaume: это просто вопрос терминологии. Здесь то, что мы сделали — это базовое количество активных параметров, но правда, не дали ему другое имя, но да, мы могли назвать medium, только я,

я полагаю, это модель, которую мы выпустили, mixture-of-experts. Это модель, которая объединяет разные модели, которые раньше мы делали так же — у нас была одна модель, общая модель для Mistral, делающая instruction following, отдельная модель для девелопмента, специфичная для кода, и другая модель для reasoning Mistral.

Это были отдельные артефакты, построенные разными командами в Mistral. И что мы делаем — мы по сути сливаем всё это. Был Pixtral Mistral — первая vision-модель, отдельная модель, но способ, которым мы делаем вещи внутри — у нас одна команда фокусируется на одной способности, строит одну модель.

Когда она достаточно зрелая, мы решаем слить это в [00:30:00] матрицу. Здесь это был первый раз, когда мы по сути соединили всё это в одно. Но есть некоторые вещи, которые мы делали впервые тогда, для объединения, например, больше способностей или function calling — это будет гораздо, гораздо лучше на платформе Mistral Small.

Это наша последняя модель, над которой мы работаем.

Vibhu: И да, ключевые штуки — она очень разреженная, 6B активных, довольно эффективно обслуживать. 256K контекст. Да,

Объединение способностей vs специалисты

swyx: Что интересно — это общая теория разработки индивидуальных способностей в разных командах и затем объединения их.

Куда это приведёт?

Vibhu: Мы видели пять вещей, собранных вместе. Да. Какие следующие пять команд?

swyx: Думаю, на самом деле OpenAI отошёл от оригинального видения 4o omni-модели. Это то, что они продавали. Все модальности на вход и все модальности на выход.

Но чувствую, вы можете это сделать.

Guillaume: Думаю, есть некоторые модальности, где это не конкурентоспособно. Например, для аудио. Здесь, если вы хотите делать транскрипцию, нет смысла использовать большую модель. Если вы просто хотите транскрибировать, это будет очень неэффективно. Если хотите делать аудио, вы, вероятно, хотите быть [00:31:00] 3B-моделью с такой же производительностью

swyx: по сути одинаковой.

Это будет невероятно дешевле. Так что здесь мы хотим иметь

Guillaume: отдельную, которая делает только это. Да, думаю, вопрос просто — если вы хотите задать модели по речи очень сложный вопрос, как это сделать — каскадировать вещи. Хотите ли вы засунуть всё в модель с одним ключом вокруг? Это не конкурентная дискуссия, не уверен, что вы идёте в этом направлении, но это возможно. Конечно. Но думаю, для нас следующие способности, которые мы хотим интегрировать в эти модели — это, например, маркетинг, или reasoning лучше, больше способностей, о которых не так много говорят, но они на дне, я думаю, для наших клиентов в разных индустриях, например, вещи вокруг legal computer. Эти все вещи модели из коробки не делают хорошо. Потому что люди, если вы не приоритизируете это, нет бенчмарка на это.

swyx: Это сделано как

Guillaume: сделать это хорошим — нужно просто делать работу. Извлекать что-то, обрабатывать [00:32:00] выражения. Да.

Но мы предлагаем подумать об этом.

swyx: Думаю, для голоса. Да. Ключевая вещь, наверное, за последний год или около того с Veo, Grok Imagine и всем этим — это соединение голоса с видео, верно? Чего люди не понимают — пространственный звук, потому что большинство TTS — это просто «я говорю в микрофон в идеальном студийном качестве».

Но когда есть видео, голос движется.

Pavan: Это правда. Соображение было немного другим в том смысле, что там это standalone артефакт, где вы получаете всё и потребляете. Но в разговорной обстановке нужна экстремально низкая задержка.

swyx: Да,

Pavan: стриминг был бы одним из основных соображений.

swyx: Можно построить гигантскую компанию, делая только это. Так что не нужно делать голос, но я просто говорил на тему слияния модальностей — это то, что меня удивляет, я как «вау». Все до, скажем, середины прошлого года просто делали эти пайплайны: окей, мы соединим TTS-модель с voice штукой и lip sync [00:33:00] штукой, и что там ещё.

Нет. Просто гигантская модель. Да.

Миссия open source

Vibhu: У меня вопрос из двух частей. Первая — это всё ещё открыто. Похоже, open source всё ещё очень важен для того, что вы делаете, и я просто должен упомянуть вашу статью. Январь 2024. Это одна Mistral of experts. Очень фундаментальное исследование, как делать хорошо.

MoE-статья выходит — очень хорошая статья для каждого. Это просто side tangent. Нет.

swyx: Эта штука была — мы вернули, 8x22 была как ядерная бомба для open source. Думаю, нужно больше 7B. Да. Да. Но эта стала больше противоположности нам.

Да. Я не помню это, помню — не думаю, что это был январь, верно? Это было на NeurIPS, и все на NeurIPS были декабрь, кажется, 25. Да. Модель тоже была.

Vibhu: Это, наверное, просто маленькое обновление.

swyx: Да. Нет, но у тебя есть точка.

Vibhu: Нет, надо это проверить. Но я хочу услышать больше широко об open source у вас, ребят, и когда вы спросили ранее [00:34:00] о том, что дальше, какие другие, side tapes вы делаете. Вы выпустили Leanstral. Это,

swyx: это не обязательно сюрприз. Я был — это не вписывается в моё представление о Mistral.

Guillaume: Да. Сначала по open source в целом — это действительно что-то, что относится к генезису компании. Думаю, мы начинали потому, что мы делали open source с самого начала и даже до этого. До этого мы с Tim были в Meta, мы выпустили LLaMA, и думаю, что было действительно приятно.

Увидеть, что до этого для большинства исследователей, например университетов, было невозможно работать с LLM. Не было LLM снаружи. И если посмотреть на многие техники, которые были разработаны после, например, open source все эти post-training подходы, например DPO, preference optimization — всё это было сделано людьми, у которых был доступ к этой модели.

И это было бы невозможно без этого. Так что это действительно делает движение быстрее. Мы действительно хотим внести вклад в эту экосистему. Думаю, это глубоко и также имеет большое влияние. Все эти статьи в open source community действительно помогают научному сообществу в целом двигаться быстрее.

Так что [00:35:00] мы хотим внести вклад в эту экосистему. Поэтому мы выпускаем очень детальные технические отчёты. Mistral и наша первая reasoning модель — куча результатов, что работает, что не работает. Думаю, полезно. Да, для аудиомоделей тоже делиться многими деталями, делиться ими для real-time модели.

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

Это страшное будущее. Мы не хотим в нём жить, мы действительно хотим, чтобы эти модели были доступны каждому. Интеллект должен быть доступен любому, кто может его использовать. Так что мы продвигаем эту миссию open source модели. Да. Не первая модель, не лучшая на свете. Да.

Lean и формальные доказательства

Guillaume: Leanstral, я думаю, это тоже шаг в этом направлении. Это немного отличается от того, что мы обычно выпускаем. Но у нас небольшая команда внутри [00:36:00] работает над этим. Формальное доказательство, формальная математика. Думаю, это тема, которая нас в целом волнует, и мы работаем над reasoning. Думаю, мы начали слишком рано — делать reasoning без LLM очень сложно, особенно когда работаешь с формальными системами, потому что количество данных ничтожно.

Это address-able сообщество людей, пишущих формальные доказательства. Но причина, по которой нам это нравится — если посмотреть на то, что люди делают с reasoning, проблемы, которые можно использовать. Обычно это будут проблемы, где можно верифицировать вывод. Например, все эти AIME проблемы, где решение — число от 1 до 1000.

Можно верифицировать, сравнить с эталоном или с выражением. Можно сравнить вывод выражения, сгенерированный с эталоном. Но во многих, в большинстве проблем и в большинстве reasoning проблем нет лёгкого способа верифицировать решение. Если вопрос — покажите, что F непрерывна — нельзя сравнить с эталоном, верно?

Если это доказательство, что это верно, или доказательство свойств, нет способа просто верифицировать корректность вашего доказательства. Так что сложно применить — здесь нет верифицируемого вознаграждения. Так что [00:37:00] то, что вы могли бы предоставить, это, конечно, судью, который будет смотреть на ваше доказательство. Но это очень сложно, и может произойти reward hacking.

Так что это сложно. Можно предоставить эталонное доказательство, но есть много способов доказать одно и то же. Если модель даёт негативное вознаграждение, потому что это другое доказательство, может быть, это всё равно валидное доказательство, просто другое. Так что не сработает хорошо. Что приятно с Lean и с формальным доказательством — не нужно беспокоиться об этом вообще.

Мы просто,

swyx: функция, которая в основном компилируется в Lean, функционально та же самая. Именно.

Guillaume: Если она компилируется, она корректна. Это очень легко. И можно применить, и тогда можно,

swyx: это просто слишком маленькое. Так что ни один человек не пойдёт и не сделает это.

Guillaume: Да, именно.

Это могут сделать только люди — очень маленький круг людей, делающих PhD на эту тему. Так что это супер мало. И это грустно, потому что это очень полезно не только для матема, но и для верификации программного обеспечения. Например, верификация ПО сегодня — крошечный рынок. Очень мало индустрий работают над этим, и нам это нужно.

Обычно это компании, строящие самолёты, аэро-робототехнику,

swyx: вроде

Guillaume: вещей [00:38:00], где они абсолютно хотят быть уверены. Жизнь зависит от этого, но очень редко люди формально верифицируют корректность своего ПО. Думаю, одна из причин — это просто сложно делать.

swyx: Вы думаете о TLA+? Это язык, который некоторые люди используют для верификации ПО? Нет. Что люди используют в [не уверен], но да, причина, по которой люди не используют это больше и почему индустрия не такая большая, как могла бы быть — это очень сложно. Но теперь с cutting edge, которые есть, всё будет очень иначе.

Guillaume: Мы увидим гораздо больше этого. Так что да, индустрия будет гораздо больше в будущем — эти модели. Так что да. Здесь, предвосхищая это немного, мы хотели работать над этим, потому что доказательство математической теоремы и, по сути, те же инструменты.

swyx: Да.

Перенос reasoning и агенты

swyx: Одна из моих теорий — поскольку доказательства занимают так много времени, это на самом деле просто прокси для long horizon reasoning, связности и планирования. Многие, возможно, скажут — окей, это для людей, которые любят математику. Это для — окей, это нишевый математический язык. Кому какое дело? Но на самом деле, и если вы используете это как часть data mixture для [00:39:00] post-training и reasoning, это на самом деле может всплеснуть везде.

Да. И думаю, это недоисследовано, или никто реально не выпустил окончательную статью о том, как это обобщается.

Guillaume: Да, абсолютно. И

Pavan: Думаю, даже

Guillaume: это то, что мы уже видим. Например, делайте reasoning на математике — американец должен делать reasoning ещё.

Да. На ранней стадии. Есть некоторый перенос, какая-то эмерджентность происходит. И интересно, это не просто тема в целом, но есть много связей с этим, включая агентов. Потому что иногда модель может видеть теорему, которую нужно доказать, она очень сложная, но затем может взять инициативу и сказать — я докажу эту теорему через леммы.

Я предложу леммы, и я в параллели докажу каждую. Три из них параллельно с sub-agents, но я также докажу их в теории и тулом. Так что можно делать это тоже. Довольно интересно. Даже если не получится доказать одну из лемм, можно, может, успешно доказать обычную лемму, так что получаете возможное вознаграждение здесь.

Так что это немного менее спартанский вопрос — просто получить ноль или один за всё. [00:40:00] Так что довольно интересно. Думаю, мы можем,

Vibhu: да, это также интересный случай просто для специализированных моделей в целом, верно? Cost-вещь, которую вы показываете, довольно интересна — похожий счёт, вы 30, 70, 100, 50, 300 баксов. Меньше.

swyx: Думаю, cost немного несправедлив, верно? Потому что это inference cost. Всегда сверху их маржа сверху. Но мы не знаем ничего другого, так что должны разобраться.

Vibhu: Окей.

Следующие фронтиры в обучении

Vibhu: Хотел на самом деле надавить на это больше. Не по cost, но вы упомянули — окей, это отличный способ иметь верифицируемый long-context reasoning.

Какие другие фронтиры — уверен, вы работаете внутри — много pushback на pre-training scaling, RL push, compute в сторону того, чтобы более половины training-бюджета было на RL. Где вы видите фронтир исследований в этом?

Guillaume: Вы имеете в виду

Vibhu: просто в foundation model training в следующем — одна вещь, которую вы делаете, — это фундаментальное исследование с нуля, верно? Так что у вас, наверное, есть действительно хороший взгляд, где [00:41:00] можно это прогнозировать.

Guillaume: Да. Думаю, для нас мы всё ещё много работаем на стороне pre-training.

Думаю, мы очень далеки от ситуации в pre-training. Думаю, ML для pre-training будет большим шагом по сравнению со всем, что мы делали до этого. Мы очень рады этому. И думаю, на другой стороне теперь нужно думать всё больше об этом алгоритме, который будет поддерживать эти очень длинные траектории.

Когда было, например, GRPO — это не работает с любой off-policy, что было окей изначально, потому что вы решаете math-проблемы, которые решаются за несколько тысяч токенов. Так что модель может рандомизировать их довольно быстро. Когда делаете обновление, модель никогда не слишком далеко.

Она никогда слишком далеко. Но теперь, когда движетесь к таким проблемам, где определённо занимает часы, например, шесть часов, чтобы получить вознаграждение, тогда ваша модель... co pick places. Так что у вас есть новая инфраструктура, которая поддерживает это, но также новые А. Сейчас всё, что мы делаем внутри, мы пытаемся строить инфру, которая предвосхищает то, что у нас будет через шесть месяцев, что является этими [00:42:00] чрезвычайно длинными сценариями. Думаю, когда мы начинали Mistral, часть меня и мы хотели — очень приятный underlying элемент, где люди могут заниматься исследованиями, как, с большим количеством ресурсов.

Так что было приятно. Думаю, многое изменилось, когда ChatGPT вышел. Думаю, после этого опять то же самое. Но было приятно. И мы тоже хотим работать в этой части скрипта раньше

swyx: подходя к концу.

Найм и след команды

swyx: Мы просто, очевидно, я думаю, вы делаете невероятную работу.

У вас очень впечатляющее видение для open source и для голоса. На что вы нанимаете? Что вы ищете в тех, кто пытается присоединиться к компании?

Guillaume: Да, мы нанимаем много людей в нашу команду. Нанимаем во всех наших офисах. Наш HQ во Франции в Париже.

У нас небольшая команда в Лондоне. У нас команда в Пало-Альто тоже. Открыли офисы в SAU, в Польше. Один в Цюрихе. Также есть некоторое присутствие в Нью-Йорке тоже, и один в Сан-Франциско. Так что мы в любом случае также нанимаем удалённо. Мы строим команду, пытаясь нанимать очень сильных людей.

Думаю, мы хотим остаться — команда не. Достаточно небольшая команда [00:43:00]. Но думаю, мы хотим сохранить её такой, потому что нам это кажется довольно эффективным. Маленькая команда — они agile, так что да.

swyx: Окей.

AI для науки и партнёрства

swyx: Сосредоточимся на науке и forward-deployed. Мы на самом деле сильные верующие в науку.

Запустили наш новый science-подкаст, который фокусируется специально на AI для науки. Какие области вы считаете самыми перспективными?

Guillaume: Что нас сейчас очень волнует и что мы уже начали делать — мы, наверное, сможем поделиться больше об этом через пару месяцев — мы исследуем AI для науки.

И есть много областей, где мы думаем, что можно получить чрезвычайно перспективные результаты, если применить AI в этих доменах. Есть много long-inputs. Нужно просто найти эти домены, где AI ещё не был применён, и это обычно сложно делать, потому что люди, работающие в этих доменах, не обязательно знают возможности этих моделей.

Они не знают. Я бы просто соединил их. Да, именно. С исследователем — что на самом деле сложно сделать. Но это соединение мы делаем естественно с нашими клиентами. У нас есть компания, с которой мы работаем очень тесно. Например, IBM Andreessen — один из наших партнёров, и мы делаем исследования с ними по другим, тоннам чрезвычайно интересных проблем.

Колонки в физике, [00:44:00] в материаловедении, в которых они по сути единственные, кто работает. Потому что они делают что-то, что больше никто не делает. Так что да, есть много доменов, где AI может реально революционизировать вещи. Просто нужно подумать об этом, быть знакомым с тем, что можно сделать или применить.

Это что-то, где больше моделирования с нашими партнёрами, с нашими клиентами sort AI for science.

swyx: Да. Окей.

Навыки Forward Deployed

swyx: А для forward deployed — что делает хорошего forward deployed engineer, что им нужно? Где люди терпят неудачу?

Guillaume: Думаю, обычно нужны люди, очень знакомые с технологией и не обязательно с большой исследовательской экспертизой, но которые действительно хорошо используют эти модели — знают как делать fine-tuning, как запустить error pipeline.

И это не просто. Это что-то, что большинство компаний не сможет сделать самостоятельно. Так что здесь нужны люди, которые любят решать проблемы, которые принимают решение сложных, очень конкретных проблем. Это applied science, по сути.

Да, думаю, не слишком отличается, думаю, от того, что нужно в исследованиях, потому что вы пытаетесь найти решения проблем, [00:45:00] которые у клиентов ещё нет. Иногда легко, иногда вы здесь, чтобы делать работу. Нужно создавать синтетические данные.

Находить edge case. Может быть, да. Зависит от проблемы. Но нужно, думаю, также немного терпения, быть креативным. Думаю, очень похожий навык, азиатский,

Pavan: разнообразие работы, которую они делают. Это всегда меня удивляет. Это идёт во весь спектр от вещей, с которыми они сталкиваются в индустриях.

Это просто очень интересно. Думаю.

swyx: Какие-нибудь забавные success anecdotes?

Guillaume: Да, это может быть на самом деле обучение этой маленькой модели на edge, которая делает одну конкретную вещь, может быть, как обучение очень большой модели на специфических языках. Сделать модели действительно хорошими в каких-то use case, например, computer-aided design, эти вещи.

Это сочетание с vision. Да,

Pavan: и обнаружение дефектов для чипов или на заводах — идентификация вещей. Разнообразие может быть в чём угодно, где можно развернуть эти foundation модели. Так что да, работа, чтобы заставить это работать в конкретной обстановке, по сути всё, что нужно, чтобы это добавило ценности в этом workflow.

Vibhu: Да. [00:46:00] И это идёт через весь стек, верно? Даже просто подтянуть веб-сайт.

swyx: Это так широко. По compute это так широко.

Vibhu: Мы даже не затронули — у вас есть coding CLI tool. Одна вещь, которую вы делали, — думаю, первым инструментом были агенты, Mistral agents. У вас был agent builder, можно обслуживать через API и всё такое.

И, полагаю, forward deployed люди.

Guillaume: Да.

Vibhu: Помогают это строить и подобное.

Цикл обратной связи с клиентами

Guillaume: Это также часть того, почему мы — мы делаем много вещей, но думаю, это также часть value proposition, что иногда клиенты. Они всегда очень осторожны со своими данными и им не нравится доверять стольким партнёрам, доверять одному партнёру для кода, давать данные другой третьей стороне для аудио и ещё одной.

Им это не нравится. Здесь им действительно нравится наш подход, что мы можем помочь им с чем угодно, так что им не нужно отправлять данные стольким облакам. Так что да,

swyx: думаю, FD может быть на много порядков больше, чем research scientists, и им не нужен ваш полный опыт, но они всё равно очень ценны для клиентов.

Guillaume: На практике эти две команды [00:47:00] всё ещё довольно переплетены, очень часто. Да. Прежде всего, они используют те же инструменты, тот же data pipeline и всё. Это очень полезно для команды science — получать обратную связь, и solution команды, потому что они могут смотреть, что эти клиенты пытаются делать, это не работает. Это действительно может пойти в следующую версию.

Да. Но это по сути real world eval. Да, это real world eval, и это не то, что — например, если вы просто работаете в лаборатории, это просто отгрузка модели. Но вы не делаете эту работу для клиентов. Вы понятия не имеете, хороша ли ваша модель в этом edge case.

Например, даже в год вы это обнаружили, верно? Так что да, есть огромный разрыв между публичными бенчмарками, которые очень академичны. На

Pavan: редких случаях — они просто очень разнообразны, и в конкретном контексте клиента можно дообучить и сделать так, чтобы сначала оценить, создать solid eval бенчмарк, и затем измерить в контексте их типа аудио.

Например, один use case буквально — есть слово для детей, и они должны просто произнести его. Это очень конкретная вещь. Вы просто говорите одно слово и затем ставите оценку, правильно ли ребёнок сделал. [00:48:00] Это очень разнообразные use cases, и идея, что прикладной scientist engineer пойдёт и сделает это лучше.

И затем из обучения мы включаем это в саму базовую модель. Так что она просто лучше из коробки.

Vibhu: Да. Это хорошая full circle система. Foundation model evals — это все просто прокси того, что вам действительно нужно. У вас никогда не будет такого, не имеет смысла, чтобы был one-word transcription как этот.

Это не то, на что хочется подгонять. Идеально.

Завершение и благодарности

swyx: Всем надо посмотреть всё, что Mistral предлагает, и попробовать TTS-модель — линк будет в show notes. Огромное спасибо, что пришли. Спасибо. Такой растяжкой.

Обсуждение этого эпизода