Типичный дизайн 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, сделали единую структуру файловой системы, путь в которой не зависит от места хранения. Далее уже задача программистов перенести файлы со старой системы на новую. Для этого написали отдельный скрипт, которой вытягивал файл со старой на новую и правил путь в базе данных. Отдельно для кода заказчика пришлось писать новый интерфейс доступа к файлам и менять старые вызовы в коде на использование этого интерфейса.
Долго запрягали, но поехали очень быстро. За половину суток скрипт обработал все файлы и доступ к ним через новый интерфейс неожиданно оказался намного быстрее. И самое главное: можно полностью избавиться от всего старого окружения.
Выводы:
- Избегать использования библиотек, поддержка которых вероятно скоро прекратится. Заранее это не всегда можно определить, но есть косвенные признаки.
- Писать код с продуманной архитектурой и интерфейсами, которые позволяют легко поменять хранилище (и не только его).
- Разделять задачу на разные уровни. Конкретно здесь хранение можно почти полностью реализовать на более низком уровне без существенного потери функционала.
- Использовать как можно более прозрачные и унифицированные инструменты.