Контролируемая эволюция RAG-системы: оценка mcp серверов и кеширование результатов запрос-ответ
В статье рассматриваются теоритические выкладки как возможно эволюционировать RAG-систему на одном домене (документация 1С). Эволюцию можно расширить на использование нескольких доменов (финансы, бух.учет, юриспруденция, кодинг и.т.п.)
От уравнений до верификации: как мы сравнивали разработанный веб-модуль для анализа потерь в НКУ (низковольтных комплектных устройствах) с нормативной базой
А можно ли рассчитать потери и нагрев шин для оценки тепловыделения в НКУ быстро, точно и прямо в браузере?
Мы решили проверить — и разработали веб-ориентированное расчётное ядро, которое затем сравнили с требованиями ГОСТ.
В электроэнергетике и электротехнике тепловой расчёт НКУ — это не просто рутина, а ключевой вопрос при оценке безопасности и эффективности НКУ. При тепловом расчёте НКУ необходимо учитывать потери мощности в шинах и аппаратах — именно они являются основным источником нагрева внутри шкафа.
Шины, при протекании по ним тока, нагреваются из-за Джоулевых потерь, и если температура выходит за рамки нормы, последствия предсказуемы: ускоренное старение изоляции, рост потерь энергии, а в критическом сценарии — перегрев и выход из строя оборудования.
На практике инженеры часто оказываются перед выбором:
Нормативные таблицы — надёжно и консервативно;
Дорогие CAE-пакеты (COMSOL, ANSYS) — сложно, точность требует времени и бюджета;
Упрощённые ручные расчёты — быстро, но менее точно.
А что, если объединить скорость, точность и прозрачность в одном веб-инструменте?
В этой статье мы покажем, как на основе физических уравнений мы разработали веб-ориентированное расчётное ядро для теплового расчёта шин, а затем — докажем его точность в сравнении с ГОСТ.
Нейронные сети сегодня уже не какая-то магия из научных статей. Они стоят за рекомендациями в сервисах, распознаванием изображений и, конечно, за LLM-моделями, которыми мы пользуемся каждый день. Но знакомство с ними у многих происходит через готовые библиотеки такие, как PyTorch или TensorFlow: написал пару строк кода — модель обучилась — всё работает. А что именно произошло внутри обычно остаётся загадкой.
Feed-forward нейронная сеть (FNN) — одна из самых базовых архитектур, на основе которой исторически выросли более сложные модели: DNN, CNN и многие другие современные подходы. Хотя сама по себе она редко используется в практических задачах в чистом виде, именно через неё проще всего понять фундаментальные принципы обучения нейросетей.
В этой статье мы реализуем нейронную сеть прямого распространения с нуля, используя только Python и NumPy — без готовых ML-фреймворков. Такой подход позволяет на практике увидеть, как работают основные концепции и принципы нейронных сетей. Погружаясь одновременно в математику и программирование, вы сможете получить более глубокое понимание того, что происходит внутри модели во время обучения и предсказаний.
Эта реализация станет основой для дальнейшего изучения: по мере освоения материала можно экспериментировать с более сложными архитектурами, различными функциями активации и методами обучения, улучшая свои собственные модели. Статья рассчитана на читателей с базовым пониманием линейной алгебры и Python, и ее цель — показать, как ключевые математические идеи превращаются в работающий код.
Задача: человек регистрируется, оплачивает, получает ключ на почту и сразу подключается. Без ручной работы с моей стороны. Под капотом — FastAPI, Marzban, PostgreSQL, React, ЮKassa, Resend. Расскажу про архитектуру, грабли и неочевидные решения.
Во второй части мы сделали консольный чат с циклом и system prompt. Но у него был пробел: каждый запрос шёл к модели независимо, без контекста предыдущих реплик. В третьей части добавляем историю сообщений — и чат наконец начинает помнить разговор.
TL;DR: В этой статье мы возьмем новейшую Gemma 4 31B, которая в оригинале весит 62 ГБ, и заставим её работать и выгружаться на бесплатном Kaggle с лимитом диска в 57 ГБ. Спойлер: нам придется удалять исходники прямо во время работы Python-скрипта.
Когда в FastAPI-проекте появляется нормальная авторизация, код быстро начинает расползаться в стороны.
Сначала все выглядит терпимо: один Depends(get_current_user), один Depends(get_enforcer), одна ручная проверка. Потом роутов становится больше, правил доступа становится больше, и внезапно половина endpoint’ов начинает содержать не бизнес-логику, а обвязку вокруг нее.
В какой-то момент меня перестал устраивать и классический подход через dependency injection в каждом роуте, и вариант с middleware. Хотелось, чтобы правило доступа было видно прямо рядом с маршрутом, но при этом не приходилось таскать авторизацию в сигнатуры всех функций.
В итоге я собрал casbin-fastapi-decorator — тонкий слой над Casbin для FastAPI, который позволяет описывать authorization через декораторы.
Идея простая:
Но очень быстро оказывается, что настоящая сложность не в самих задачах, а в инфраструктуре вокруг них.
Сначала хочется просто запускать код в фоне. Потом появляются ретраи, таймауты, логирование, контроль выполнения. Ещё чуть позже всплывают совсем неприятные вопросы: что делать с пропущенными запусками после рестарта, как не дублировать задачи и где вообще должна жить логика планирования.
В какой-то момент становится очевидно:
Это продолжение предыдущей публикации про реставрацию ruGPT3XL. Для тех кто не читал, кратенько, я конвертировал древний Megatron-LM чекпоинт в HuggingFace-формат, залил веса на HF, накатил поддержку GGUF в llama.cpp и подумал, что всё. Но нет.
По ходу тестов, проведённых разными людьми удалось выявить ряд недоработок, которые я по мере обнаружения правил, ну а после того, как удалось получить стабильную и рабочую версию мне захотелось решить одну старую проблему, которая меня в ruGPT3 моделях очень беспокоила, это проблема маленького контекста в смешные 2k токенов.
Решил поднять контекст до 8k.
Недавно перед нами встала задача быстро реализовать микросервис для конвертации видео. Стандартным решением для таких целей является FFmpeg, который умеет читать файлы чанками (запросы HTTP Range) с URL и выводить результат в stdout. Поэтому я решил попробовать подход с потоковой конвертацией.
Важно уточнить, что под «потоковой обработкой» здесь подразумевается передача данных в виде последовательности чанков (Chunked Streaming), а не классический Continuous Streaming, как в случае с live-видео.
Давайте рассмотрим реализацию конвеевской игры «Жизнь» при помощи графической карты. Я хочу поэкспериментировать с разными библиотеками и методиками, чтобы понять, как обеспечить наилучшую производительность. Начнём мы с простого и постепенно будем повышать сложность.
Игра «Жизнь» — это простой клеточный автомат, поэтому она должна хорошо поддаваться GPU-ускорению. Правила просты: каждая ячейка в двухмерной сетке или жива, или мертва. На каждом шаге мы подсчитываем живых соседей ячейки (включая диагонали). Если ячейка жива, она остаётся живой, если живы два или три её соседа. В противном случае она умирает. Если клетка мертва, она оживает, если живы ровно три соседа. Из этих простых правил возникает потрясающий объём сложности, о котором написаны подробные статьи.
Для простоты я буду рассматривать только сети N×N и пропущу вычисления на краях. Всё будет работать на Nvidia A40, а бенчмарк производительности я буду проводить при N=216. Пока мы будем хранить каждую ячейку в виде 1 байта, поэтому весь массив займёт 4 ГБ.
Весь код выложен в репозитории GitHub.
Что делать, если по литературе задали два тома "Войны и мира", а времени (или желания) читать нет? Конечно, запрячь нейросеть! Но как быть, если в твоем распоряжении всего 10 ГБ видеопамяти, а модель упорно пытается "убить" выживших героев и переименовывает Пьера Безухова в Бездаровского?
В этой статье я поделюсь опытом запуска Saiga Llama 3 8B на домашнем железе, расскажу, как бороться с галлюцинациями через промпт-инжиниринг, и почему 7500 символов текста Толстого иногда весят столько же, сколько одна строчка жесткого правила в системном промпте. Внутри - анализ вероятностей токенов, лог работы модели и готовый код для суммаризации длинных текстов.
Если ввести в поиск запрос object detection, почти сразу среди результатов окажутся модели семейства YOLO в разных версиях. Это неудивительно: они популярны, быстры, достаточно просты в использовании и хорошо подходят для прикладных задач. Модели вроде YOLO и RF-DETR обычно работают по одной и той же схеме: на вход подается изображение, на выходе мы получаем предсказания объектов.
Такой подход удобен и хорошо работает для картинок. Но видео — это не просто набор независимых кадров.
Мы не стали спорить с TIOBE и RedMonk и собрали свой рейтинг языков программирования на основе GitHub. Данные за 2024–2025 показывают неожиданные вещи: JavaScript впереди, TypeScript резко растёт, а Rust и Go выигрывают по качеству проектов. Разбираем, что стоит за цифрами и где могут быть искажения.
Представьте логиста, у которого перед глазами 400 разных коробок и 8 машин. У него есть Excel, калькулятор и два часа времени. Я решил, что это несправедливо, и написал веб-сервис на Django, который делает это мгновенно. Внутри: 3D MaxRects, полная свобода вращения (6 осей) и учет суровой реальности — от очередности выгрузки до предельной нагрузки на нижние ряды.
Для тех, кто предпочитает один раз увидеть: вот 3-минутное демо работы интерфейса и визуализации на Three.js
В то время как одни пытаются обосновать, какой язык лучше в качестве средства обучения программированию школьников, посмотрим на вопрос с другого угла. Ведь не только языки бывают разными, также не всегда одинаковы цели обучения, методики (подходы), обучаемые. Поэтому вероятно в одних случаях может быть лучше один язык, в других — иной.
Всем привет!
Если вы хоть раз пытались нормально вкатиться в разработку Telegram-ботов, то почти наверняка сталкивались с одной проблемой: информации в интернете много, но она какая-то рваная. То есть где-то вам сразу дают библиотеку, заставляя писать код и даже не объяснив, как бот вообще работает.
В особых сценариях (например разработка userbot) смешивают воедино Telegram Bot API, Telegram API (да, это разные вещи!), api_id, api_hash, token, chat_id, webhook и еще десяток терминов.
А где-то вообще показывают “hello world”, который фактически-то работает, но только ты ступишь на шаг вперед, так всё начинает разваливаться, ведь понимания практически 0.
В этой статье моя цель - разобрать всё это нормально и по-человечески, объяснив как использовать Telegram Bot API для создания ботов.
Сегодня (2026.04.01) прошло ровно 9731 день с тех пор, как сообщество Python узнало об изъяне в работе со строками.
Это было так давно, что у Python еще не было мажорных версий (для холиваров приходилось использовать PHP).
Так давно, что еще не существовало ни pythonchallenge.com, ни его прародителя notpron.com - легендарных убийц времени программистов.
Это было в прошлом тысячелетии. А именно - 1999 году, когда, согласно летописям, реализовали тип string. В том же году ведущий разработчик Jim Fulton опубликовал исследование, где без купюр указал на проблему.
Как ни странно, она не решена до сих пор.
Имитация движений: как научить робота повторять движения, используя нейросеть для генерации траектории.
Привет, Хабр!
На днях HR-отдел отклонил мое резюме на позицию джуна. Вместо фидбека я получил ответ «В нашей команде слишком много козерогов, и нашему тарологу не понравился ваш Сатурн». Сначала я хотел возмутиться, но потом подумал. Может звезды не врут? Возможно наш звездный язык программирования определяется в зависимости от расположения планет во время первого запуска IDE.
Я провел фундаментальное исследование, проанализировал натальные карты Гвидо ван Россума, Страуструпа и прочих, и составил первый в мире точный гороскоп языков программирования.
И результат меня поразил...
