LLM divide and conquer

Типичный дизайн GPT предполагает сложность O(n^2). Возможно эту сложность по памяти снизили с помощью старого доброго подхода "Разделяй и властвуй", а именно стали разбивать большой вход на отдельные куски и каждый из них обрабатывать отдельно. Если это действительно сработает, то потенциально можно сильно уронить аппаратные требования к LLM. В идеале до O(n*log(n)), как в поиске и умножении длинных чисел, но это очень сладкая цель. В любом случае будет интересно!

Creabot

Если набирать Скуф в латинской раскладке, получается Creat. Почти как Creator, но Скуфещк как-то не звучит.

Немного поэксперементируем и получаем

Creabot набранный в русской раскладе это Скуфище.

Ну да, креативный бот, всё верно!

Под капотом чужого продукта

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

Суть в следующем. Компания использует некоторое покупное или открытое ИТ-решение и всё в нём устраивает, кроме некоторого недостающего функционала. И этот функционал не обеспечивается штатными возможностями продукта, конфигурацией или расширениями к нему. Возникает естественная мысль: а давайте найдём спеца/компанию или своими силами "доработаем напильником" решение как нам надо. Часто это можно сделать за вменяемые деньги и время, компания модифицирует решение и включает в свой ключевой бизнес-процесс. И всё работает, какое-то время.

Сложности начинаются по прошествии времени. Продукт у поставщика обновляется, а наш нет. Или обновляется, но работает не как ожидалось. Или работает, но через какое-то время появляются неожиданные ошибки. Или продукт поменялся так, что модификация с сохранением функционала теперь невозможна. Фактически компания теперь имеет кастомный продукт без возможности внятной поддержки. Таким образом получаются различные необновляемые CRM/ERP/фреймоворки и сторонние библиотеки, а 1С-ники отлично знают "счастье" работы с правленной конфигурацией.

Хороший вариант решения: написать свой модуль или расширение к используемому решению. К сожалению, такое возможно не всегда, да и в этом случае расширение зависимо от основного продукта и может потерять поддержку.

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

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

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

Тренды 2024-2025

Если коротко: Всё будет дорожать.

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

Почему персонал? Основная причина — государство расходы вешает на людей. И это касается не только России, где есть дополнительные статьи расходов. Номинальная стоимость жизни растет быстрее инфляции. Отдельная боль молодёжи это жильё. В результате непродуманной программы льготной ипотеки оно подорожало за последние 5 лет более чем в 2 раза, ипотека фактически недоступна.

Зумеры с порога просят большие зарплаты, но им фактически и не оставили выбора. Если нет наследства и поддержки родственников — смысла соглашаться на работу за еду у них нет. Неявно здесь вылазит и ещё одна давняя проблема — демография. Нет жилья — рожать не будут. Достаточно большое поколение 80-х уже выходит из фертильного возраста, а поколение 90-х существенно меньше. Да и жить им негде, 80-кам в этом смысле повезло чуть больше.

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

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

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

Нас ждут непростые времена.

О старых конфигурациях 1С

У одного заказчика используется 1С:Торговля достаточно старой версии на такой же старой платформе 8.2. И то, и другое уже не поддерживается 1C, никакие обновления не ставятся. Хранение данных выполнено в MS SQL старой древней, который установлен на ещё более древнем Windows Server. Конфигурация Торговли была достаточно сильно дописана на заказ именно под бизнес-процессы заказчика. И вот эта вся связка работает уже более 5 лет. Надо сказать, прекрасно работает.

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

С момента внедрения конфигурации прошло уже более 10 лет. СУБД, ОС и серверы, на которых это всё работает, устарели и их отдельно даже смысла обновлять нет.

Что делать? Конструктивно ничего с этим не сделать. Только делать всё наново. И в конкретно этом случае в новом решении из качественно-быстро-дешёво даже 2 пунктов не набирается.

Что сделали: оставили как есть.

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

Неподдерживаемый код

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

В продакшене могила компилировалась из исходников на тех же CentOS серверах примерно в те же годы, т.е. начало 2010-х. На тех же серверах работает код самого проекта на php 5.4 с остальным уже сильно не новым окружением. А код заказчика развивается и хотелось бы уже мигрировать новую спецификацию языка и использовать возможности новых библиотек. Но сделать это сложно.

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

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

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

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

Выводы:

  1. Избегать использования библиотек, поддержка которых вероятно скоро прекратится. Заранее это не всегда можно определить, но есть косвенные признаки.
  2. Писать код с продуманной архитектурой и интерфейсами, которые позволяют легко поменять хранилище (и не только его).
  3. Разделять задачу на разные уровни. Конкретно здесь хранение можно почти полностью реализовать на более низком уровне без существенного потери функционала.
  4. Использовать как можно более прозрачные и унифицированные инструменты.