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

Практическое описание гибридного локально-облачного рабочего процесса с использованием Gemma 4 и GPT-5.4, с обоснованием и структурированными результатами.

Делиться

Сегодня при разработке приложений LLM обычно используются два соединения развертывания: либо полный переход в облако, то есть отправка всех данных через облачный API LLM, либо полный локальный переход, то есть запуск всего с помощью открытой модели, размещенной локально. Локальные модели сохраняют этот контекст в тайне, но из-за ограниченных локальных вычислительных ресурсов они могут создавать трудности при выполнении сложных задач. class=»wp-block-pullquote»>

Можно использовать возможности облачных вычислений для анализа данных, сохраняя при этом локальный конфиденциальный контекст?

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

В частности, мы обсудим:

• Как развивать гибридные конструкции. Мы рассмотрим трехосевую карту и проиллюстрируем 5 наиболее типичных типов.
• Для наглядного примера рассмотрим один из вариантов. Мы используем как локальную модель для изучения небольшого языка (Gemma 4 E4B от Google), так и облачную модель для изучения большого языка (GPT-5.4 от OpenAI).

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

1. Когда руководитель использует гибридную локальную и облачную архитектуру LLM?

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

Но конфиденциальность — не основная причина перехода к гибридным технологиям.

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

1. Направление , которая отвечает на вопрос «кто применяется первым?». Оно может быть ориентировано на локальные решения или на облачные.
2. Триггер, следовательно, на вопрос «когда используется облако?». В некоторых сценариях работы облака возникают постоянно. В других случаях облако возникает только при определенных условиях.
3. Цель , которая отвечает за вопрос «зачем разделять рабочий процесс?». Как мы уже упоминали, конфиденциальность является одним из основных мотивов. Но другими факторами могут быть стоимость и задержка, а также безопасность и надежность.

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

Схема 1: Санитарная обработка и решение проблем

Этот шаблон, ориентированный на локальные процессы (ось 1), всегда запускает облачную LLM (ось 2) и учитывает необходимость сохранения конфиденциальности (ось 3).

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

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

Схема 2: Планирование-затем-планирование

Эта модель ориентирована в противоположном направлении. Она ориентирована на облачные технологии (ось 1), облачная модель всегда активируется (ось 2) и при этом обеспечивает конфиденциальность (ось 3).

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

Схема 3: Нарастание сложности.

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

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

Этот подход ориентирован на локальные ресурсы (ось 1), запуск облачной модели является условным (ось 2) и часто мотивированным вознаграждением и задержкой, а не конфиденциальностью (ось 3).

Шаблон 4: Сначала черновик, затем доработка.

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

Этот подход ориентирован на локальные решения (ось 1), может запускать или не запускать облачную модель (ось 2) и часто мотивируется также стоимостью и задержкой.

Шаблон 5: Перекрестная проверка

Ещё один важный принцип, заслуживающий внимания, — это перекрестная проверка.

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

Эта закономерность распространяется на внешние направления (ось 1), облачная модель всегда активна (ось 2), и она в основном определяет прозрачность и надежность (ось 3).

2. Пример практики: Стоит ли запускать посудомоечную машину сейчас или позже?

конкретному примеру. В частности, мы рассматриваем задачу планирования системы работы «умного дома».

2.1 Настройка кейса

В данном случае мы рассматриваем систему умного домашнего помощника, которая хранит частную память домохозяйства. wp-block-quote-is-layout-flow»>

Посудомая машина должна запустить сейчас или позже?

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

Для решения этой проблемы голосовой помощник знает, что сейчас 18:30 , и имеет доступ к следующей информации о домохозяйстве, характеристиках устройств и тарифах:

 Бытовая память: - Мыть посудомоечную машину нужно перед завтраком, потому что детям нужны чистые миски, обычно около 06:30. - Не позволяйте посудомоечной машине работать, когда все уже легли спать, обычно около 22:30; это прямо возле спален, а Майя чутко спит. — Электромобиль — это машина Марка, и его нужно зарядить, прежде чем он уедет в 07:00. - Робот-пылесос часто работает после обеда; сегодня он закончил обход кухни около 16:10. Факты об устройстве: - Посудомоечная машина: время работы около 90 минут, энергия около 1,2 кВтч, доступна уже сейчас. - Зарядное устройство для электромобилей: время работы около 120 минут, потребление энергии около 14 кВтч, доступно уже сейчас. - Робот-пылесос: последний цикл уборки завершился в 16:10; на доке батарея заряжена на 78%. Тариф: - 17:00–20:00: 0,45 доллара США/кВтч - 20:00–00:00: 0,22 доллара США/кВтч - 00:00–06:00: 0,12 доллара США/кВтч - 06:00–17:00: 0,25 доллара США/кВтчкод>

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

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

• Шаг 1: локальный LLM. Прочитайте закрытый контекст, абстрагируйте задачу планирования так, чтобы она не предоставила конфиденциальную информацию.
• Шаг 2: облачная LLM. Проанализируйте анонимную задачу планирования и составьте расписание.
• Шаг 3: локальный LLM. Преобразовать результат в облако языков обратно на язык домохозяйства и представить окончательный ответ пользователю. ли>

Именно такой рабочий процесс мы выстроим далее.

2.2 Настройка моделей Ollama и Gemma 4

В данном переводе мы используем модель Gemma 4 E4B в качестве локальной модели LLM.

Gemma 4 — это семейство моделей, выпущенное Google в прошлом году. Оно предназначено для рассуждений, программирования, многомодального понимания и агентных процессов. Модель доступна в нескольких размерах. Для нас важны варианты, удобные для периферийных устройств, а именно модель E4B.

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

На компьютерах под управлением Windows это можно сделать с помощью официального установщика:

 https://ollama.com/download

После установки вы можете запустить Ollama из меню «Пуск» Windows.

На компьютер с Linux установить Ollama можно следующим образом:

 "curl -fsSL https://ollama.com/install.sh | sh"

После запуска Ollama мы можем приступить к включению нашей локальной языковой модели. Это можно сделать с помощью командной строки:

 ollama pull gemma4:e4b 

Для справки мой ноутбук оснащен процессором Intel i7-13800H, 32 ГБ оперативной памяти и видеокартой NVIDIA RTX 2000 Ada. Ноутбук примерно с 8 ГБ видеопамяти. Если E4B кажется слишком слабым, вы можете выбрать gemma4:e2b .

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

 ollama run gemma4:e4b "what's" столица Франции?"

вам Если удалось получить обратно «Париж», поздравляем, Джемма 4 теперь доступна на вашем локальном компьютере через Ollama.

2.3 Шаг 1: Локальная дезинфекция

Этот шаг полностью демонстрирует эффективность локально.

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

Начнём с составления инструкции к системе:

 # Примечание. Этот запрос был повторен с помощью AI LOCAL_SANITIZER_INSTRUCTIONS = """ Вы являетесь локальным помощником по умному дому, работающим внутри дома. Система имеет доступ к памяти частного домохозяйства, фактам об устройствах и информации о тарифах. Пользователь задал вопрос планирования об одной домашней нагрузке. Ваша роль - подготовить задачу планирования для облачной модели рассуждения, не раскрывая личные детали домохозяйства. Облачная модель будет учитывать время, использование энергии, сроки и Не требуется знать имена устройств, имена людей, сведения о комнатах, семейные процедуры или причину существования ограничения. Используйте идентификаторы нагрузки, такие как load_A, load_B и load_C, вместо реальных имен устройств или нагрузок. Включите нагрузки, которые важны для ответа на вопрос планирования пользователя. записанное в scheduling_problem, покидает дом. Сохраняйте частное сопоставление анонимных идентификаторов нагрузки с именами домашних устройств в local_mapping. Поле local_mapping остается внутри дома и является единственным местом, где могут появляться имена частных устройств. Не отвечайте на вопрос пользователя и не решайте расписание самостоятельно. Ваша задача — преобразовать контекст частного домохозяйства в анонимную задачу планирования, которую можно использовать в облаке. точный текст, который будет отправлен в облачную модель. - В scheduling_problem используйте только анонимные идентификаторы нагрузки, а не имена устройств, имена людей, сведения о комнатах или объяснения домашних хозяйств. Не связывайте идентификаторы нагрузки с частными именами; пишите «load_A:», а не такие метки, как «load_A (робот-пылесос):». и окна тарифов - Поместите частное сопоставление имени загрузки только в local_mapping.strip()

Здесь мы просим локальную модель выбора три задачи:

Определите, какие бытовые приборы действительно имеют отношение к вопросу пользователя;
1. Удалите конфиденциальную информацию, такую как имена, данные о номере и т. д. д.;
2. Сохраните достаточное количество данных о планировании, чтобы облачная модель могла правильно рассуждать.

Далее мы определяем состав подсказок для составления контекста, который будет определять вопрос пользователя, конкретный вопрос домохозяйства и определительный контракт результат:

 def build_local_sanitizer_prompt(private_context: dict[str, Any], user_question: str, ) ->str: return f""" Вопрос пользователя: {user_question} Частный домашний контекст: {format_private_context(private_context)} Задача: Подготовьте анонимную задачу планирования, чтобы облачная модель рассуждения могла анализировать и планировать расписание. Используйте анонимные идентификаторы нагрузки в задаче планирования и сохраняйте локальное сопоставление в local_mapping. Верните свой ответ в формате JSON с точно такими полями: {{ "target_load_id": "anonymous ID нагрузка, указанная в вопросе пользователя", "scheduling_problem": "точная анонимная задача планирования, которая будет отправлена в облако", "local_mapping": {{ "load_A": "robot пылесос", "load_B": "" }} }} Пример local_mapping только иллюстрирует направление сопоставления. Выберите фактические анонимные идентификаторы нагрузки на основе соответствующие загрузки, которые вы включаете. Ключи должны быть идентификаторами анонимной загрузки, а значения должны быть исходными именами домашних устройств. Возвращать только JSON, без ограничения уценки. class="wp-block-prismatic-blocks"> # pip install ollama import ollama import json Prompt = build_local_sanitizer_prompt( Private_context=private_context, user_question=USER_QUESTION, ) response = ollama.chat( model="gemma4:e4b", messages=[ {"role": "system", "content": LOCAL_SANITIZER_INSTRUCTIONS}, {"role": "user", "content": Prompt}, ], think="high", options={"temperature": 0, "num_ctx": 32768}, ) content = response["message"]["content"] local_sanitizer_output = json.loads(content)

представляет собой упомянутую пару моменты:

• Нам необходимо установить клиент Ollama для Python.
• Мы формируем запрос, исходя из запроса пользователя и контекста частной жизни домохозяйства.
• Мы используем режим мышления модели, задающий значение параметра <код>thinkкод> . Поскольку локальную модель необходимо исследовать в сложных локальных единицах, выделение локальной модели большего объема вычислительных ресурсов здесь имеет смысл.

Вы можете заметить, что я прошу Джемму вернуть JSON непосредственно в командной строке. Более формальный подход заключался в использовании <сильных>структурированных результатовсильных> . Ollama поддерживает это с помощью аргумента format :

 response = ollama.chat( model=LOCAL_MODEL, messages=messages, format=PydanticSchema.model_json_schema(), ) 

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

Это, по-видимому, известная проблема, называемая налогом по ограничениям[1]: для небольших моделей жесткие ограничения структурированного результата могут улучшить схему достоверности, но при этом навредить правильности задачи. В производственной системе я бы, вероятно, добавил логику проверок и повторных процессов на этом этапе. Задача планирования в облачной системе LLM, чтобы использовать ее мощные аналитические возможности, не раскрывая при этом никакой конфиденциальной информации.

Начнем с настройки системной инструкции для запуска LLM в облаке:

 # Примечание. Этот запрос был повторен с AI CLOUD_REASONER_INSTRUCTIONS = """ Вы являетесь специалистом по планированию. Вы получаете анонимную задачу планирования с идентификаторами нагрузки, текущим временем, продолжительностью нагрузки, использованием энергии, доступностью, сроками, ограничениями последнего завершения и окнами тарифов на электроэнергию. Ваша задача - решить, должна ли целевая нагрузка начаться сейчас или позже, а затем предложить осуществимый график для соответствующих нагрузок. Используйте только информацию в планировании Проблема. Не придумывайте имена устройств, сведения о домохозяйствах или отсутствующие ограничения. При сравнении возможных графиков учитывайте сроки, ограничения по последнему завершению, время работы, энергопотребление и тарифы. Возвращайте ответ через структурированную схему вывода. Используйте структурированный вывод напрямую. Вот схема вывода:
 от ввода import Literal из pydantic import BaseModel, Field class ScheduledLoad(BaseModel): str = Field( ...,description="Идентификатор анонимной загрузки из проблемы планирования, например load_A.", ) start: str = Field( ...,description="Запланированное время начала в 24-часовом формате ЧЧ:ММ.", ) end: str = Field( ...,description="Запланированное время окончания в 24-часовом формате Формат ЧЧ:ММ.", ) причина: str = Field( ..., описание="Краткая причина выбора этого временного окна.", ) class CloudScheduleReasoning(BaseModel): рекомендация: Literal["run_now", "run_later"] = Field( ..., описание="Должна ли целевая загрузка начаться сейчас или ее отложить.", ) предложенное_schedule: list[ScheduledLoad] = Field( ...,description="Возможное расписание с использованием только анонимной загрузки IDs из командной строки.", ) рассуждение: str = Field( ...,description="Краткое рассуждение, основанное только на фактах анонимного планирования.", )
 Студенту, обучающемуся по программе LLM в области облачных технологий, будет поручено заполнить этот шаблон. Затем мы составим запрос для облачной модели:
 def build_cloud_reasoning_prompt(local_sanitizer_output: dict[str, Any]) ->str: return f""" Анонимная проблема планирования: {local_sanitizer_output['scheduling_problem']} Целевая нагрузка: {local_sanitizer_output['target_load_id']} Задача: Решите, должна ли целевая загрузка начаться сейчас или позже, затем предложите возможный график для соответствующих анонимных загрузок. "".strip()
 Обратите внимание, что в облачную систему LLM мы отправляем только анонимную задачу планирования. Никакого объединения памяти Наконец домохозяйства или нагрузки.
, мы обращаемся к Azure OpenAI:
 from openai import AzureOpenAI # Настройка облачного клиента LLM cloud_client = AzureOpenAI( api_key=os.environ["OPENAI_API_KEY"], azure_endpoint=os.environ["OPENAI_API_BASE"], api_version=os.environ["OPENAI_API_VERSION"], ) # Подготовьте приглашение cloud_prompt = build_cloud_reasoning_prompt(local_sanitizer_output) ответ = cloud_client.responses.parse( model="gpt-5.4", Instructions=CLOUD_REASONER_INSTRUCTIONS, input=cloud_prompt, Reasoning={"effort": "medium"}, text_format=CloudScheduleReasoning, ) cloud_reasoning = response.output_parsed.model_dump()
 На данном этапе облачная модель выполнила планирование, но результат по-прежнему выражается в анонимных идентификаторах нагрузки. Поэтому нам необходим заключительный этап для преобразования.
 2.5 Шаг 3: Локальное заземление
 На этом заключительном этапе снова выполняется сравнение локально.
Как обычно, начнем с настройки системной инструкции для шага 3 LLM. Ее цель — результат облачной обработки данных обратно на язык, результат в домашних условиях и выдача рекомендации:
 # Примечание. Этот запрос был повторен с помощью AI LOCAL_FINALIZER_INSTRUCTIONS = """ Вы — локальный помощник по умному дому, работающий внутри дома. Пользователь спросил, запускать ли домашнюю нагрузку сейчас или позже. Облачная модель уже рассмотрела проблему анонимного планирования и вернула предложенное расписание с использованием идентификаторов нагрузки. Вы можете увидеть исходный домашний контекст и локальное сопоставление анонимных идентификаторов нагрузки с именами домашних устройств. Ваша роль — написать ответ, который будет читать пользователь. ответ должен отвечать на исходный вопрос «сейчас или позже» на обычном домашнем языке, используя облачное расписание в качестве плана планирования. Используйте local_mapping для преобразования идентификаторов нагрузки обратно в имена домашних устройств. Используйте только контекст частного дома, чтобы сделать ответ понятным и актуальным. Не повторяйте оптимизацию планирования с нуля. Не подразумевайте, что какое-либо устройство уже было запущено или запланировано автоматически. Правила: - Сначала ответьте на вопрос «сейчас или позже». Используйте имена домашних устройств, а не анонимные идентификаторы загрузки. - Сохраняйте важные рекомендации по времени из расписания облака. - Упоминайте другие запланированные загрузки только тогда, когда они помогают объяснить рекомендацию. - Если результат облака противоречит контексту частного дома, отдайте предпочтение локальному контексту и скажите об этом кратко. - Ответ должен быть кратким и сосредоточенным на решении пользователя. class="wp-block-paragraph">Затем мы формируем соответствующий запрос. Здесь локальная модель вопрос получает несколько элементов:
 Исходный пользователь;
 Контекст частного домохозяйства;
 Выход локального дезинфицирующего средства;
 Результат логического распределения в облаке.
 Функция-конструктор:
 def build_local_finalizer_prompt(private_context: dict[str, Any], user_question: str, local_sanitizer_output: dict[str, Any], cloud_reasoning: dict[str, Any], ) ->str: return f""" Вопрос пользователя: {user_question} Частный домашний контекст: {format_private_context(private_context)} Локальный вывод дезинфицирующего средства: {json.dumps(local_sanitizer_output, indent=2)} Облачное обоснование: {json.dumps(cloud_reasoning, indent=2)} Задача: Написать окончательную рекомендацию для пользователя. Ответить на актуальный вопрос пользователя сначала используйте предложенное выше расписание облака и не создавайте другое расписание, только если оно помогает объяснить рекомендацию. Ответ должен быть кратким и сосредоточенным на решении. class="wp-block-prismatic-blocks"> подсказка = build_local_finalizer_prompt( Private_context=private_context, user_question=USER_QUESTION, local_sanitizer_output=local_sanitizer_output, cloud_reasoning=cloud_reasoning, ) ответ = ollama.chat( model=LOCAL_MODEL, messages=[ {"role": "system", "content": LOCAL_FINALIZER_INSTRUCTIONS}, {"role": "user", "content": Prompt}, ], think="medium", options={"temperature": 0, "num_ctx": 32768}, ) Final_answer = ответ["message"]["content"]
 Это полная реализация нашего трёхэтапного рабочего процесса.
 2.6 Запуск рабочего процесса
 Теперь давайте запустим рабочий процесс и проверим результаты.
 На первом этапе мы использовали локальную модель Gemma для преобразования контекста домохозяйства в анонимную задачу планирования. Вот полученный результат:
 { "target_load_id": "load_A", "scheduling_problem": "Текущее время: 18:30nНагрузки:n load_A:n Энергопотребление: 1,2 кВтчn Расчетная продолжительность: 90 минутn Самый ранний старт: 18:30n Жесткий срок (должен завершиться до): 06:30n Ограничение плавного останова (невозможно запустить после): 22:30n load_B:n Потребление энергии: 14 кВтчn Расчетная продолжительность: 120 минутn Самое раннее начало: 18:30n Жесткий срок (должно завершиться до): 07:00nТарифный график:n 17:00-20:00: 0,45 доллара США/кВтчn 20:00-00:00: 0,22 доллара США/кВтчn 00:00–06:00: 0,12 доллара США/кВтчn 06:00–17:00: 0,25 доллара США/кВтч", "local_mapping": { "load_A": "посудомоечная машина", "load_B": "Зарядное устройство для электромобилей" } }
 Мы заметили, что локальная модель правильно отфильтровала контекст. Робот-пылесос упоминался в исходных данных о домохозяйстве, но локальная модель правильно определила, что он не имеет отношения к текущему вопросу планирования, поэтому он не включен в анализ.
 Что еще более важно, мы видим, что scheduling_problem содержит только анонимные идентификаторы нагрузки, облачная LLM получает только абстрактные данные планирования, такие как продолжительность, энергопотребление, периодичность и т. д. д.
 На шаге 2 облачная LLM-система получает анонимное расписание:
 { "recommendation": "run_later", "propose_schedule": [ { "load_id": "load_A", "start": "20:00", "end": "21:30" }, { "load_id": "load_B", "start": "00:00", "end": "02:00" } ] }
 Наконец, Джемма преобразует результат в удобный для пользователя язык:
 Вам придется запустить посудомоечную машину позже. Чтобы сэкономить деньги, подождите сегодня до 20:00. Начав тогда, вы сможете завершить работу к 21:30, переместив потребление энергии из самого дорогого временного окна в более дешевое. Общий план также предусматривает использование зарядного устройства для электромобилей на полночь (12:00–2:00), чтобы воспользоваться самыми низкими тарифами на электроэнергию. задача.
 3. Заключительные мысли
Приведенный выше пример «умного дома» оказывается лишь одной из возможностей в пространственном пространстве проектирования гибридных локально-облачных приложений LLM. Во многих приложениях они могут воспроизводить разные ролики.
 Поэтому я считаю, что следует использовать следующие три вопроса:

 Кто должен действовать первым: локальная модель или облачная модель?
 Когда следует перейти облачную модель?
 Что же на самом деле нам дает этот раскол?

 Последний вопрос особенно важен. Обычно первое, о чем думают люди, — это конфиденциальность, но могут быть и другие факторы, такие как стоимость/задержка, надежность и управляемость. Не стоит их отключать из виду.
 На мой взгляд, в этом и заключается суть преимуществ гибридных локально-облачных приложений LLM: не компромисс между локальными и облачными пространствами, а более гибкий способ проектирования самого приложения.
 Ссылка
 [1] Рэй (2026), Налог на ограничения: измерение компромиссов между достоверностью и корректностью в структурированных выходных данных для небольших языковых моделей. https://arxiv.org/abs/2605.26128

 Шуай Го Посмотреть все в Шуай Го

Источник: towardsdatascience.com
Похожие записи
SpaceX: объяснение 8 самых важных вещей после IPO
Как максимально эффективно использовать команду Codex Exec
Как далеко можно зайти в классическое НЛП? От «мешка слов» до наращивания идентификации возможностей жуткого автора.