Камни, песок и вода при планировании

Как часто вы сталкивались с тем, что команда напланировала много, а сделала сильно меньше? Какие у этого были причины? Обычно это «ой, ну там саппорта много было», «смежники еще задач принесли неожиданно», «сотрудник ушел в отпуск» (вот так сюрприз!) и всё в таком духе.

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

Что делать с этой аналогией?
Если объем банки N, то люди оценивают объем крупных проектов тоже в N и на это коммитятся. Но в банку точно не влезет столько крупных камней. Они же там не один к другому притерты. Есть куча разных промежутков: завязка на смежников, на заказчиков, на интеграцию, на переделку и допочинку (тоже сюрприз, что сразу нельзя без проблем с первого раза всё идеально сделать!). Поэтому крупных камней точно надо планировать меньше, чем N.

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

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

Пример
В моем личном примере у уже знакомой и бодрой команды я закладываю камней примерно на 65%, 25% песка и 10% воды. И это стабильно работает. Проверено уже не на одной команде, не в одной компании.

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

Как-то лет 6-7 назад смотрел доклад Скайенга, и они там подводили статистику, что у них камней получалось 35%, а остальное суета, саппорт, текучка (читай песок). Так что тут без индивидуального подхода я не знаю, как обойтись.

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

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

Speech and Language Processing by Dan Jurafsky and James H. Martin

A textbook that covers both classical and modern approaches by Daniel Jurafsky is an immortal classic that is constantly updated.

As a supplement, you can also look at the course LSA 311: Computational Lexical Semantics by the same author.

Table of contents:

Part I: Fundamental Algorithms
1: Introduction
2: Regular Expressions, Tokenization, Edit Distance
3: N-gram Language Models
4: Naive Bayes, Text Classification, and Sentiment
5: Logistic Regression
6: Vector Semantics and Embeddings
7: Neural Networks
8: RNNs and LSTMs
9: Transformers
10: Large Language Models
11: Masked Language Models
12: Model Alignment, Prompting, and In-Context Learning

Part II: NLP Applications
13: Machine Translation
14: Question Answering, Information Retrieval, and RAG
15: Chatbots and Dialogue Systems
16: Automatic Speech Recognition and Text-to-Speech

Part III: Annotating Linguistic Structure
17: Sequence Labeling for Parts of Speech and Named Entities
18: Context-Free Grammars and Constituency Parsing
19: Dependency Parsing
20: Information Extraction: Relations, Events, and Time
21: Semantic Role Labeling and Argument Structure
22: Lexicons for Sentiment, Affect, and Connotation
23: Coreference Resolution and Entity Linking
24: Discourse Coherence

Links:
- Site
- Book (wait, it'll load eventually)

Navigational hashtags: #armknowledgesharing #armbooks
General hashtags: #nlp #naturallanguageprocessing #llm #nn

Технический отчёт Qwen2.5

Создатели линейки языковых моделей Qwen2.5 представили технический отчёт. Вот что мы из него узнали.

Претрейн

На претрейне использовали датасет объёмом 18 триллионов токенов против 7 триллионов у Qwen 2. В частности, были данные, применявшиеся для обучения Qwen2.5-Math и Qwen2.5-Coder, что позволило улучшить результаты модели в вопросах, связанных с математикой и программированием. Также применяли синтетические данные, сгенерированные Qwen2. Scaling laws использовали для предсказания оптимальных гиперпараметров — например, для learning rate или вычисления размера батча.

Во время первой фазы претрейна длина контекста составляла 4096 токенов, а на второй и финальной — 32 768 токенов для всех моделей семейства, кроме Qwen2.5-Turbo. В её случае претрейн проходил в четыре этапа, начинаясь с 32 768 токенов и заканчивая 262 144 токенами. В каждой фазе претрейна Qwen2.5-Turbo максимального значения достигали только 40% данных, а остальные были короче. По словам авторов, это позволило модели плавно адаптироваться к новой длине контекста.

Благодаря стратегиям YaRN и Dual Chunk Attention удалось увеличить максимальную длину обрабатываемой на инференсе последовательности в четыре раза: до миллиона токенов у Qwen2.5-Turbo и до 131 072 токенов у других версий.

Алаймент

SFT-датасет состоял из более чем миллиона примеров. Длина выхода Qwen2.5 — 8192 токена, в то время как обычно она составляет менее 2000. Улучшения удалось добиться благодаря наборам данных для длинных ответов. Разработчики использовали back-translation, чтобы генерировать запросы на основе данных для предварительного обучения, ограничивали длину выхода и отфильтровывали низкокачественные пары с помощью Qwen2.

Для задач, связанных с математикой, использовали CoT-данные из Qwen2.5-Math. Кроме того, применяли rejection sampling вместе с размеченными данными и моделью награды для пошагового рассуждения. Что касается генерации кода, то здесь было несколько агентов и пары инструкций на примерно 40 языках программирования.

В части instruction following модели генерировали инструкции, проверочные коды и юнит-тесты для перекрёстной проверки. Это позволило LLM лучше следовать промптам. А благодаря внедрению цепочек рассуждений в ответы, Qwen2.5 стала лучше извлекать информацию из структурированных данных — например, таблиц.

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

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

На этапе DPO в качестве позитивных примеров использовали хорошие ответы с SFT. Те же, которые не прошли проверку на SFT, стали негативными примерами.

Для создания датасета задействовали как автоматические, так и ручные методы оценки. В итоге получился набор данных из 150 тысяч пар. Qwen2.5 обучалась на нём в течение одной эпохи с применением Online Merging Optimizer c learning rate 7 × 10⁻⁷.

Reward-модель тренировали на двух наборах данных: общедоступном и проприетарном, содержащем запросы со сложной структурой. Ответы генерировались с чекпоинтов Qwen-моделей, прошедших файнтюнинг разными методами (SFT, DPO, RL), и при разных температурах. В качестве алгоритма для онлайн RL использовали Group Relative Policy Optimization (GRPO). Набор запросов для обучения reward-модели был идентичен тому, что применялся на этапе обучения с подкреплением. Для каждого запроса отбирали по 8 ответов.

Душный NLP

#sql #interview