Как я собрал локальный редакционный конвейер на базе Qwen 3.5 9B, LM Studio и Python

Когда я начинал собирать собственный редакционный конвейер, у меня не было цели сделать «очередной AI-чат». Мне нужен был прикладной инструмент, который можно встроить в реальную работу: дать ссылку на новость, прогнать материал через несколько ролей, получить черновик, редакторскую проверку, финальный текст и Telegram-пост. Причём всё это — локально, без облачных моделей и без передачи данных во внешние сервисы.

В итоге я собрал MVP локальной редакционной системы, где одна модель выполняет несколько редакционных ролей, а сам конвейер работает как управляемый workflow, а не как хаотичный набор «агентов». Ниже — подробный разбор, зачем я это делал, как устроена архитектура и какие выводы я сделал на практике.

Зачем вообще нужен такой конвейер

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

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

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

Именно поэтому я пошёл не в сторону одного универсального промпта, а в сторону редакционного конвейера.

Какая была исходная архитектура

У меня уже был ПК на Windows 11 с видеокартой, и именно на нём я решил держать модель. Для запуска я использовал LM Studio и поставил Qwen 3.5 9B. Остальную логику я вынес на отдельную Ubuntu-машину.

В итоге архитектура получилась такой:

Это решение оказалось сильнее, чем попытка держать всё на одной машине. Windows-компьютер с GPU делает только то, что у него получается лучше всего: обслуживает модель. Ubuntu-машина отвечает за контроль, состояния, маршрутизацию задач и интерфейс.

Почему я не делал «рой агентов»

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

Я сознательно не стал строить свободный рой агентов. Вместо этого я собрал жёсткий линейный конвейер из ролей:

Это важное различие.

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

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

Как устроены роли в конвейере

Planner

Первый этап — это не генерация текста, а постановка задачи.

Planner получает ссылку, заголовок, тип материала и заметки, после чего формирует структурированный бриф:

Это позволяет не бросать Writer напрямую на сырую ссылку. Сначала задача формализуется.

Researcher

Researcher не пишет финальный материал. Его работа — вытащить фактуру.

Он получает бриф и исходный источник, после чего формирует:

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

Writer

Writer получает уже не хаотичный источник, а brief + research pack.

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

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

Critic

Critic — один из самых полезных этапов.

Он получает черновик и проверяет:

Если Writer — это генерация, то Critic — это контроль качества. Без него система производила бы просто больше текста. С ним она начинает производить более осмысленный текст.

Finalizer

После Critic я добавил ещё один важный этап — finalizer.

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

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

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

Почему Python оказался правильным выбором

Во-первых, FastAPI позволяет очень быстро поднять внутренний сервис и web-панель без лишней тяжести.

Во-вторых, LangGraph хорошо подходит именно для workflow-сценариев, где есть этапы, состояния, паузы и ручное утверждение.

В-третьих, интеграция с LM Studio через OpenAI-compatible API в Python делается просто и без лишней экзотики.

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

Какие проблемы всплыли в первом MVP

Первая версия сработала, но очень быстро стало видно, что «работает» и «удобно использовать» — это две разные вещи.

Сырой JSON в интерфейсе

Изначально planner, researcher и critic сохраняли результаты в JSON, и эти JSON-файлы просто выводились в карточке задачи. Формально всё было правильно: данные сохранялись, этапы проходили, история была. Но пользоваться этим было неудобно.

Вместо редакционного интерфейса я видел машинные контейнеры данных.

Это пришлось исправлять: разделить внутренние артефакты и человекочитаемое представление.

Проблемы с кириллицей

На одном из этапов выяснилось, что в интерфейсе отображаются \u041f, \u043e и прочие escape-последовательности. Это было не ошибкой модели, а ошибкой сериализации JSON.

После исправления UTF-8 и ensure_ascii=False проблема ушла, а интерфейс стал наконец нормально показывать русский текст.

Telegram-посты были слишком слабыми

Ещё одна проблема — Telegram-посты. Модель без жёсткого шаблона быстро скатывалась в типичный генеративный стиль:

Поэтому я ввёл для Telegram отдельный редакционный шаблон: короткий лид, блок «Что важно», несколько пунктов через длинное тире, короткий вывод от лица редакции и финальная строка со ссылкой на материал.

Это резко улучшило результат.

Поддержка англоязычных источников

Один из самых полезных этапов развития конвейера — добавление поддержки английских источников.

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

Для медийной и новостной работы это намного сильнее, чем отдельная кнопка «перевести статью».

Почему я оставил человека в цепочке

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

После прохождения конвейера задача всё равно попадает на ручное решение:

Это важный архитектурный принцип. Я не строил фабрику автопубликации. Я строил контролируемый редакционный инструмент.

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

Что этот конвейер уже даёт на практике

Сейчас система уже умеет:

То есть это уже не просто «эксперимент с агентами», а рабочий редакционный MVP.

Какие выводы я сделал

Одна LLM сама по себе — это ещё не редакция. Но одна LLM, встроенная в структурированный workflow с ролями, артефактами, промежуточными проверками и ручным approve, уже может быть сильным прикладным инструментом.

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

Что дальше

Дальше этот проект можно развивать в несколько направлений:

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

Именно такой подход, на мой взгляд, делает локальные LLM реально полезными в работе.