Natural Language Processing *

Недавно в X (Твиттер) один пользователь задался вопросом - сколько денег OpenAI потеряла из-за того, что люди говорят своим LLM спасибо и пожалуйста (не дословно). Сэм Альтман ответил на это: "tens of millions of dollars well spent--you never know", что можно перевести как: "десятки миллионов долларов были потрачены не зря, никогда не знаешь [на чем выиграешь].

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

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

В завершающей части руководства от Google мы фокусируемся на лучших практиках и тонкостях мастерства промпт-инжиниринга. Изучаем все аспекты работы с БЯМ: от контроля температуры и Top-K/Top-P параметров до применения таких техник как промптинг с отступлением, цепочки рассуждений и ReAct. Разбираем преимущества использования структурированных форматов и переменных в промптах. Завершается статья практическими советами по документированию, тестированию и оптимизации промптов. Это не просто руководство — это комплексная система знаний, позволяющая максимально эффективно использовать возможности больших языковых моделей.

Одна из актуальных задач для компаний в сфере ИИ - это поиск и генерация ответов по внутренней документации. На первый взгляд кажется, что решение простое: скормить документы большой языковой модели (LLM) и получать ответы. На практике же технические решения оказываются далеко не такими эффективными и качественными, как хотелось бы. Сейчас для работы с локальными документами доступны два основных подхода - RAG (Retrieval-Augmented Generation) и дообучение модели (fine-tuning). Оба подхода имеют свои преимущества и ограничения. В статье рассмотрим их как с теоретической, так и с практической точки зрения.

Для обработки Common Crawl на терабайтных объёмах широко используются архитектуры обработки данных, построенные на фреймворках вроде Apache Spark. Благодаря распределённой обработке данных и структурированному стримингу Spark позволяет разработчикам создавать масштабируемые пайплайны, применять логику фильтрации и формировать итоговые очищенные корпусы для обучения. Эта статья перевод моей статьи на medium.com, я хотел рассматреть, как на практике формируются обучающие наборы из Common Crawl (например, в проектах C4, CCNet, OSCAR, GPT-3, BLOOM, Falcon и др.), а затем показать пример Spark Streaming-приложения, который я написал и опубликовал в GitHub. Мы также приводим пример подхода, реализованного в DeepSeek, для фильтрации математического контента — узкоспециализированная задача, которая способна дать существенный прирост в качестве моделей.

Представляю вашему вниманию перевод второй части статьи "Prompt Engineering" (Промпт-инжиниринг) авторства Lee Boonstra - Software Engineer Tech Lead, Office of the CTO в Google. Эта публикация продолжает цикл переводов, посвященных методам эффективного взаимодействия с большими языковыми моделями.

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

Оригинальная публикация фокусируется в основном на моделях Gemini и сервисе Vertex AI от Google, однако описанные техники и рекомендации универсальны и применимы практически ко всем современным большим языковым моделям (GPT, Claude, Llama и др.).

Представляю вашему вниманию перевод статьи "Prompt Engineering" (Промпт-инжиниринг) авторства Lee Boonstra - Software Engineer Tech Lead, Office of the CTO в Google.

Это первая часть из цикла трех статей, где мы разберем основы промпт-инжиниринга и базовые техники взаимодействия с большими языковыми моделями. Вы узнаете, как настраивать параметры моделей, использовать различные типы промптов и получать предсказуемые, релевантные результаты. Несмотря на фокус оригинала на Gemini/Vertex AI, описанные принципы применимы ко всем современным моделям ИИ.

Современная разработка ПО — это плавильный котел языков: Java, C#, JS/TS, Go, Kotlin… список можно продолжать. Но когда дело доходит до оценки ИИ-агентов, способных помогать в написании и исправлении кода, мы часто упираемся в ограничения. Популярный бенчмарк SWE-bench, например, долгое время поддерживал только Python.

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

В статье расскажем:

• Что такое SWE-Bench
• Какие сложности возникают при сборе данных и тестировании
• Наш опыт: какие языки поддерживает SWE-bench
• Ручная перепроверка, или SWE-bench Verified
• Сравниваем SWE-bench с другими бенчмарками для разработки ПО
• Ценообразование SWE-bench: как формируется стоимость одного датапойнта

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

В этой статье вы найдёте всё, что нужно знать об этом стандарте: как устроены его 10 полей, какую роль он играет в задачах диаризации и распознавания речи, и почему его до сих пор активно используют лидеры индустрии — такие как pyannote.audio, NVIDIA NeMo, DScore и другие.

• Сначала в GPT 4.5 провёл продуктовые исследования и сформулировал требования.
• Попросил превратить это в архитектурный план.
• Отревьюил, поправил тупые ошибки.
• Затем этот план (как метапромпт) скормил Sonnet в VS Code через плагин Cline. Попросил сначала создать общую структуру, шаблонные имплементации, документацию, спецификации API (protobuf для gRPC, REST API).
• Архитектурно сразу заложил микросервисы. Sonnet для каждого сервиса подобрал и обосновал оптимальную базу данных (где-то Postgres, где-то ClickHouse и т.д.).
• Сгенерировал SDK для взаимодействия, примеры использования. Сразу заложил observability: централизованные логи, метрики Prometheus, трейсинг Jaeger/Tempo, дашборды для Grafana.
• Потом итерационно генерировал код: сначала тесты (End-to-end, BDD), потом имплементацию под эти тесты.
• Написал манифесты для Kubernetes и Docker Compose для локального запуска.
• Сгенерировал даже скрипты для тестов REST API через curl и gRPC через gRPCurl.

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

- граф связей между героями
- хронологию событий
- карту мест действия

Выпущенные 5 апреля Llama Scout (17 миллиардов активных параметров, 16 экспертов, 109 миллиардов параметров суммарно) и Llama Maverick (17 миллиардов активных параметров, 128 экспертов, 400 миллиардов параметров суммарно) выглядят крайне разочаровывающе. Они разочаровывают настолько, что пользователи даже предполагают причиной неправильную конфигурацию; они задаются вопросами и спорят о том, насколько сильно манипулировали бенчмарками.

Это был самая негативная реакция на выпуск модели, совершенно противоположная реакции на Gemini 2.5 Pro. Я уже видел столь же глубоко разочаровывающие и запутывающие релизы, но они не были американскими и выпускались лабораториями, бенчмарки и заявления которых, как мы уже поняли, не стоит брать в расчёт при оценке возможностей моделей.

После этого релиза я помещаю Meta* в эту категорию ИИ-лабораторий, заявлениям которых не следует доверять, которые не соответствуют нормам отрасли и которые точно не находятся на переднем рубеже исследований. Пока не доказано обратное, я исключу её из категории, в которой находятся OpenAI, Anthropic, Google, xAI и DeepSeek.

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

Дальше будет небольшая выжимка и перевод с помощью ChatGPT.

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

Что такое Промпт-инжиниринг?

Большая Языковая Модель(БЯМ) работает, предсказывая наиболее вероятную последовательность слов (или «токенов»), следующую за вашим вводом. Когда вы пишете запрос, вы, по сути, задаете начальную точку и направление для этого процесса предсказания. Промпт-инжиниринг включает в себя:

Это алтернативная концовка моего мини-хабра-сериала с переводом нашумевшего Sci-Fi рассказа ai-2027.com. Он написан топовыми ИИ-экспертами, ссылается на кучу данных, имеет две концовки (!) и сейчас все о нём говорят.

Эта концовка проиграла на голосовании в конце второй части

В предыдущих сериях

...три огромных дата-центра, заполненных копиями Agent-2, работают днем и ночью...

...он предпочитает работать в рамках существующего политического истеблишмента, постепенно укрепляя свою власть...

...они просят Пентагон разработать план кинетических атак на китайские дата-центры...

...быть идеально честным все время — это не то,

OpenAI запустила свою Академию — десятки видеолекций. Полезно, но далеко не все. Если вы разработчик или аналитик, которому нужны технические детали и практические руководства по API, моделям и их оптимизации, смотреть всё подряд — не вариант.

Я изучил доступные материалы и сделал выжимку из только технических материалов. Этот гайд проведет по 10 ключевым лекциям вышедшим на сегодня, которые помогут разобраться в Function Calling, RAG, Fine-tuning, Evals и других важных темах. Мы не будем здесь касаться лекций для новичков, материалов про Sora или использования ИИ в образовании — только хардкор, только для тех, кто строит и анализирует LLM.

Привет, Хабр! Меня зовут Саприн Семён. Я занимаюсь анализом данных и машинным обучением в компании ПГК Диджитал. Сегодня мы начинаем серию статей, в которой я расскажу о том, как мы с командой разрабатывали ИИ-помощника, а также приведу практические кейсы по улучшению точности ответов с минимальными затратами памяти графических процессоров. 

Как вы уже могли догадаться, наш ИИ-помощник разработан на основе RAG (Retrieval-Augmented Generation) системы. Хотя принцип работы RAG многим уже знаком и не вызывает того самого «вау», я всё же кратко напомню, как эта система работает, почему она так популярна и почему её ответам можно доверять.

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

Это вторая часть моего мини-хабра-сериала с переводом нашумевшего Sci-Fi рассказа ai-2027.com. Он написан топовыми ИИ-экспертами, опирается на кучу данных, имеет две концовки (!) и сейчас все о нём говорят.

В предыдущей серии:

...модель была «согласована» (aligned), так что она откажется выполнять вредоносные запросы...

...исследователи пытаются выявить случаи, когда модели, похоже, отклоняются от Спецификации...

...Ранним утром агент мониторинга трафика Agent-1 обнаруживает аномал

Эта статья на прошлой неделе взорвала твиттер и русскоязычный ИИ-телеграм. Большинство серьезных ии-блогеров написали по ней обзоры. Почему? Да просто это никакая не статья, а полноценный sci-fi рассказ про ближайшее будущее, только с кучей референсов на реальные данные.

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

А еще тут 2 концовки (!)

Сегодня мы продолжим изучать руководства по разработке LLM. А 23 апреля на онлайн-встрече расскажем, почему создание платформы для инференса LLM с нуля — далеко не всегда оптимальный выбор, и объясним, как MWS GPT может значительно упростить и ускорить работу с большими языковыми моделями. Подключайтесь, регистрация открыта по ссылке.

Привет, Habr! Наша команда LLM-разработки подготовила статью с анализом low-code редакторов для разработки пайплайнов на базе LLM-моделей. Тема сравнения редакторов назревала давно, так как мы активно используем данные инструменты в своей работе и зачастую сталкиваемся с различными ограничениями решений. Данная статья будет полезна командам, которые только выбирают среду разработки пайплайнов для своих LLM-приложений и ИИ-агентов, а также тем, кто ищет лучший редактор для решения своих задач.

Сегодня поговорим о теме, которая вызывает живой интерес у многих разработчиков и энтузиастов ИИ — интеграции больших языковых моделей вроде DeepSeek или ChatGPT с собственной базой знаний.

В этой статье я подробно расскажу, как работают векторные базы данных, зачем они нужны и какую роль играют в построении эффективной связки между вашей внутренней информацией и мощью современных LLM. Если вы хотите научиться «обучать» ИИ на своих данных — добро пожаловать!