Kurgan-Telecom Ru | Информационные технологии

Здравствуйте, уважаемые читатели Хабра!

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

Эволюция GTD и систем ведения заметок постепенно приводит к следующему шагу: локальному AI-ассистенту, который работает не с абстрактной “памятью”, а с вашей собственной базой знаний о проектах, бизнесе, документах, задачах и решениях.

Профилирование Java‑приложений в production часто упирается не в отсутствие инструментов, а в их ограничения: CPU горит в одном месте, latency копится в другом, аллокации давят на GC, а lock contention вообще не виден в обычном CPU‑профиле.

В статье разбираем, как использовать async‑profiler для диагностики реальных Java‑сервисов: снимать CPU, allocation, wall‑clock и lock‑профили, читать flame graph и понимать, где именно приложение тратит ресурсы.

Когда говорят про RAG, его часто описывают как простой способ улучшить LLM‑систему: добавить поиск по внешним данным, найти релевантный контекст, передать его модели и получить более точный ответ.

На уровне идеи это действительно выглядит логично.

Но в реальной системе RAG — это не только способ обогатить ответ. Это отдельный операционный слой, который влияет на задержку, размер prompt, количество input tokens, стоимость запроса, качество ответа, SLA и требования к наблюдаемости системы.

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

Это не промышленный benchmark и не попытка получить универсальные цифры. Скорее серия контролируемых экспериментов: посмотреть на механику RAG pipeline и компромиссы, которые часто остаются за кадром, когда RAG описывают просто как «поиск + LLM».

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

Но рутины очень много: документы, коммуникации, задачи, сроки, база знаний, финансы, корпоративное обучение, тестирование знаний, исследование рынка, реклама, корпоративный сайт и т.д.

Как-то так случилось, что многие сервисы стали укрупняться и совмещать несколько инструментов в одном. Я задался вопросами: «Хорошо это ли плохо?» и «Насколько такие мегакомбайны будут востребованы через год, два, пять?» Порассуждал об этом в статье.

В своих прошлых статьях «Три пути к 4K» и «Нейросетевой апскейлинг дома» я рассказывал о выборе софта, базовых принципах нейросетевого апскейлинга и реставрации исходников уровня DVD и VHS. Но время идёт, навыки растут, и вот от простого (кусок дерева -> игрушка) мы переходим к сложному (игрушка -> коллекционная фигурка), а именно на территорию 720p–1080p исходников, Blu-ray и вебки.

И именно здесь для меня началось то, что я назвал «долиной отчаяния».

Вы берёте отличный исходник, выбираете крутую open-source модель, запускаете рендер… и всегда получаете что-то странное на выходе. Цвета поплыли, контраст упал, на градиентах неба появились какие-то искажённые линии, а ваш FPS в процессе ужасен. Кажется, что ПО сломано, а ИИ-модели взбесились и вместо «качественного апскейла» портят картинку.

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

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

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

В сегодняшней статье разберём, как на базе версии Apache Superset с поддержкой MCP и связки Foundation Models от Cloud.ru можно собрать рабочего AI-агента аналитика, который фразу «построй мне аналитику по продажам» за минуты превращает в полноценный дашборд с возможностью скейлинга в продакшене.

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

Рассказываю, как написал кроссплатформенную .NET-библиотеку для глобального перехвата клавиатуры и мыши. Под капотом: WH_KEYBOARD_LL на Windows, CGEventTap на macOS и polling через XQueryKeymap на Linux. Один интерфейс, три реализации, ноль внешних зависимостей.

Привет. В предыдущих статьях этого цикла мы разбирали, как Kubernetes-объекты читаются (первая — informer и кэш в controller-runtime) и записываются (вторая — Server-Side Apply, patch’и, managedFields). Сегодня — про их жизненный цикл.

Между kubectl apply и появлением объекта в etcd проходит целая цепочка: admission chain, мутирующие и валидирующие вебхуки, schema-валидация, встроенные плагины. Между kubectl delete и реальным исчезновением объекта может пройти от миллисекунд до часов — в зависимости от того, какие на нём финализаторы и какая стратегия каскадного удаления выбрана. Механизм при этом универсален для любого ресурса: Pod, Deployment, ваш CRD — жизненный цикл у всех один.

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

Как-то так получилось, что я NLP-инженер, который закончил Московский государственный лингвистический университет. Мне нравится ковыряться в коде и мозгах нейросетей, при этом я стараюсь не забывать, на каком фундаменте выросла трендовая ныне область под названием Natural Language Processing (NLP).

Поэтому захотелось собрать в одной статье беглый обзор истории компьютерной лингвистики — от первых теорий и грамматик Хомского до появления рекуррентных сетей и механизма внимания. Думаю, стоит остановиться ровно перед эпохой трансформеров, потому что это отдельная, глубокая и достойная собственного рассказа тема. 

Представьте, что у вас есть многослойный пайплайн обработки данных.

Ширина слоя — 5000 узлов. Количество слоёв — 60. Общее число узлов — 300 000.

Каждую секунду приходит 10 новых событий (изменений на входе). Наивный подход — пересчитать всё с нуля — будет перебирать все 300 000 узлов на каждое обновление. При 10 обновлениях в секунду это 3 млн вычислений узлов в секунду. А если ширина слоя 100 000 и слоёв 100? Получаем 10 млн узлов на пересчёт. Компьютер не справляется.

Финансовые системы предъявляют жёсткие требования к производительности.

Риск-департамент запрашивает переоценку портфеля из 200 000 опционов. Маржинальная система требует пересчитать все позиции клиентов после сильного движения рынка. Алгоритмический трейдер хочет оценить Greeks для тысяч потенциальных сделок за миллисекунды.

Стандартные подходы на .NET дают сбой по трём причинам.

Причина 1: Объектная модель

Каждый опцион становится отдельным объектом в куче. Виртуальные методы, ссылки, разрозненное расположение в памяти. Для 200 000 объектов — миллионы байтов, GC-паузы на сборку, промахи кэша процессора.

Причина 2: Позлементные вычисления

Вызов функции ценообразования в цикле — плохо. Процессор не может векторизовать код, потому что не видит всю картину целиком. SIMD-инструкции простаивают.

Причина 3: Аллокации в горячем пути

Каждый вызов new double[100000] для хранения промежуточных результатов — это давление на GC. В 24/7 сервисе такие аллокации накапливаются и вызывают непредсказуемые паузы.

Требования к решению

Допустим, вы делаете симуляцию города. Или RTS. Или RPG с открытым миром. И у вас в сцене одновременно находится 5, 10, а то и 20 тысяч живых существ. У каждого свои цели, приоритеты, эмоции, социальные связи.

Ваша архитектура AI начинает трещать по швам.

Классический подход — дать каждому NPC компонент с методом Update() — перестаёт работать где-то после 500–1000 объектов. Дальше начинаются проблемы:

Краткая справка об основных действующих лицах:

Lia Montelongo - модель, инструктор по фитнесу и йоге, преподаватель танцев, эксперт в вопросе персональных тренировок. Всемирно извесна по ролям в серии Mortal Kombat - Синдел в Mortal Kombat 3 (1995), Тани в Mortal Kombat 4 (1997) и Сарины в Mortal Kombat Mythologies: Sub-Zero (1997).

Уже многие написали и рассказали о таком полезном инструменте для организации своих заметок как Obsidian.

Если кто еще не знает, Obsidian - это бесплатное Electron-приложение, доступное на всех основных платформах, созданное Эрикой Сю и Шидом Ли уже в далёком 2020 году. В этой программе итересным UI-решением, позволившим привлечь внимание аудитории, стало визуализация графа заметок, как некой общей карты,мозга, базы знаний, состоящией из md-документов. Для меня на приктике эта фича оказалась самой бесполезной по сравнению с другими возможностями платформы. Встроенные плагины для ежедневных заметок, тэги, мощный поиск, шаблоны, работа с изображениями и многое другое + больше колличество стороннних плагинов на любой вкус и возможность при необходимости написать их самому. Вот, что мне пригодилось на самом деле. Я действительно за короткое время перенес все свои заметки из разрозненных источников в одно место и программа стала моим ежедненвным инструментом. Поэтому я стал ее использовать на нескольких устройствах.

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

В качестве решения я нашел opensource-программу syncthing. Она простая, быстро устанавливается, имеет довольно простой интерфейс. На своих устройствах я использую Ubuntu, поэтому данное ПО также отлично подходит.

Написание курсовой работы — это всегда трудоемкий процесс, требующий обработки огромных массивов информации: от подбора релевантных источников до структурирования глав и проверки уникальности текста. 

С развитием генеративного ИИ подход к обучению и подготовке студенческих работ кардинально изменился. Курсовая с помощью нейросети  — это не способ «обмануть систему», а мощный инструмент автоматизации рутины, структурирования мыслей и преодоления творческого кризиса.

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

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

Самое очевидное решение - писать данные в базу. Но такая таблица будет постоянно расти, занимать всё больше места, а выборка за прошлый период может отрабатывать довольно долго, особенно если требуется уместить целый год в 900 пикселей графика.

Когда-то и я наступил на эти грабли - когда база на MongoDB распухла так, что не влезла в 32-битный компьютер. Но это другая история.

При этом мало кому нужно точно знать, какая температура была на датчике 26 июля 2016 года в 14:33:15 - чаще достаточно просто усредненных значений. Вот как раз для подобного давным-давно люди придумали RRD - Round-robin database

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

ИИ помогает:

Звучит как мем про стартап, который пытается быть всем сразу. Я сам так думал примерно до середины разработки. Но в итоге мы это собрали, выкатили в App Store и Google Play, и теперь команды реально ведут в этом проекты. Расскажу, как оно устроено внутри, что было тупо, что неожиданно сработало, и где я до сих пор не уверен, что мы поступили правильно.

Сразу оговорюсь: это не «убийца Jira» и не «убийца Slack». Это попытка убрать одну конкретную боль, на которую я смотрел несколько лет.