Python *

Хочу рассказать о том, как я создавал tg бота на локальной LLM Ollama и с какими проблемами я столкнулся. Бот написан на python и библиотеке telegram.

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

Модели я подбирал под свой компик: 5070 и 32 гб оперативы. Сервера своего нету, поэтому бот работает только когда я дома.

Бот продолжает развиваться. Следить за обновлениями и новыми фичами можно в моем Telegram-канале: https://t.me/rocet_0

На своем тг-канале я предлагаю подписчикам выбор, какую бредовую идею запилить следующей. На этот раз подписчики выбрали новый челлендж: сделать Git в Telegram. Чтобы можно было через бота инитить проекты, пушить файлы, коммитить — и всё это в публичном канале с тредами.

С практической точки зрения этот проект нахуй не нужен. Есть гитхаб, есть гитлаб, есть куча нормальных инструментов. Но как эксперимент — почему бы и нет? Чисто посмотреть, можно ли заставить Telegram работать как VCS.

Я тогда подумал: «Ну, бот на aiogram, база данных, пара команд — делов то))»

Словари, датаклассы и прочая е*атория

Когда я только начинал, первая мысль была: «Положу всё в JSON, на кой мне база данных?» Ну серьёзно, проектов мало, пользователей немного, файлы текстовые че заморачитватся.

Подергал JSON туда-сюда пару дней и понял: не варик.

Во-первых, конкурентный доступ. Два юзера одновременно коммитят — один из них перезаписывает файл другого. Во-вторых, целостность данных. Если бот упал в середине записи — JSON остаётся в невалидном состоянии. В-третьих, версионность. Хранить историю изменений в JSON — это просто перенести проблему из кода в структуру файла.

Короче, JSON — для конфигов, а не для данных, которые меняются каждую секунду.

Выбор пал на SQLite.

Почему:

Ввиду серьёзных ограничений, которые могут быть введены для Telegram, а также возможной блокировки сервиса, я решил сделать простой скрипт для сохранения информации из диалогов. В первую очередь — из Saved Messages (Избранное).

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

Всем привет. В ходе этого материала вы узнаете:

1. Как сделать простой рендер на c# в MonoGame

2. Что использовать, чтобы вызвать python из c#

3. Почему пункт 2 - это плохая идея

4. Как MonoGame игру сбилдить в web/html с помощью его форка KNI

Пристёгивайтесь, будет весело!

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

Но есть более фундаментальный вопрос - кто в системе определяет правила игры?

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

- часть проверок живeт во фронтенде

- часть - в API,

- часть - в промежуточных сервисах

- часть — во временных проверках, добавленных после инцидентов

Добавили новый сервис в цепочку - и изменилось поведение.

Вынесли проверку в отдельный процессинг - и появились состояние гонки.

Перестроили оркестрацию - и неожиданно стала недоступной операция, которая раньше работала.

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

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

Мы отвлекаем существенные ресурсы в поисках решения для проблем.

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

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

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

Добро пожаловать в обсуждение! Буду рад конструктивной критике и дополнениям.

Привет! Меня зовут Фаина, я системный аналитик с опытом более 5 лет. В последнее время все чаще стала задумываться как системному аналитику в текущих реалиях применять в работе ИИ. Так началось мое погружение в увлекательный мир LangChain, ИИ, RAG и векторные БД.

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

Большинство AI-инструментов — либо облако, либо код под каждую задачу. Coreness Flow строится вокруг событий: пришло сообщение, сработал cron, прилетел webhook — агент находит сценарий по триггеру и выполняет цепочку шагов.

Плагины декларируют вклад в интерфейс через config.json — фронт собирает вкладки и настройки по этим данным, без правки React-кода. Новый плагин — новая вкладка, без хирургии во фронтенде. RAG полностью локальный: BGE-M3 ONNX INT8 + Qdrant embedded в процессе приложения, гибридный поиск офлайн. Разбор архитектуры — API Bus, lifecycle, система сценариев с триггерами и переходами.

Приветствую читателей.
Мы пытались построить LLM-чат для продакшена.
Через месяц у нас был 20k-токенный prompt, 50 тулзов и ответы по 2 минуты.
В итоге пришлось отказаться от ReAct и перейти на LLMCompiler.

А начали мы с того что компания захотела поекспериментировать с созданием чата

Для начала освежим память как вообще работает llm и react архитектура.
С точки зрения разработчика, ллм - это функция, которая принимает на вход строку и отдает другую строку, входящая строка может прораммировать то, какой ответ будет, например, вы можете попросить ллм вести себя как чат, далее хранить историю входов и выходов и передавать ее опять в ллм.

Простейший пример чата.

Алгоритм Крускала (также алгоритм Краскала) - алгоритм, который преобразовывает связный неориентированный граф в минимальное остовное дерево. На самом деле пока что непонятно, что делает он, поэтому разберём поподробнее.

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

Привет, Хабр! Меня зовут Владимир Кочетков, и я тимлид Deep Learning разработки в области распознавания речи и соавтор курса «MLOps для разработки и мониторинга моделей» в Яндекс Практикуме.

Сегодня поделюсь опытом, как мы с командой внедряли менеджер ML-экспериментов, и расскажу: в чём сложность обучения моделей; когда нам понадобился менеджер экспериментов; какие были к нему требования и как они эволюционировали в процессе; что мы выбрали и почему; как это работает в жизни.

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

В этой статье я расскажу о том, как был создан CodeWiki Skill для Claude Code (и не только) - инструмент, который автоматически генерирует полноценную структурированную документацию для любого репозитория, используя мультиагентный подход.

Афанасий Фет написал импрессионистскую картину в стихах. Сможет ли цифровой анализ объективно подтвердить или опровергнуть этот миф?

Когда все вокруг пользуются ChatGPT и Claude, возникает естественный вопрос: а что, если попробовать сделать нечто подобное самому? Не для того, чтобы конкурировать с гигантами, а чтобы понять изнутри, как работают современные языковые модели.

Этот проект — моя попытка пройти весь путь: от токенизации текста до генерации кода. Не используя готовые решения от HuggingFace, а реализуя каждый компонент самостоятельно. И знаете что? Это оказалось одновременно сложнее и интереснее, чем я предполагал.

Сегодня мы выходим в продакшн с системой "Шампур Логистик", которая пакует флот из 15 судов и распределяет манифест на 70 000 контейнеров быстрее, чем вы успеете допить кофе.

Это уже не просто «тетрис в вакууме». Мы построили промышленный конвейер на FastAPI и Celery, где математическое ядро с 90% Test Coverage сталкивается с суровой физикой моря: лимитами стекирования в 210 тонн, жестким LIFO-зонированием портов и капризными рефрижераторами.

В этой статье я покажу изнанку системы: как за 16 минут превратить маркетинговый хаос в выверенный цифровой двойник рейса, почему 10% свободного места в трюме — это не ошибка, а осознанная экономия миллионов долларов, и как наш "Шампур" защищает прибыль перевозчика в закрытом море кода.

<cut />

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

Помедитировав немного над этим, я пришёл к интересным эвристикам.

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

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

Например, существует масса формализованных циклов проектирования (PDCA, OODA, DMAIC, 8D и etc.) — по сути, тривиальных мета-алгоритмов; однако каждый шаг этих алгоритмов — это куда более сложная и нетривиальная задача.

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

Играть в игры весело, а ещё веселее их разрабатывать!

Сегодня мы создадим простейшую игру для Telegram, представляющую собой Mini App.

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

В нашей игре нужно будет прыгать по платформам и собирать звёзды.

Ссылка на игру – вы можете пройти её сами.

Современные WAF — это крепости, которые открывают ворота любому, кто знает секретное рукопожатие. Я переписал свой Red Team сканер с Python на Go и обнаружил, что топовые защиты сдаются и отдают бинарные данные, принимая бота за легитимный браузер. История о том, как uTLS и правильный ClientHello ломают логику "защитников". Код, бенчмарки и (конечно) тесты, проведенные строго на внутренних полигонах.

Машинное обучение обычно ассоциируется с датасетами, метриками и бесконечными экспериментами в ноутбуках. Но в какой-то момент для нас ML перестал быть абстрактной технологией - и стал маршрутом. Причём буквально. Эта история о том, как модели, гипотезы и пара неочевидных решений привели нас не только к рабочему результату, но и на самый настоящий остров Парамушир (северные Курилы).

Попытка улететь на вертолёте из Петропавловска-Камчатского в Северо-Курильск сразу превратилась в маленькое приключение: местные хором пугали погодой и перспективами — «можете не прилететь, а если вдруг прилетите, то потом не улетите». Камчатка в этом смысле честна и беспощадна, особенно к планам. Но желание полетать на вертолёте здесь перевешивало все разумные доводы — уж слишком манила сама идея увидеть полуостров с воздуха, да ещё и недорого (у вертолетных экскурсии на Камчатке кусачие цены). На вопрос "как не играть в рулетку с погодой" - ответ очевиден, ML.

P.S. хоть Хабр и не про туризм, но вдруг кому интересно, на Парамушире есть и свои достопримечательности, такие как действующий вулкан Эбеко и аэродромное плато (бывшие японские ангары) поэтому не только ради дешевого полета на вертолете мы оказались в Северо-Курильске.

Задача оценивания состояния динамической системы по неполным и зашумленным измерениям считается фундаментальной проблемой в теории управления, навигации, робототехнике и обработке сигналов. Рекурсивный фильтр Калмана обеспечил возможность аналитического решения для линейных систем с аддитивными гауссовскими шумами. Однако практические системы редко удовлетворяют ограничениям линейности и гауссовости. И если для учета нелинейности в инженерном сообществе в целом существует консенсус в пользу нелинейных фильтров, то с не‑гауссовскими шумами все сложнее.

Так, Википедия прямо отмечает: «Бытyет ошибочное мнение, что для правильной работы фильтра Калмана якобы требуется гауссовское распределение входных данных».

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

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

1. Снижается ли производительность линейного фильтра Калмана при различных типах не‑гауссовских шумов.
2. Как и чем измерить это снижение (если оно происходит).
3. Чем можно заменить линейный фильтр Калмана в этих условиях и какова цена такой замены.

В настоящей статье с помощью численного моделирования и специализированных метрик NEES и NIS делается попытка дать ответы на эти три вопроса.