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

Теперь

Здравствуйте!

Меня зовут Хосе, и сегодня со мной Иэн и Зои.

Все мы знаем о больших языковых моделях.

Мы используем их для всего: поиска рецептов, краткого пересказа видео на YouTube и программирования.

Существуют очень большие LLM, такие как модели Gemini, которые способны на невероятные вещи. Но в этом докладе мы поговорим о малых языковых моделях.

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

Мы будем говорить о малых моделях не как об альтернативе передовым моделям, а как о дополнении к ним.

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

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

Для этого я использовал Gemma 4, поэтому мог просто скачать ее и запустить на своем оборудовании бесплатно, но я запустил ее на коммерческом шлюзе только для справедливого сравнения.

Сколько же будет стоить передовая модель?

Примерно в 20–200 раз больше в зависимости от кеширования токенов и других факторов.

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

Ваш телефон

Теперь очевидный вопрос: в чем разница в качестве и точности?

В этом конкретном наборе данных Gemma 4 может решить 53 % задач.

Это означает две вещи.

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

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

В этом докладе мы хотим помочь вам получить больше от каждого токена.

Зои расскажет, как выбрать малую модель, а Ян – о моделях Gemma, чтобы вы понимали, как они работают и что могут делать.

Затем я быстро покажу, как попробовать Gemma 4 в Android Studio. Наконец, мы покажем, как вписать небольшие модели в ваши ежедневные рабочие процессы, а также реальные тесты производительности Android, которые помогут вам понять, на что они способны.

А теперь передаю слово Зои.

Спасибо, Владлен.

То есть использовать одну модель для всего – это как забивать гвозди микроскопом?

Это эффективно, но немного непропорционально.

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

Чтобы понять, что вам нужно привнести в свои рабочие процессы, вам нужно открыть набор инструментов, посмотреть, что доступно, каковы их характеристики, для чего они хороши.

Чтобы выбрать малую модель, нужно знать, какие они бывают.

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

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

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

Так что мы можем работать нелинейно.

Диффузионная модель работает по тому же принципу, но обрабатывает блок токенов за раз.

Это похоже на набросок, который постепенно обретает четкость.

В этом случае DiffusionGemma работает с фрагментами по 256 токенов за раз.

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

Итак, в нашем наборе инструментов есть модели, которые могут писать, верно?

Неправильно.

По сути, модели встраивания превращают объекты, такие как изображение, текст или любое другое понятие, в вектор.

Таким образом, мы получаем сопоставление, скажем, координат в многомерном пространстве, что позволяет нам концептуально сравнивать две вещи.

Например, если хот-дог – это бутерброд, то они, скорее всего, будут находиться рядом или в одном месте.

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

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

Например, у нас есть функциональные модели, которые преобразуют естественный язык в вызовы API, визуальные модели, которые, как я уверен, вы знаете, на что они способны, или, например, классификаторы, которые могут давать оценки входным данным на основе определенных параметров.

Итак, у нас есть много вариантов, верно?

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

Как же выбрать малую модель?

Начнем с набора открытых малых моделей Gemma, которые можно запускать локально.

Передаю слово Иэну.

Спасибо, Зоя.

Как Хосе упомянул в начале, малая языковая модель может выполнять около 50 % задач без дополнительной настройки.

Но почему вы можете выбрать именно локальную модель?

Итак, есть четыре основных момента.

Первый – это конфиденциальность.

Например, у вас могут быть ключи API, проприетарный код или вещи, которые буквально не могут покинуть ваш ноутбук.

Второй – задержка.

Когда модель загружается в графическую или унифицированную память, вы получаете ответ, как только завершаются вычисления.

Таким образом, нет времени прохождения сигнала до серверов и нет дополнительной задержки.

Следующий пункт – нулевые предельные издержки.

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

Например, если вы запускаете что-то на локальном компьютере, он может выполнять дополнительные повторные попытки в цикле ошибок.

Это бесплатно, и никаких неожиданных расходов на API не будет.

И, наконец, четвертый – офлайн-режим.

Представьте, что вы можете использовать ее в самолете, поезде, автобусе или метро – в любом месте, где модель работает на вашем устройстве.

Звучит здорово, но при принятии таких решений нужно учитывать два основных фактора.

Итак, первое – это память, а второе – скорость.

Если вы посмотрите на эту диаграмму, на две нижние модели, 26B и 31B, то увидите, что для работы в BF16, то есть 16-битном квантовании, им обеим требуется более 50 ГБ видеопамяти.

Проблема в том, что она не поместится на многих устройствах.

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

Теперь это выглядит более разумно.

Мы говорим о 14 ГБ и 17 ГБ, верно?

Теперь она поместится на Mac с объединенной памятью.

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

Этот процесс называется обучением с учетом квантования.

В результате модель обучается с учетом того, что она будет работать с меньшими размерами, и поэтому потери будут меньше.

Таким образом, мы получаем сокращение требований к оперативной памяти на 75%, и теперь она может поместиться на этих устройствах.

Но мы пошли ещё дальше.

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

Таким образом, у нас есть своего рода смешанный пакет квантования.

Таким образом, мы переходим от Gemma E2B размером 11,4 ГБ к модели размером 1,1 ГБ.

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

Следующий – скорость.

Итак, когда вы используете авторегрессионную модель, как упомянула Зои, вы предсказываете следующий набор токенов.

Например, в задаче по программированию многие из этих токенов на самом деле вполне предсказуемы, например, это конец сигнатуры метода или открывающая или закрывающая фигурная скобка.

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

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

Это возможно благодаря тому, что в архитектуре Gemma 4 используется общий кеш KV.

Так что думайте об этом как о своего рода кратковременной памяти модели.

Итак, небольшая модель-черновик предскажет три или четыре токена заранее, а более крупная модель затем посмотрит на тот же кеш KV и, по сути, проверит выходные данные.

В результате производительность может вырасти примерно в три раза без потери качества выходных данных модели, поскольку она просто прогнозирует результаты, а затем решает, правильные они или нет.

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

Поэтому он не очень хорошо работает с такими вещами, как творческое письмо, потому что там больше вариативности, но он очень хорошо работает с предсказуемыми вещами, такими как структуры JSON и кодирование.

Итак, как бы вы на самом деле оценили одну из этих моделей?

Самое очевидное, что вы можете сделать, – это посмотреть на результаты тестов, например LiveCodeBench или MMLU.

Но это даст вам лишь общее представление о возможностях модели.

Вам нужно оценить весь стек, в котором он работает.

Итак, это модель, которую вы используете, веса и подход к квантованию, инференс среды выполнения, поэтому вы можете использовать что-то вроде llama.cpp, Ollama или LiteRT, агентную обвязку, которую вы используете, будь то Pi, OpenCode или Antigravity, а затем окно контекста, которое является своего рода пространством для всех данных, которые вы хотите, чтобы ваша модель могла обрабатывать.

И сочетание всех этих вещей приводит к тому, что это своего рода жизнеспособно.

Приведу пример. Мы тестировали Gemma 4 на Android Bench и запустили версию Ollama с контекстом по умолчанию 32k.

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

Просто увеличив контекст с 32 000 до 256 000, мы смогли сохранить это в памяти, и модель смогла пройти этот конкретный тест.

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

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

Как же провести собственную оценку?

Вот три быстрых совета.

Например, вы можете взять историю Git, то есть набор уже успешных PR, и использовать их в качестве входных данных для модели, чтобы посмотреть, насколько хорошо она с ними справляется.

Затем вам понадобится детерминированный оценщик, который поможет определить, правильны ли выходные данные модели.

У нас есть два отличных примера.

У нас есть компилятор и модульные тесты.

Что бы ни было сгенерировано, вы можете прогнать это через него, и он скажет вам, прошли вы или нет, удалось ли вам выполнить эту конкретную задачу.

И третий – траектории входа.

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

И я хочу, чтобы вы попробовали изменить формулировку вопроса с "Является ли эта модель такой же умной, как эта большая передовая модель?"

"Возможно ли выполнить эту задачу на этом оборудовании с этой конкретной конфигурацией?"

Чтобы это выяснить, мы разработали фреймворк под названием "Мы уже на месте?".

или AWTY.

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

То есть сама модель, используемый вами механизм логического вывода, обвязка и конфигурация оборудования.

и вы поймете, готовы ли вы.

Например, вы можете посмотреть, насколько надежна эта конкретная задача.

Если вы запустите его, скажем, 10 раз подряд, будет ли он каждый раз делать одно и то же?

Возможно, вы смотрите на задержку.

Возможно, вам нужен ответ в реальном времени.

Итак, каковы ваши пороговые значения для скорости выполнения задачи?

А затем вы можете посмотреть на требования к ОЗУ.

То есть важен не только объем ОЗУ, но и то, сколько памяти вы можете выделить, а также какие приложения и инструменты вам нужно запускать на этом оборудовании.

Может ли он занять 50 % или только 10 % ОЗУ?

И вы получаете эту последнюю оценку готовности.

Если он зеленый, значит, конфигурация готова к работе.

Если он оранжевый, желтый или красный, возможно, вам нужно изменить конфигурацию.

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

Поэтому я рекомендую ознакомиться с этим.

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

Зои расскажет о том, как мы проводим некоторые оценки, а сейчас я передаю слово Хосе, который покажет вам, как быстро начать работу с Gemma 4.

Спасибо, Ян.

Так что да, самый быстрый способ попробовать Gemma 4 сегодня – это, вероятно, Android Studio.

Давайте я покажу, как это сделать.

Давайте переключимся на ноутбук.

– Вот так.

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

Мне просто нужно скачать модели на жесткий диск.

Так вы запустите сервер llama.cpp, который будет сразу же правильно настроен.

Но вы также можете использовать собственный сервер llama.cpp, Ollama или LM Studio – все, что захотите.

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

Кроме того, имеет смысл использовать небольшие модели через удаленного поставщика.

Вы можете добавить сюда модель, если она совместима с OpenAI или Anthropic.

Хорошо, давайте посмотрим.

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

Итак, я выбрал Gemma 4 26B и могу спросить: "Что такое ViewModel?"

Окей.

Поэтому очень важно помнить, что при смене модели весь разговор отправляется в новую модель с самого начала.

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

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

Спасибо, Хосе, и спасибо, Иэн, за обзор моделей Gemma и за то, что рассказали, достигли ли мы уже цели.

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

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

Все верно?

Это, знаете, некоторые из вещей, которые, я уверен, все уже делают, даже, вероятно, не осознавая этого.

Но я бы хотел призвать вас, или я бы хотел призвать вас мыслить шире, верно?

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

Все верно?

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

Если мы сможем выйти за эти рамки, что смогут делать малые модели?

В какие рабочие процессы вы могли бы их внедрить, чтобы облегчить себе жизнь и освободить больше времени для того, чем вы, возможно, хотите заниматься больше?

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

Итак, это несколько примеров, верно?

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

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

Для этого и нужны контрольные показатели.

И, как сказал Ян, общая таблица лидеров, особенно для Python, мало что скажет вам о том, будет ли небольшая модель полезна для ваших рабочих процессов Android.

Точно так же, как сверло для гипсокартона мало что может сказать о сверле для бетона.

Но вам следует инвестировать в собственные оценки.

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

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

При оценке контрольных показателей следует учитывать три фактора.

Это немного мета, но, по сути, первое, что нужно сделать, это определить тип задачи, которую выполняет эта модель, верно?

Насколько точно она определена.

Похоже ли это на тип задачи, которую вы ему дадите?

Второй – это масштаб задачи.

Это написание документации, решение PR или что-то, что похоже на вашу работу?

И, наконец, соответствует ли сложность системы сложности, которую вы собираетесь предоставить?

И здесь мы можем увидеть, почему тест Python не будет очень репрезентативным для Android.

Поэтому мы создали Android Bench – бенчмарк, который отражает экосистему Android и работу с ней.

Первая версия содержит 100 задач Android, сопоставимых с запросами на извлечение. Вы можете запустить ее в Harbor, чтобы проверить любую комбинацию агента, модели и навыка.

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

А теперь я передаю слово Хосе, который расскажет о результатах и о том, как оптимизировать работу с небольшими моделями.

Хорошо, спасибо, Зоя.

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

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

Долгосрочные задачи – это задачи, на выполнение которых у человека могут уйти дни или недели.

Например, перенос или масштабный рефакторинг. И, спойлер, вы не сможете сделать это с помощью небольшой модели.

По крайней мере, за один раз.

Об этом мы поговорим позже.

Хорошо, небольшие задачи.

Это работа, которая требует чтения и записи, возможно, одного или двух файлов, и не требует больших знаний.

Например, небольшие модели довольно хороши в Compose, по крайней мере, в основах Compose.

Например, между элементами должно быть 8 dp, или используйте тему вместо жестко закодированных цветов, или извлеките строки.

Это очень легко для маленькой модели.

Это задание сложнее, но вы справитесь.

@Composable
 fun AnimatedDrawer() {
   val offsetX = remember { Animatable(0f) }
-  Box(modifier = Modifier.offset(x = offsetX.value.dp)) {}
+  Box(modifier = Modifier.graphicsLayer { translationX = offsetX.value }) {}
 }

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

Итак, подсказка фактически говорит нам, какую composable-функцию нужно оптимизировать и что с ней не так: она рекомпонуется в каждом кадре.

Это делает задачу довольно простой даже для небольшой модели, такой как Gemma 4.

В данном случае это заняло три минуты и потребовало изменения одной строки.

Теперь

Итак, мы разобрались, что такое малая модель.

Давайте посмотрим, что такое небольшая задача.

Рассмотрим задачи среднего уровня.

Малые модели должны справляться с большинством из них.

В этом задании в запросе из приложения Pocket Casts отсутствует агент пользователя, а также есть ошибка в логике повторных попыток.

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

Но это прошло.

Это заняло 10 минут.

Оно изменило три файла.

Кстати, через OpenRouter это стоило 6 центов.

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

Это пример Now in Android с довольно подробным отчетом или запросом, но в нем не упоминается имя класса или файл, поэтому агенту нужно приложить больше усилий, чтобы понять архитектуру приложения, уровень данных, механизм синхронизации и в данном случае и т. д. Таким образом, в этом конкретном запуске он потерпел неудачу.

Все было реализовано почти правильно, но предполагалось, что значение начальной синхронизации будет -1, а на самом деле оно равно 0.

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

Вот и всё!

Эту ошибку можно было бы обнаружить, если бы агент просто запустил существующие модульные тесты.

Это показывает, что меньшие модели, как правило, останавливаются немного раньше, чем передовые.

Мы попросили агента устранить проблему, а не проверить ее.

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

Об этом мы тоже поговорим чуть позже.

Итак, давайте поговорим о больших задачах.

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

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

Но есть и такие, когда, глядя на то, что произошло на самом деле, вы понимаете, что модель была на 90 или 90 процентов там.

Давайте выберем один из них.

Я выбрал этот, потому что он слоеный.

Проходит примерно в половине случаев.

Поэтому я считаю, что это на грани того, на что способна небольшая модель.

Или хотя бы модель, выпущенную в апреле.

Она связана с обработкой некорректных URL в библиотеке Coil.

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

Давайте быстро рассмотрим его.

Все запуски проверялись на наличие типичных кодировок URL и ошибок, но только в некоторых, половине из них, были добавлены тесты для плохо закодированных символов, так что тестовый пример там.

Те, которые не прошли, не прошли оценку.

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

Они следуют инструкциям, но не пытаются произвести на вас впечатление, как это делают передовые модели.

Вы знаете, как сейчас можно задать уровень усилий агента?

Просто учитывайте, что при использовании небольшой модели он установлен на слишком низком уровне.

Итак, давайте определим большие задачи как те, которые могут быть выполнены небольшими моделями примерно в 50 % случаев, чего Gemma 4 31B может достичь по сравнению с набором данных Android Bench v1, о котором Зои говорила ранее.

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

Конечно, и это не требует никаких усилий.

Во-первых, если вы используете локальную модель, например Gemma 4, как упоминал Ян, убедитесь, что она настроена правильно.

Например, если вы используете Ollama для работы с Gemma 4, по умолчанию размер окна контекста составляет 32 000 токенов, хотя на самом деле поддерживается в восемь раз больше.

Конечно, если вы используете Gemma 4 через Android Studio, вам не нужно ее настраивать.

По умолчанию он настроен правильно.

В наших тестах это позволило повысить точность результатов с 26 до 53 %.

Затем используйте Android CLI, инструмент Android CLI, особенно для поиска документации.

Это не всегда применимо, поскольку модели довольно хорошо справляются с основами, но всякий раз, когда вы используете новый или нишевый API, наличие документации является ключевым фактором.

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

Добавьте подсказки для проверки.

Мы говорили об этом.

Расскажите модели, как запускать тесты, какие типы тестов доступны, как управлять эмуляторами и т. д. Вы можете сделать это в файле AGENTS.md, чтобы инструкции были доступны всем агентам. Это в любом случае будет полезно.

Она должна быть у вас.

Но будьте осторожны с очень длинными файлами AGENTS.md. Если вы попробуете разных агентов, то увидите, что у некоторых из них огромные системные подсказки и описания инструментов, и они, похоже, снижают производительность небольших моделей.

Мы попробовали запустить эти тесты с OpenCode, и он показал гораздо более низкие результаты, чем pi, вероятно, потому, что он использует более крупные описания инструментов и системные подсказки.

Затем добавьте навыки, но также удалите навыки.

Небольшим моделям может потребоваться подсказка при использовании новых и нишевых API, но лучше не заполнять их контекст общими навыками Compose, например.

А что насчет долгосрочных задач?

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

Примеры долгосрочных задач: перенос всего приложения с XML на Compose, создание сложного приложения с нуля или преобразование кросс-платформенных приложений в нативные приложения для Android.

Если мы посмотрим на результаты Android Bench V2, который фокусируется исключительно на долгосрочных задачах, мы увидим, что передовые модели набирают от 3 до 40 %.

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

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

Давайте посмотрим, как это сделать.

Вернемся к Зое.

Спасибо, Владлен.

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

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

Так что, если у вас упал провайдер, или вы уперлись в лимит запросов к API, или вы в самолете или поезде, как говорил Ян, вы можете настроить резервную модель и сделать так, чтобы, будь то онлайн или локально, вы могли продолжать работу, если что-то случится.

Ещё одна вещь, которую вы можете сделать с помощью оркестрации, – получить более качественные ответы.

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

Вы также можете создать совет, в котором разные типы моделей или разные модели будут выполнять одну и ту же задачу одновременно, а затем вы сможете оценить разные ответы и то, как веса и смещения каждой модели повлияли на результат.

Вы также можете использовать отдельную модель в качестве, скажем, тестов.

Это похоже на экспертную оценку.

И вы могли бы увидеть это через это.

И, конечно, оркестровка помогает повысить экономическую эффективность, например за счет каскада.

По сути, вы можете настроить его вручную, чтобы вы могли установить одну модель для планирования, вы могли установить другую модель для выполнения, другую для тестов.

Это можно сделать разными способами, например в облаке или локально, настроив прокси-сервер LiteLLM.

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

В заключение вернемся к вопросу, который Хосе задал в начале выступления: в чем разница в качестве и точности между небольшими и передовыми моделями?

И ответ, как и во многих других случаях в компьютерных науках, зависит от ситуации.

Однако я хочу подчеркнуть, что вы можете сами создать такую культуру.

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

Итак, первая часть здесь — выбрать правильный инструмент, верно?

Существует несколько типов инструментов.

Узнать их, исследовать их, верно?

а затем выяснить, какие профессии им подходят или даже чем они могли бы заниматься.

Во-вторых, убедитесь, что вы правильно настроили область действия, которую модель получает для выполнения работы.

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

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

И в конце концов, вам нужно поработать над настройкой или созданием собственных оценок.

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

Но самое главное, вы можете продолжать исследовать, продолжать строить, продолжать веселиться, верно?

Вы можете начать уже сегодня, составив список моделей с помощью Android Bench и полученных результатов или начав с Gemma 4 в Android Studio.

Спасибо.