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

Однажды мой знакомый продакт спросил у меня: «А как вы используете нейросети в своей работе?». Я подумал и ответил: «А никак.» Надо сказать, что я не очень доверял нейросетям, воспринимая их скорее как продвинутый поисковый движок, нежели ассистент в ежедневных рутинных задачах. Мы немного поговорили о его опыте, и я в очередной раз призадумался: «А может пора?». Откровенно говоря сыграло ощущение того, что я упускаю что‑то полезное и интересное (как в своё время случилось с криптой) и, возможно, стоит попробовать.

Представьте, что ваши ИИ-агенты — это маркетинговый отдел, где Crew AI его мозг. Сейчас это один из самых популярных фреймворков, и не зря.

В микросервисной архитектуре есть множество зависимостей от других сервисов и инфраструктуры. В результате чего возникают проблемы, которые съедают большое количество сил и времени. Приходит, например, тестировщик с описанием воспроизведения бага — а чтобы его воспроизвести, надо долго готовить данные, а потом еще дольше поднимать фронт… После N-й итерации повторять такое вы, конечно, не будете это, мягко говоря, утомляет. Так интеграционные тесты становятся определенным оверхедом вместо того, чтобы упрощать жизнь разработчикам.

Меня зовут Степан Охорзин, я Senior Go Developer в «Лаборатории Касперского». У нас в компании уже много проектов/продуктов, которые пишутся на Go, а еще мы мигрируем на него с «плюсов» там, где это возможно. Ведь Go — отличный язык, когда речь идет о распределенных системах; в частности, мы разрабатываем на нем облачные решения.

Сегодня речь пойдет как раз об одном из таких инструментов — Kaspersky Security Center (KSC). Если коротко, то KSC — это консоль для удобного управления безопасностью на уровне предприятия, эдакий аналог ЦУПа для сложных IT-систем. Как вы уже догадались, KSC построен на микросервисной архитектуре — и именно в нем мы организовали интеграционное тестирование. Теперь наши тесты не просто не уходят в технический долг, а могут сами служить документацией. Мы же думаем только о бизнес-логике, все остальные вопросы берет на себя DI-контейнер.

В статье расскажу, как мы это реализовали, с деталями и примерами.

Автоматизация клиентской поддержки с помощью больших языковых моделей — перспективное направление, но без доработки они не всегда способны дать точные и релевантные ответы. Меня зовут Михаил Крюков, технический директор платформы Robovoice (SL Soft), и в этой статье я расскажу, как усиливать LLM с помощью RAG.

Используя реальный кейс, я расскажу о выборе LLM (сравнивали GigaChat MAX, GPT-4o, LLaMA 3.1 70B, YandexGPT 4 и Gemma 2 9b) и RAG (RagFlow, Dify и LangChain Custom + Vector database). Разберу ключевые сложности при интеграции — подготовку датасетов, настройку RAG, борьбу с «галлюцинациями» моделей, затрону вопросы экономики проекта и способов удешевления стоимости диалога. Статья будет полезна разработчикам и бизнесу, планирующим автоматизировать первую линию поддержки с помощью ИИ. Инфраструктура и железо в материале не освещены.

Недавно я столкнулся с задачей реализации аутентификации с использованием API Key в ASP.NET Core Web API. Хотя многие авторы рекомендуют использовать IAuthorizationFilter для этой цели, я обнаружил, что это не самый подходящий вариант. У меня есть более удачный подход, которым я хотел бы поделиться, включая примеры. Реализация была протестирована как в .NET 8, так и в .NET 9.

Всем привет!

Я — разработчик, сижу тут в своём углу, разрабатываю разработки. Хочется показать людям, что я сделал и какую пользу это может принести людям. Своего бота выложу только после вас! В рекламу вкладываться не хочу, да и зачем!

Нет ни одного поста, где разработчик скинул бы ссылку на своего бота и не получил бы дизлайк!

Предлагаю: если ты разработчик — пуляй в комментарии ссылку на своего бота и опиши, что он умеет,какова польза для общества и какие прикольные фишки ты использовал при его создании!

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

Создание документации — самая скучная часть в разработке игр. Так думают многие разработчики, а некоторые из них уверены, что «документация устаревает раньше, чем она написана». Отчасти они правы. В современной разработке игр жестким многостраничным документам нет места. Но это вовсе не значит, что документация бесполезна. Геймдизайн документ (диздок, GDD) как стандарт документации для создания игр эволюционировал вместе с индустрией.

Прогнозирование временных рядов играет ключевую роль в самых разных отраслях: от предсказания тенденций на фондовом рынке до оптимизации цепочек поставок и управления запасами.

Однако традиционные модели, такие как ARIMA, экспоненциальное сглаживание (ETS), Prophet, а также современные подходы глубокого обучения — например, LSTM и архитектуры на базе трансформеров — сталкиваются с рядом проблем.

Сегодня it-сообщество предлагает большое количество любопытных инструментов для создания RAG-систем. Среди них особенно выделяются два фреймворка —  LangChain и LlamaIndex. Как понять, какой из них подходит лучше для вашего проекта? Давайте разбираться вместе!

Как разработчик я ежедневно сталкиваюсь с большим количеством данных, которые нужны для принятия каких‑либо решений. Логи, конфиги, данные профилирования, аналитические выгрузки из БД и даже сведения о том, когда был написан данный код — это всё данные. Иногда бывает достаточно посмотреть глазами, и картина станет ясной. Но чем больше данных, тем меньше помогает «метод пристального взгляда», и тем нужнее какие‑то инструменты анализа.

Иногда можно собрать нужную информацию, просто скомбинировав несколько линуксовых команд пайпом (cat data.log | grep … | awk … | sort | uniq -c | sort -r | head), иногда пригодятся электронные таблицы, иногда проще написать небольшую программку для анализа данных. Но когда я освоился с языком R и его экосистемой, то всё это стало ненужным.

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

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

В этой статье вы научитесь всему, что нужно знать о метриках оценки LLM, включая примеры кода. Мы рассмотрим следующие вопросы:

Что такое метрики оценки LLM, как их можно использовать для оценки систем LLM, а также распространенные ошибки и что делает метрики отличными.

Различные методы вычисления метрик оценки LLM и почему подход LLM-as-a-judge («LLM как судья») является наиболее эффективным.

Как реализовать и выбрать подходящий набор метрик оценки LLM с использованием библиотеки DeepEval (GitHub: DeepEval).

Я давно хотел реализовать этот проект. Цель заключалась в создании маски, покрытой светодиодами и выполненной из печатных плат. Я использовал 16 отдельных матричных панелей с общим количеством 2960 адресных светодиодов, которые позволяют отображать на маске всё, что только захочется.

Это довольно трудоёмкая работа, конструкция хрупкая и нагревается при использовании. Однако, если вы готовы к вызову, попробуйте. Этот проект подходит только для опытных пользователей.

Делаем виртуального помощника с помощью промпт‑инжиниринга

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

Что вас ждёт в статье:

Часть 1: Подходы промпт‑инжиниринга для принятия решений:
– Input‑Output (IO)
– Chain of Thought (CoT)
– Tree‑of‑Thought Prompting (ToT)
Часть 2: Как заставить нейросеть принимать конкретные решения
Часть 3: Ограничения при использовании LLM

Всем привет! На связи команда ad-hoc аналитики X5 Tech. Если вы уже знакомы с нашими статьями, то наверняка знаете, что нашей ключевой темой является А/Б тестирование. Важной составляющей А/Б теста является дизайн: для успешного проведения эксперимента необходимо оценить размер пилотной и контрольной групп, зафиксировав предварительно ожидаемый эффект. Но возникает вопрос: как убедиться в обоснованности гипотезы и рассчитать ожидаемые эффекты от инициативы?

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

Разработчики языка Go подбросили программистам занятную дилемму - в виде фиксированного размера буфера у каналов (тех что используются для передачи сообщений между потоками - точнее "go-рутинами" приложения). На днях на ревью увидел у коллеги код в духе:

- хотим оповещать "подписчиков" об изменениях в БД, асинхронно
- используем для этого канал с буфером какой-то вместимости (например, 50)
- когда вызывается коллбэк от БД, мы создаём информационное сообщение и пытаемся затолкать его в канал
- если канал оказался заполнен, просто пишем ошибку в лог и спокойно выходим из коллбэка ничего не делая (запись в базу проходит, но оповещения не будет)

Стоит ли так делать? А какие ещё варианты? Был бы канал безразмерным (как в erlang или некоторые из очередей в java) - программист и не задумался бы (может семантически лучше чтобы отправка в канал удавалась всегда - как запись в массив или мэпу) - но в Go нам предоставили "более полный" контроль над ситуацией, только не сказали что с ним делать :-)

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