Много раз проскакивало желание у многих получить простой инструмент, позволяющий следить за истекающими сертификатами SSL. Ниже представляю инструмент для самостоятельного развертывания в среде docker.
Код написан для python14, но работать будет и на других версиях (12, 13, 14 и т.д.).
Что включает проект (все в одном):
Предположим, вы построили RAG-сервис на SQL, и он отлично работает. Довольно быстро, очень точно, и очень дорого, ведь каждый запрос к сервису требует обращения к LLM для генерации ответа по чанкам, извлеченным из базы знаний. И чем больше мы извлекли таких фрагментов, тем больше входных токенов тратится на составной промпт, даже если ответ будет состоять из одного предложения.
Можно, конечно, заранее срезать количество извлекаемых чанков, но это отразится на качестве ответов.
Можно настроить кэш, который экономит на обращениях к сервису, когда приходят одинаковые вопросы. Но когда пользователь спрашивает "How to get developer support?”, и тут же другой пользователь спрашивает "How to ask development-related questions?", ваш сервис каждый раз будет генерировать ответ заново, сжигая ваши токены и заставляя пользователя ждать. Обычный кэш тут бессилен: для него эти две фразы — абсолютно разные ключи.
В этой статье я расскажу, как развернуть мощный семантический кэш на базе AlloyDB Omni (PostgreSQL от Google), используя векторный поиск ScaNN, автоматическое партиционирование и планировщик задач. Мы пройдём путь от настройки Docker-контейнера до продакшн-архитектуры.
Пролог: Почему бизнесу нужна эволюция, а не революция
Представьте сцену: Вы запускаете первый ИИ-агент для поддержки клиентов. Первые две недели — восторг. "Он отвечает! Он работает!" Месяц спустя — разочарование. "Он повторяет одни и те же ошибки. Не умеет работать со сложными запросами. Требует постоянного контроля".
Знакомо? Это классическая история "пилотного проекта, который не масштабируется".
Моя команда прошла этот путь. Мы потратили 18 месяцев на эволюцию от примитивного бота до системы, которая:
Самостоятельно обрабатывает 85% сложных запросов
Снизила операционные затраты на 40%
Еженедельно улучшает свои показатели на 3-5% без вмешательства разработчиков
В этой статье я покажу конкретные шаги этой эволюции с кодом, схемами и бизнес-обоснованиями. Вы узнаете не "как сделать крутого ИИ", а "как построить систему, которая сама становится круче".
Когда все вокруг пользуются ChatGPT и Claude, возникает естественный вопрос: а что, если попробовать сделать нечто подобное самому? Не для того, чтобы конкурировать с гигантами, а чтобы понять изнутри, как работают современные языковые модели.
Этот проект — моя попытка пройти весь путь: от токенизации текста до генерации кода. Не используя готовые решения от HuggingFace, а реализуя каждый компонент самостоятельно. И знаете что? Это оказалось одновременно сложнее и интереснее, чем я предполагал.
Мы все видим, как ассистенты и агенты меняют правила игры. То, что недавно называли «умной IDE» с подсказками, рефакторингом и статическим анализом, сегодня лишь разминка перед сбором функциональности. Ассистенты и агенты могут пройтись по десяткам файлов, обновить тесты и даже оформить базовую документацию. Но вместе с бешеной скоростью генерации пришёл и хаос.
Поговорим о том, как не дать «вайб-кодингу» развалить ваш продакшен и почему Spec-Driven Development (SDD) — это наш новый «компилятор», которому нужно доверять.
У нас в компании был один проект, с которым я не справился.
Дело было так: мне сообщили, что знакомый плюсовик написал какой-то скелет проекта на питоне, а теперь мне надо его допилить, подставив в нужные места реализации. Почему тогда делал он, а не я, а сейчас должен делать я, а не он? Да чёрт его знает. Но я подумал, что смогу — унаследуюсь и переопределю методы где нужно, подставлю зависимости во всякие DI, ну что там может быть плохого?
Оказалось, что плохо вообще всё.
Проект был раздут и переусложнён настолько, что буквально не умещался у меня в голове. Я уже начинаю подозревать, что, похоже, я LLM, и у меня контекст в районе 4096 токенов, потому что чем дольше я читаю код, тем меньше помню, что там было в начале. Изучая проект, я прыгал по стеку вызовов, пытаясь понять, что откуда вызывается и в какой последовательности, и просто в какой-то момент терялся. Проект меня победил, и его передали кому-то другому.
Недавно мне дали черновик статьи на редактуру, чтобы я её подправил где считаю нужным. А статья-то оказалась как раз про тот самый проект — автор рассказывал, как он классно всё написал. Вы даже не представляете, как сложно писать дифирамбы проекту, который настолько плох и полон антипаттернов, что можно собрать по нему целую статью. Так, подождите-ка, а что если...
Короче, вот она — анти-статья, собранная из того проекта. А где мне не хватало примеров, я брал код из Django, потому что он вообще полностью собран на антипаттернах.
Я инженер ОВиК, и меня достало каждый день гуглить перевод кгс/см² в бары. Универсальные конвертеры не знают про Гкал/ч и кгс/м², а инженерные калькуляторы — платные или с рекламой. Написал своё Android-приложение на Python/Kivy: 10 категорий, 60 единиц измерения (включая все инженерные), 5 калькуляторов (скорость в трубе, тепловая мощность с гликолями, расширительный бак по СП 60.13330, потери на клапане, площадь изоляции). Работает полностью офлайн, бесплатно, без рекламы. Рассказываю как сделал, с какими граблями столкнулся и как выложил в RuStore.
Кэш-монтирование в Docker — это мощный инструмент, который может значительно ускорить процесс сборки образов в CI/CD. Но его правильная настройка в GitLab требует понимания не только работы BuildKit, но и особенностей взаимодействия с различными конфигурациями GitLab Runner — DinD и DooD.
В этой статье я расскажу об устройстве кэш-монтирования в Docker и как его использовать в GitLab CI/CD. На примере простой сборки Python-проекта покажу готовые решения для кэширования зависимостей, чтобы оптимизировать сборку Docker-образов.
Выбор фреймворка для глубокого обучения — это стратегическое решение, влияющее на скорость разработки, стоимость и масштабируемость. Правило «PyTorch — для исследований, TensorFlow — для продакшена» больше не работает. К 2026 году оба фреймворка активно заимствуют лучшее друг у друга: PyTorch наращивает промышленные возможности (TorchServe, ExecuTorch), а TensorFlow с Keras 3 становится гибче для исследований.
Согласно опросу Stack Overflow Developer Survey 2024, PyTorch (10,6%) и TensorFlow (10,1%) находились примерно на одной отметке по частоте использования у разработчиков, а в исследовательских и AI-first-компаниях уверенно лидирует PyTorch. Но есть нюансы.
Какая структура данных стоит за list? Как быстро отрабатывает операция append? Эти вопросы часто задают на собеседованиях, и чтобы на них отвечать, нужно понимать, как список работает под капотом. В этой статье разберём, как же устроен список в питоне, копнём на уровень CPython и позапускаем код. После прочтения вы будете знать о списках больше, чем ваши коллеги.
С точки зрения нейронных сетей мир плоский. Иерархические данные напоминают, что это не так.
Работа нейронных сетей неотделима от допущения, что всего одна функция отображает вводные данные на выходные. Но в реальных условиях данные редко вписываются в такие рамки.
Допустим, есть клиническое исследование, проводимое сразу в нескольких больницах. Лекарство одно и то же, но отличаются популяции пациентов, процедуры и порядок ведения записей. В таких случаях наблюдения группируются в разные датасеты, каждый из которых управляется скрытыми параметрами.
Стандартные нейронные сети в таких условиях жёстко сбоят. Обучите одну модель сразу на всех датасетах — и она расфокусируется из-за различий, станет усреднять функции, которые усреднять не следует. Натренируйте по модели на каждом из датасетов — и получите переобучение, в особенности, если датасеты будут маленькими. Такие обходные манёвры как задействовать статические векторные представления (эмбеддинги) или постоянно наращивать размер сети в сущности не решают ключевую проблему: система запоминает причуды сети, не моделируя её структуру, складывающуюся на уровне датасета. А ведь именно эта структура — залог качественных результатов.
Некоторое время назад я опубликовал статью про генерацию синтетических данных для электродуговых печей (EAF). Идея была проста: реальных промышленных данных нет (они стоят миллиарды или засекречены), а учить ML‑модели на чем‑то надо.
Статья вызвала неожиданно обсуждение. В комментариях собрались профильные инженеры, дата‑сайентисты и те самые «душные физики»(в хорошем смысле), которые заставили меня переписать генератор с нуля. Этот пост — история о том, как проект эволюционировал от простой таблицы с цифрами до сложного симулятора, который прошел аудит экспертов и был разобран на части математическим методом Курамото.
Сегодня мы выходим в продакшн с системой "Шампур Логистик", которая пакует флот из 15 судов и распределяет манифест на 70 000 контейнеров быстрее, чем вы успеете допить кофе.
Это уже не просто «тетрис в вакууме». Мы построили промышленный конвейер на FastAPI и Celery, где математическое ядро с 90% Test Coverage сталкивается с суровой физикой моря: лимитами стекирования в 210 тонн, жестким LIFO-зонированием портов и капризными рефрижераторами.
В этой статье я покажу изнанку системы: как за 16 минут превратить маркетинговый хаос в выверенный цифровой двойник рейса, почему 10% свободного места в трюме — это не ошибка, а осознанная экономия миллионов долларов, и как наш "Шампур" защищает прибыль перевозчика в закрытом море кода.
<cut />
Всем привет! Хочу рассказать не столько про свою модель, сколько про инженерные компромиссы, с которыми я столкнулся во время работы над проектом. Буду рад любой критике.
Речь пойдет о моем проекте edge-weather-forecast — лёгкой нейросетевой модели прогнозирования температуры, которую можно запускать прямо на метеостанции или на простом CPU-устройстве вроде Raspberry Pi.
Приветствую, Хабр! Представляю вам свой фреймворк - ai-sidekick
Мы разберём готовый к работе фреймворк для экспериментов с MCP-tools. А также, на его основе, рассмотрим архитектуру RAG (Retrieval-Augmented Generation) AI-ассистента для поиска информации в вашей собственной базе знаний. Это не набор абстракций в тысячу строк, а минималистичная кодовая база на Python и Docker, которая предоставляет возможность экспериментировать с конфигурациями и кодом под ваши задачи.
Привет! Если у вас когда‑либо был опыт деплоя нейросетки, вы знаете, что обучение — это полдела, а вот добиться шустрого инференса — целое искусство. Часто обученная в PyTorch модель дает замечательные метрики, но стоит попытаться запустить её в приложении начинаются всякие проблемки.
Одно из решений, которое часто выручает — ONNX и ONNX Runtime. Если эти буквы для вас пока ничего не значат — не беда, сейчас разберёмся что к чему. А если вы уже слышали про ONNX, то, возможно, задавались вопросом: «А реально ли ускорить инференс, заморочившись с этой технологией?» Еще как!
Большая статья для тех, кто, как и я, споткнулся об asyncio и так не разгадал до конца «магию» событийного цикла. Попробовал распутать этот клубок через подробный рассказ (в как можно более доступной форме) о внутренних механизмах Линукса и самого asyncio, которые лежат в основе событийного цикла. К концу статьи, надеюсь, магия исчезнет, а взамен придет ясное понимание фундамента. Статья будет полезна и тем, кто работает с asyncio на других платформах.
Django Rest Framework (DRF) - чуть ли не единственный фреймворк для разработки REST на базисе Django. Мой нарратив о Django в прошлой статье заключался в том, что это неповоротливый монолит, который абсолютно не следует best practices и не стремится к ним. Если вдруг вы не задумывались о том, как связаны DRF и Django, то вас может быть немного это удивит - никак. Их делали совершенно разные люди, но каким-то образом они сошлись в общей концепции: игнор хороших практик, перегруженные классы и магия, превращающая разработчика в гадалку.
Агенты отлично справляются с узкими, конкретными задачами — например, написать функцию или короткий текст — но начинают буксовать на сложных многошаговых процессах. Чем более абстрактна и «высокоуровнева» работа, тем больше ошибок они допускают: путают шаги, пропускают операции, неверно интерпретируют инструкции. Такие ошибки накапливаются и усиливают друг друга, приводя к неожиданным результатам. Чем больше задача, которую вы отдаёте агенту, тем выше шанс, что он её провалит.
Помедитировав немного над этим, я пришёл к интересным эвристикам.
Большинство высокоуровневой работы более алгоритмично, чем кажется на первый взгляд.
Большинство низкоуровневой работы менее алгоритмично, чем кажется на первый взгляд.
Например, существует масса формализованных циклов проектирования (PDCA, OODA, DMAIC, 8D и etc.) — по сути, тривиальных мета-алгоритмов; однако каждый шаг этих алгоритмов — это куда более сложная и нетривиальная задача.
Значит, стоит стремиться давать агентам низкоуровневые задачи с небольшим, ясным контекстом, а высокоуровневые процессы описывать алгоритмически.
Обычно всё начинается с очень простой задачи, которую нужно решить чем быстрее, там лучше. «А можно ли сделать так, чтобы пользователи сами записывались на консультацию через Telegram?» или «кто-то должен отвечать на типовые вопросы клиентов ночью, пока саппорт спит». Как правило, на этом этапе вспоминают о Telegram-ботах, но тут вопросов возникает еще больше. Сколько стоит разработка? Можно ли создать такого бота своими силами? Что для этого нужно? Насколько это сложно? Или вообще, — а что там внутри этих самых Telegram-ботов, кроме команды «/start»?
