Я с GitHub Copilot (Claude) собрал полностью локальную RAG-систему с GUI, которая индексирует мои учебники и генерирует по ним отчёты, презентации, конспекты и эссе. Всё работает офлайн. В статье — архитектура, выбор компонентов, процесс совместной разработки с ИИ-ассистентом, грабли и рабочий код.
Я делаю локально работающего ИИ-агента и столкнулся с тем, что стандартный подход «закинуть текст в векторную базу, достать по косинусу» для долгоживущего агента не работает: контекст замусоривается, факты конфликтуют, ничего не забывается. Вместо этого реализовал графовую когнитивную память поверх одного файла SQLite: эпизодические и семантические узлы, типизированные рёбра, именованные сущности, гибридный поиск (FTS5 + vector + graph) с Reciprocal Rank Fusion, кривую забывания Эббингауза и фоновую LLM-консолидацию. В статье — полная архитектура с кодом, SQL-схемой и формулами. Код и минимальный пример — в репозитории.
Мониторинг мониторинга - звучит как масло масляное, но именно этим мы постоянно занимаемся в PingZen. Ведь наш сервис должен быть надёжнее, чем объекты, которые он отслеживает. Если PingZen упадёт, кто сообщит о падении вашего сайта?
Сегодня я залезу под капот тестирования PingZen и расскажу, как мы дошли до 10 900 автоматических тестов (5100 на бэкенде и 5812 на фронтенде). Все цифры и технологии - строго из нашего репозитория . Без хайпа, только факты, код и архитектурные решения.А статью подробнее про Pingzen можете посмотреть здесь
Внутренние инструменты — это странный жанр. Ты не делаешь продукт для миллиона пользователей. Ты делаешь для двадцати человек, которые будут использовать это каждый день. И если облажалась — они скажут тебе об этом лично. Прямо на созвоне. Иногда с демонстрацией экрана, где всё сломано.
Я занимаюсь этим несколько лет. Python, внутренние сервисы, утилиты, автоматизация. За это время появился довольно конкретный взгляд на то, как надо работать. Не из учебника, а через синяки.
Как определить дистрибутив Linux? А что, если имеется только информация о пакетах, установленных на устройстве? История одного «велосипеда» или мы не нашли готового решения.
Представьте, что вам нужно определить дистрибутивы, опираясь исключительно на установленные пакеты. Инвентаризация есть, но данные неполные — часто известно только имя хоста, IP и список установленных пакетов. Операционная система может быть указана как «Linux» без уточнения дистрибутива и версии. О создании алгоритма, работе с KUMA и написании код в данной статье.
Мы привыкли обсуждать микросервисную архитектуру с точки зрения границ сервисов, ответственности команд, масштабируемости и отказоустойчивости. Мы спорим о том, как правильно нарезать домен, где провести границы и какие сервисы должны взаимодействовать напрямую.
Но есть более фундаментальный вопрос - кто в системе определяет правила игры?
В реальных финтех-системах бизнес-логика часто начинает зависеть от того, как именно разложены микросервисы. Допустимость действий формируется не в одном месте, а распределяется по цепочке:
- часть проверок живeт во фронтенде
- часть - в API,
- часть - в промежуточных сервисах
- часть — во временных проверках, добавленных после инцидентов
Добавили новый сервис в цепочку - и изменилось поведение.
Вынесли проверку в отдельный процессинг - и появились состояние гонки.
Перестроили оркестрацию - и неожиданно стала недоступной операция, которая раньше работала.
В этот момент происходит архитектурный перекос - не бизнес-процесс определяет систему, а структура сервисов начинает определять поведение процесса.
Для финтеха это особенно критично. Допустимость действия - это не просто проверка прав. Это функция состояния процесса, версии правил, контекста операции и регуляторных ограничений. Если эта допустимость зависит от связности сервисов или порядка их вызова, система становится хрупкой и уязвимой, и тогда, начинается разговор о подходе, в котором бизнес-логика централизуется, версионируется и становится инвариантной к физической архитектуре.
Мы отвлекаем существенные ресурсы в поисках решения для проблем.
В мире Python есть особый вид функций — невидимки. У них нет имени, документ-строки и даже нормального тела. Они живут одну строку и умирают, сделав свое дело. Это лямбда-функции.
Многие новички считают их бесполезной игрушкой или, наоборот, пытаются запихнуть всю логику в одну лямбду, превращая код в нечитаемое месиво. В этой статье мы разберемся, где проходит эта грань. Мы не просто выучим синтаксис lambda x: x, мы поймем, как они устроены внутри, как их использовать с инструментами вроде map, filter, sorted, и главное — когда от их использования стоит категорически отказаться.
Как я написал радар межбиржевых спредов на Python и понял, почему 90% публичных ботов считают прибыль неправильно
Привет! Меня зовут Егор Лукьянов, я старший аналитик данных в Ozon Tech. В своей работе я часто сталкиваюсь с проблемой масштабируемости в pandas. Код, который быстро работает на гигабайте данных, начинает невыносимо тормозить на десяти. Уверен, эта боль знакома многим.
Сейчас есть быстрые альтернативы, например, Polars. Я сам пробовал переводить на него свои проекты. Скорость действительно впечатляет, но как в анекдоте есть нюанс: приходится переписывать чуть ли не весь код и привыкать к новому синтаксису. А это большая работа, на которую не всегда есть время.
И вот здесь я наткнулся на FireDucks — библиотеку, которая обещает решить эту проблему, просто заменив одну строку импорта. Звучало слишком хорошо, чтобы быть правдой. После опыта с Polars я был уверен, что где-то должен быть подвох.
Я решил проверить FireDucks на нескольких типичных задачах. В этой статье я хочу без лишнего хайпа поделиться тем, что у меня получилось. Мы посмотрим на реальные примеры кода, сравним скорость и разберёмся, где эта библиотека действительно хороша, а где могут быть проблемы.
Реализуем сервис семантического поиска на базе PostgreSQL с расширением PGVector. В статье: настройка БД через Docker, миграции Alembic, асинхронный слой на SQLAlchemy и API на FastAPI. Иллюстрация на обложке - нейрослоп для привлечения внимания
Издательская практика в настоящее время требует оценивать англоязычные книги, а в идеале — отлавливать бестселлеры — задолго до выхода, по первым черновикам. Занятие увлекательное, но порой рискованное. Поэтому в потенциальной переводной книге мы ищем сочетание «широкого контекста» и заключённой внутри него «необходимой новизны». Книга должна быть понятна и интересна широкой аудитории, но не перемалывать в очередной раз широко известные вещи, к тому же разобранные в блогах, а серьёзно облегчать повседневный труд и при этом предлагать ступеньку для роста.
Привет! Меня зовут Николай Олигеров, я работаю продуктовым аналитиком в Яндекс Путешествиях. В этой статье я расскажу, как мы применяли PSM (Propensity Score Matching) — статистический метод, который позволяет корректно сравнивать группы, уменьшая систематические различия между ними. Подробно разберу, как выровнять группы теста и контроля с помощью PSM, расскажу о типичных ошибках (например, утечке признаков), дам практические рекомендации по сбору и выбору фич для мэтчинга, а также покажу, как валидировать полученные результаты и оценить их достоверность.
Как запустить AI code review по git diff на своей машине через Ollama - без облака и API-ключей? Установка, конфиг и пример отчёта.
Замысел в том, чтобы написать цикл о 10 программистах, чьи имена не особо примелькались, но чьи заслуги невозможно переоценить. Начну я этот цикл с Эндрю Кучлинга (A.M. Kuchling). Я всегда знал его как автора официального туториала по регуляркам в питоне, пожалуй, лучшего по теме. Но масштаб этого человека куда больше.
ASR-системы в проде - это тяжёлые, специализированные решения под конкретные сценарии. Но что делать, если нужен универсальный инструмент, который умеет распознать длинное аудио, диаризовать спикеров, обработать пачку файлов и при этом не требует целого GPU кластера?
В этой серии статей я разбираю, как собрать «швейцарский ножик» для распознавания речи на базе Whisper: выбрать модель, победить галлюцинации, стабилизировать обработку длинных аудио и выжать максимум из обычной видеокарты.
Первая часть - про выбор ASR, оптимизацию инференса и практические грабли, с которыми сталкиваешься, когда пытаешься превратить open-source модель в рабочий инструмент.
Данный эксперимент проделан исключительно в формате развлечения выходного дня. Всё, что вы здесь увидите — результат чистого любопытства и желания покопаться в больших данных. Никакие приватные ключи не публикуются, только публичная информация об адресах.
Всем привет!
На связи София из команды применения больших языковых моделей ecom.tech. Сегодня хочу поделиться одной малоизвестной библиотекой, которую мы волей судьбы откопали на просторах github, попробовали использовать для поиска по нашей кодовой базе, и, о чудо! Это ощутимо помогло нам. Казалось бы, такой маленький шаг для человечества, но такой полезный для нашего проекта.
Когда я только начинал свой путь в автоматизации, мне отчаянно не хватало толкового и структурированного материала по паттернам проектирования именно для автотестов. Хороших статей про паттерны в целом — вагон, а вот с привязкой к тестированию — днём с огнём не сыщешь.
Паттерны — это та вещь, которая моментально выдает уровень культуры кода и понимание инженерных практик. Неудивительно, что на собеседованиях на позицию Automation QA любят покопаться в этой теме.
В этой статье я решил закрыть этот пробел. Вы найдете не только продуманную классификацию основных паттернов автоматизации, но и самый подробный, на мой взгляд, разбор каждого из них с примерами. А в конце поговорим про антипаттерны.
Добро пожаловать в обсуждение! Буду рад конструктивной критике и дополнениям.
Статья про то, как создавать клеточные лабиринты с помощью алгоритма Hunt&Kill + реализация на языке python.
История о том, как я создал свою соцсеть. И у меня даже получилось что-то. Видеохостинг, мессенджер, короткие ролики, стена и многое другое
