Этот сайт использует файлы cookies. Продолжая просмотр страниц сайта, вы соглашаетесь с использованием файлов cookies. Если вам нужна дополнительная информация, пожалуйста, посетите страницу Политика файлов Cookie

Прямой эфир

Русский

English

Войти / Регистрация

Cryptocurrencies: 8076 / Markets: 112404

Market Cap: $ 2 636 094 655 117 / 24h Vol: $ 109 212 638 780 / BTC Dominance: 59.815101328861%

Н Новости

Провожу тест‑драйв GigaChat Audio в рабочих условиях

Привет, Хабр! Сбер недавно выкатил новую модель, GigaChat Audio. Сейчас я надиктовываю модели этот текст голосом — финальный штрих в истории о том, как я проводил её тест‑драйв.

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

Меня зовут Данила @pushnoydan, я мидл‑разработчик и занимаюсь бэкендом микросервисов. А параллельно — большой любитель ИИ‑моделей: в свободное время копаюсь в них, чтобы лучше понимать возможности свежих релизов, стараюсь применять на работе, чтобы упростить рутинные задачи.

GigaChat Audio — audio‑native LLM. В течение дня я поручал ей разбирать голосовые коммуникации от коллег, составлять саммари по аудиозаписям и выводить ключевой контекст из записей различных встреч. Давайте посмотрим, как модель показала на реальных задачах.

Как развернуть GigaChat Audio у себя

Перво‑наперво нужно определить, потянет ли компьютер локальный деплой модели. Я использовал собственное железо с такими характеристиками:

Видеокарта: RTX 4090 24GB
Процессор: AMD Ryzen 9 9950X OEM, 16 ядер
Материнка: GIGABYTE X870E AORUS PRO
RAM: 128 GB DDR5
SSD: 2Tb

Постфактум спросил у другой модели, насколько это подходящий уровень железа, она оценила его как «достаточный для базового деплоя GigaChat Audio, с возможными проблемами на загружающих железо задачах». Сразу отмечу, что мою машину модель нагрузила почти на 100%, не связанные с ней задачи я решал параллельно на ноутбуке.

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

Для локальной развёртки на Windows я использовал Docker Desktop, также необходима WSL2: командная строка, wsl ‑install. Все дальнейшие команды выполняются в терминале WSL, так что без этой подсистемы ничего задеплоить не получится. Кроме того, нужно иметь на компьютере свежие драйвера NVIDIA.

Docker Desktop по умолчанию загружает и временные, и постоянные файлы на системный диск. Если места на C: маловато, нужно загружать временные файлы на другой диск, сделав линк между C: и новой папкой назначения. Для этого закрыть Docker Desktop, вручную перетащить папку AppData\Local\Docker на новое место, а потом в командной строке вбить:

mklink /J "C:\Users\<юзернейм>\AppData\Local\Docker" "<диск назначения>:\<новый путь>\<к папке>"

Папку, в которой хранятся готовые образы и модели, назначаются в настройках Docker Desktop: настройки в шестерёнке на верхней панели, Disk Image Location указывается в разделе Resources. Чтобы убедиться, что видеокарта готова к работе с моделью, можно забить в командную строку:

bash
nvidia-smi

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

Деплой через Docker делаем посредством vLLM. С учётом этого и создаётся следующий контейнер:

dockerfile
FROM vllm/vllm-openai:<текущая версия vLLM>

RUN apt-get update && apt-get install -y \
    libsndfile1 \
    ffmpeg \
    && rm -rf /var/lib/apt/lists/*

RUN pip install --no-cache-dir \
    soundfile \
    librosa \
    scipy

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

bash
cd ~/gigachat-deployment
docker build -f Dockerfile.vllm-audio -t vllm-audio:<текущая версия>

И сразу его проверяем:

bash
docker images | grep vllm-audio

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

bash
cat > ~/.gigachat.env << EOF
HF_TOKEN=ваш_сформированный_токен

MODEL_PATH=ai-sage/GigaChat3.1-Audio-10B-A1.8B
MAX_MODEL_LEN=24576
GPU_MEMORY_UTILIZATION=0.95

API_PORT=8000
API_HOST=0.0.0.0

EOF

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

bash
docker run \
  --gpus all \
  --ipc=host \
  --shm-size 32gb \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  --env-file "~/.gigachat.env" \ 
  --name gigachat-inference \
  vllm-audio:<текущая версия> \
  python3 -m vllm.entrypoints.openai.api_server \
    --model ai-sage/GigaChat3.1-Audio-10B-A1.8B \
    --trust-remote-code \
    --max-model-len 24576 \
    --gpu-memory-utilization 0.95 \
    --host 0.0.0.0 \
    --port 8000

Проверяем, как здоровье контейнера:

bash
docker ps
docker logs -f gigachat-inference

Если всё в порядке — вы увидите сообщение, что модель запущена на http://0.0.0.0:8000. Следующий шаг — тест API‑эндпоинта.

bash
#Ждём сообщение «Uvicorn running on http://0.0.0.0:8000»
curl http://localhost:8000/v1/models

Ответ должен быть такой:

 {
   "object": "list",
   "data": [
     {
       "id": "ai-sage/GigaChat3.1-Audio-10B-A1.8B",
       "object": "model",
       "owned_by": "ai-sage"
     }
   ]
 }

И, наконец, можно послать тестовый запрос:

bash
curl -o образец.mp3 https://образец.com/аудио.mp3
curl -X POST http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ai-sage/GigaChat3.1-Audio-10B-A1.8B",
    "messages": [
      {
        "role": "user",
        "content": [
          {"type": "text", "text": "Сделай транскрипцию аудио"},
          {"type": "audio_url", "audio_url": {"url": "data:audio/mp3;base64,..."}}
        ]
      }
    ]
  }'

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

С деплоем разобрались, переходим к моему опыту с моделью и реальным задачам.

Задача первая: подготовить материалы к конференции

Через пару недель выступаю перед публикой на внутреннем митапе компании. Не первый раз… а второй. Всё равно волнительно. В общем, вовсю готовлю доклад и накидываю материалы для презентации: моя тема — как получать максимальную пользу от микросервисов, не компрометируя при этом общую безопасность архитектуры. С утра написал деврел, который меня курирует, попросил поделиться успехами.

Доклад ещё не готов целиком, примерно половину я набросал в черновом варианте, а вторая половина пока существует в виде тезисов. Этот существующий черновик я зачитал GigaChat Audio.

Мой промпт для GigaChat Audio: транскрибируй аудио, которое я тебе зачитал. Составь краткий анализ части аудио до раздела про безопасность в микроядерной архитектуре: насколько рассказ эмоционально яркий, в каких местах я говорю недостаточно интересно.

В течение дня я внимательно читал все текстовые артефакты, которые получал от модели. Поскольку GigaChat Audio заточена на работу со звуком, у неё падают некоторые бенчмарки качества текста (MMLU‑Pro −9.18, BBH −7.26).

MMLU‑Pro фокусируется на способности модели рассуждать в различных сложных областях, всего в бенчмарк включено 57 дисциплин, таких как право, медицина, психология и другие. На нём модель показывает способность учитывать нюансы: бенчмарк состоит из вопросов с 10 вариантами ответа, девять из которых неверны, но очень похожи на правду.

BBH (Big‑Bench Hard) проверяет способность к сложным рассуждениям. В этом бенчмарке собраны наиболее сложные задачи семейства Big‑Bench — те, в решении которых модели заметно хуже людей. Модели нужно выполнять рассуждения, состоящие из множества шагов, делать выводы, опираясь на контекст, и так далее.

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

«HTTP‑запросы, очереди сообщений и события — это наши с вами микросервисные хлеб и масло. Все понимаем, что они в нашем контексте делают? Если нет, поднимайте руку. Отлично, рук нет, тогда не буду тут останавливаться. Но, конечно, архитектура на этих хлебе с маслом не заканчивается. И я сейчас буду разбирать, как с помощью этого нехитрого инструментария реализовать куда более сложные процессы — например, распределённые транзакции, саги, асинхронные процессы и оркестрацию сервисов, причём делать это так, чтобы безопасность не пострадала».

А вот ревью моего выступления было не слишком позитивным:

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

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

Начиная с фразы «Теперь расскажу, как в эту историю вписывается REST…» в твоей речи нет ни одной паузы. Похоже, что тебе хочется не поделиться знаниями со слушателями, а как можно скорее рассказать оставшуюся часть доклада. Речь ближе по звучанию к перечисленным дальше ещё не написанным тезисам, чем к первой части твоего рассказа«.»

В общем, над подачей ещё работать и работать. Обидно, но транскрибацию и комментарии от GigaChat Audio закинул деврелу. Надеюсь, он поможет в этом плане подкачаться.

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

Кто любит учиться? Все любят, без учёбы никак. Вот я регулярно проверяю, какие есть интересные статьи и видео про мои любимые микроядра, в том числе на английском. Раньше мог себе позволить слушать их на обычной скорости, потом времени стало меньше, переключился на двойную. Сейчас и это уже слишком отвлекает от насущных задач, но качать навыки с помощью видео всё равно хочется.

Я разбираюсь в микросервисах, но очень хочу больше знать и о микроядрах. Поэтому решил попробовать GigaChat Audio в качестве транскрибатора и составителя краткого тезисного плана по видео. Скачал нужное видео про кодинг bare‑metal ядра гипервизора, перевёл в.mp3 и скормил модели.

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

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

Возвращаясь к истории деплоя. Изначально у меня параметры модели выглядели так:

MODEL_PATH=ai-sage/GigaChat3.1-Audio-10B-A1.8B
MAX_MODEL_LEN=32768
GPU_MEMORY_UTILIZATION=0.85

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

MODEL_PATH=ai-sage/GigaChat3.1-Audio-10B-A1.8B
MAX_MODEL_LEN=24576
GPU_MEMORY_UTILIZATION=0.95

Снизил MAX_MODEL_LEN, чтобы уменьшить размер KV‑cache. Заодно разрешил vLLM использовать почти всю видеопамять (0.95 вместо 0.85) — иначе при длинном аудио не хватало слотов в кэше. Соответственно, аудио я порезал на четыре примерно 15-минутных кусочка так, чтобы начало каждого следующего отрезка дублировало последние 10 секунд предыдущего, и скормил их модели уже поочерёдно. В моём случае 15-минутные фрагменты укладывались в лимит токенов модели, но точное соотношение «минуты аудио → токены» зависит от битрейта и токенайзера конкретной модели. Со второй попытки всё получилось!

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

Транскрибация:

“28:10”

It has a state and yeah it has a runner runner which is a.

28:23

Which is a.

28:24

Which is an empty function.

28:26

So.

28:27

And here's the really nice thing about the self port kernel.

28:35

I believe I saw somewhere the line of code.

28:39

So we can actually run a VM inside a.

28:45

Inside a for loop“.”

Тезисы:

«Автор начинает с подготовки окружения и загрузки нужного софта. Он упоминает Linux, Debian, initial RAM disk и secure boot: ‘Let’s load the software’ и „Linux, let’s take Debian“.»

Сразу выясняется, что часть среды ещё не установлена или настроена неправильно. Это видно по фразе: «We gotta install some, some things first».

К счастью, мотать видео туда‑сюда в поисках реального старта не надо, найти более деловые фрагменты в тексте куда проще:

«Автор отмечает практическую архитектуру VM в seL4: с self‑port kernel VM можно запускать почти как обычный цикл, а VM enter/exit обрабатывает ядро, давая юзеру возможность совершать некоторые действия из гостевого пространства и юзер‑спейса. Это ключевой технический момент раздела.»

Автор читает документацию про minimal application, guest Linux VM, cross‑VM connectors и демонстрации вроде string reverse и Ethernet passthrough, показывая, что платформа умеет больше, чем простой запуск Linux“.”

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

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

Замечу, что я бросил GigaChat Audio заниматься сложным видео про тонкости кодинга, а это как раз домен MMLU Pro, поэтому не удивлён, что подобные мелочи просочились в текст.

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

Задача третья: сделать тезисное саммари важной встречи

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

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

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

Отрывок текста:

«Приводится пример недавней проблемы с монолитным BFF: в связи с его использованием снизилась координация команд, что привело к каскаду задержек релизов на фронтенде, накоплению ошибок и откату к задачам прошедшего спринта в одной из команд. В качестве решения предлагается модульный BFF с общим хостом в роли платформенного слоя».

JWT	“Нормализованный токен”, «BFF обменивает сессию через JWT»
NATS	«Через него идёт асинхронная доставка сообщений между BFF‑хостом и backend‑плагинами»
RPC	«От RPC вызываем серверные методы через объект с method и params»
Cookies	«Надеюсь, все в курсе, что такое cookies»

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

Такая последовательность меня устроила, потому что работу с техничным русским аудио я хотел проверить подробнее: GigaChat Audio натренирована на TimeGround-1M, а это целиком английский датасет с английскими же тайминг‑бенчмарками. Короче, на английском может быть гораздо лучший результат, чем на русском.

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

«Представитель одной из бэкенд‑команд предлагает как вариант внедрения BFF расширить слоем агрегации используемый Istio Gateway. »

Участники обсуждают, возможно ли расширение на основе используемого Istio в контексте компании <уход в технические детали>«.»

Istio — это опенсорс, для замены которого у нас есть своё решение в рамках Platform V. Очевидно, никакое расширение Istio на встрече обсуждать не могли, так что я пошёл слушать, что же там сказали на самом деле. И в процессе послушал всё саммари своими ушами. Оригинальный диалог в записи действительно Istio упоминал, но в контексте: «Да, там такой подход возможен, а возможен ли он у нас в контексте наших отличий от Istio?» Поскольку по имени собственно наше решение нигде не упоминалось, модель эту тонкость не подхватила и решила, что речь о том, есть ли у нас внутри компании возможность так поменять решение.

В принципе в данном конкретном случае не самая страшная ошибка — но это потому, что у меня у самого нужный контекст в голове, и я сразу считал косяк. Но вывод на основе этой и прошлой задачи очевиден: микс из сбивчивой речи и технических деталей способен подставить GigaChat Audio смысловую подножку.

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

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

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

Задача четвёртая: провести код‑ревью для коллеги

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

Обычно я по несколько раз переписываю свои комменты в личных заметках, прежде чем их прикреплять. А в этот — надиктовал их GigaChat Audio, чтобы он захватил мои живые эмоции в моменте.

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

Показываю конкретный пример. Младший допустил серьёзную для микросервисной архитектуры ошибку: не определил стабильный API‑контракт между сервисами и жёстко завязался на текущую структуру данных соседнего сервиса. Сейчас всё работает, но достаточно изменить формат ответа или добавить новую версию API — и интеграция начнёт ломаться в проде. Первый вариант моего комментария выглядел так:

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

Такой вариант пришёл от GigaChat Audio:

«Сейчас код рабочий, но только до изменений в данных. Контракт между сервисами не явный, из‑за этого не хватает глобальной совместимости интеграции с платформой. Код полагается на то, что текущие версии сервисов не изменятся в будущем. Давай сделаем API‑контракт явным, чтобы это исправить».

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

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

С самого утра я попросил коллег по всем задачам кидать мне голосовые. Они, наверное, неслабо удивились, потому что обычно я исключительно пишу и аудио прошу не отправлять. Но сегодня мне нужны были именно аудиоданные, чтобы тестить GigaChat Audio.

Во‑первых, слушать, какие таски приходят в течение дня.

Мой промпт для GigaChat Audio: транскрибируй присланное аудио.

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

«Привет! В <внутреннее название сервиса>, судя по всему, БДшка дубли даёт, приходи проверить прям срочно»

«В смысле у нас транзакции не локальные»

«Окей, принял, сколько на фикс?»

«Да, работает, маякну, если что»

Наказ идти работать от тимлида:

«Я тебе напоминаю который раз, что рефакторинг <название сервиса> висит и висит. Почему у меня хост чуть ли не телефон клиента знает? Монолитим опять? Короче, заканчивай там со своей моделькой баловаться и давай срочно дело делай».

Приглашение на завтрашнюю встречу от него же:

«Завтра в 12:30 разбираем, как будут взаимодействовать после обновления <сервис 1> и <сервис 2> и как обновятся границы. Приглашение на почте, прими, чтобы в календаре видно было».

И конечно, от очень расстроенного коллеги:

«<...>, меня эти логи, <...>, уже <...>. <...> с ними сколько уже, а они до сих пор внутри <название сервиса> не трассируются, <...>, нормально. Я сдаюсь, в общем, можешь злорадствовать, <...>, только сперва пофикси этот <...>. Тикет закинул».

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

Мой промпт для GigaChat Audio: составь на основе присланных аудио короткий список тезисов. Одно сообщение — один тезис.

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

«Вот список тезисов на основе присланных аудиосообщений:»

1. Продолжить срочный рефакторинг <название сервиса>, чтобы убрать технический долг и снизить риск инцидентов.

2. Поучаствовать в проектировании границ между <сервис 1> и <сервис 2> и их взаимодействия на встрече в 12:30.

3. Настроить подробную трассировку логов в <название сервиса>.

Итоги рабочего дня

Доволен ли я? Да, доволен. Мне хотелось, чтобы GigaChat Audio упростил мне работу со звуком, и он это сделал. В целом модель работает как хорошая контекстовыжималка, которая помогает быстро выхватить самые важные факты из записи. Но и косяки в итоговом тексте с фокусом на сложных технических задачах видны: информацию, полученную по хардкорным темам, лучше перепроверять.

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

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