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

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

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

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

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

Индексы – это «ускорители» доступа к данным в базах данных. Правильно выбранные индексы могут многократно ускорить запросы, что особенно критично в highload-системах с большими объёмами данных и большим числом запросов. Однако за ускорение чтения приходится платить усложнением записи и дополнительным расходом памяти. В этой статье мы подробно рассмотрим, как работают разные типы индексов в реляционных СУБД, как выбирать индекс под конкретный запрос, обсудим подводные камни (например, блоат, переиндексация, избыточные индексы) и затронем индексацию в NoSQL (MongoDB, Cassandra). Завершим чеклистом, который поможет выбрать оптимальный индекс под вашу задачу.

TL;DR

Больше года назад я переехал в Великобританию по визе таланта. Пост об этом был на Хабре. Эта виза разрешает работать, строить бизнес и учиться в Великобритании. Трудоустроенным в самой стране быть не обязательно, поэтому первое время я работал удаленно. Но жить в Лондоне и не пользоваться благами местного рынка труда было бы странно, дальше расскажу почему. Поэтому я оказался в поиске новых возможностей на незнакомой для себя территории.

Вы приходите на работу — а вам больше не дают задач. Коллеги внезапно перестают здороваться, а начальник при всех называет вас «бесполезным балластом». Вас нагружают невыполнимым объемом работы, а потом обвиняют в «профнепригодности». Было ли у вас такое? Может вы были свидетелем таких процессов?

Это не паранойя. Это система «выдавливания» сотрудников. По данным Роструда, каждый пятый работник сталкивается с давлением перед увольнением. Но лишь 3% обращаются в суд — остальные просто уходят «по собственному», теряя деньги и репутацию.

Но зачем так делать? Это просто выгодно. Увольнение «по статье» грозит им судами и проверками, а «сокращение» требует выплат. А вот если сотрудник как бы «сам ушел» — компания может сэкономить от 2 до 12 зарплат в каждом случае.

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

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

Я собрал самые популярные мифы о зумерах (поколении Z, родившихся примерно с 1997 по 2012 год) и проверил их на основе последних исследований.

Языковые модели сталкиваются с такими проблемами, как галлюцинации, устаревшие знания и непрозрачные, неотслеживаемые процессы рассуждений. RAG решает эти проблемы, интегрируя знания из внешних баз данных. В этом обзорном цикле статей подробно рассматривается развитие парадигм RAG, включая наивный RAG, продвинутый RAG и модульный RAG. В ней тщательно анализируется трёхкомпонентная основа RAG, включающая поиск, генерацию и дополнение. В статье объясняются передовые механизмы, что позволяет глубже понять их идею. Кроме того, в цикле представлены современные методы оценки и бенчмарки технологий RAG. В заключительной (5-й части) авторы описывают текущие проблемы и указывают перспективные направления для исследований и разработок.

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

Последние пару лет в свободное от Настоящей Работы время я в роли CTO/соло-бэкендера участвовал в создании Stry — фитнес-стартапа с подписной моделью. Теперь, когда наша команда официально объявила о прекращении дальнейшего развития проекта, пришло время порефлексировать и поделиться полученным опытом. В этой статье я в двух словах представлю продукт, детально опишу архитектуру проекта и расскажу о наших (моих?) основных технических успехах и неудачах. Поехали!

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

Сейчас среди Java/Kotlin команд распространено применение Чистой (ака Гексагональной, ака Луковой — Clean, Hexagonal, Onion) архитектуры для разработки бакэндов прикладных приложений (да и Android‑приложений тоже). Однако это семейство архитектур в контексте прикладной разработки зачастую не даёт никаких преимуществ, а только привносит лишние церемонии и тем самым замедляет её.

В этом посте я подробно разбираю, почему, на мой взгляд Чистая архитектура не является лучшим выбором по умолчанию для прикладных приложений, и кратко рассказываю об альтернативной архитектуре (спойлер: Промышленная функциональная архитектура), которую использую в качестве дефолтной последние 3 года и пока что доволен.

Но перед тем как перейти к Чистой архитектуре, сначала надо разобрать принцип инверсии зависимостей (Dependency Inversion Principle, DIP).

Привет Хабр! Меня зовут Татьяна Ошуркова, я разработчик и системный аналитик. Существует множество подходов и инструментов для работы с требованиями и их описания, в том числе текстовые спецификации, диаграммы и многое другое.

В этой статье я разберу использование простого, понятного, наглядного инструмента, который интегрируется с подходом Docs as code – Mindmap (Интеллект-карта). Этот метод позволяет организовывать требования в виде древовидной структуры, что делает процесс работы более гибким и наглядным.

Привет, Хабр!

Вы когда-нибудь писали аналитические запросы в MySQL и понимали, что встроенных функций вам не хватает? Хотите посчитать медиану зарплат? 99-й процентиль времени ответа запросов? Собрать JSON-массив прямо в базе данных?

В MySQL нет MEDIAN(), PERCENTILE_CONT() и нормального способа объединить данные в JSON. Всё приходится делать через костыли.

Решение? Написать собственную агрегатную функцию на C++, которая будет работать так же, как SUM() и AVG(), но делать то, что вам реально нужно.

Уже лет 20 существует миф (или не миф), что современный Highload-проект невозможен без кэшей. Они всегда нас выручали, когда не справлялись базы данных. Но с тех пор, как появились первые кэши, key-value баз данных и другие технологии, многое изменилось и традиционные СУБД значительно эволюционировали. И так ли теперь нужен кэш?
Мы протестировали самые известные кэш-сервисы и СУБД и попробовали выжать из них миллион запросов в секунду в разных условиях. Делимся с вами результатами в этой статье.
Привет, Хабр! Я Алексей Рыбак, предприниматель и основатель R&D-лаборатории DevHands, автор телеграм-канала про System Design и Highload. В прошлом — СТО и руководитель московского офиса Badoo. Работал во втором по размеру такси-сервисе «Везёт», который мы после продажи интегрировали с Яндекс.Такси. Сейчас наша компания разрабатывает образовательные программы по Highload и перформансу.

Привет! Меня зовут Олег Кретинин, и я разработчик в команде общих компонентов в Яндекс Еде. Сегодня я расскажу о том, как мы смогли успешно снять нагрузку с нашей базы данных, а также уменьшить её размер.

Помимо сервисов, написанных на C++, Go и Python, у нас есть монолит, он же «кора», на PHP, который всё ещё представляет огромную кодовую базу, хранит кучу логики и предоставляет данные по API для 120 сервисов.

После обновления фреймворка и версии PHP мы принялись за решение другой проблемы, которая всё чаще и чаще давала о себе знать. В тот период у нас возросло количество инцидентов, связанных с базой данных, и нам нужно было что‑то придумать, чтобы стабилизировать проект максимально быстро. Случалось, что всё сыпалось во время праздничных дней, когда количество заказов увеличивалось на 30–40%, или во время разовых массовых операций, например когда однажды в большую сеть ресторанов добавлялся бесплатный соус к каждой позиции меню.

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

Постарался создать простой чек лист для принятия решения о выделения в микросервис конкретного домена.

В мире разработки программного обеспечения существует множество "священных коров" — принципов и практик, которые принимаются как данность и редко подвергаются критическому анализу. Особенно показательна ситуация с принципами SOLID на русскоязычных ресурсах: достаточно открыть Хабр, чтобы найти 100500 статей о SOLID, и в каждой из них принципы интерпретируются по-разному.

Само существование такого количества "объяснительных" статей говорит о фундаментальной проблеме: если принципы требуют толкования, значит их названия не являются самодостаточными и интуитивно понятными. А если каждый разработчик понимает принципы по-своему, возникает вопрос — зачем вообще нужны принципы, которые не дают однозначного руководства к действию? Принципы SOLID, предложенные Робертом Мартином, давно стали одной из таких "священных коров". Однако пришло время честно признать: то, как мы используем SOLID сегодня, часто противоречит изначальным идеям и в целом иногда может приносить больше вреда, чем пользы. Зависит от контекста.

SRP не SRP

Самый яркий пример искажения первоначального замысла — это интерпретация принципа единственной ответственности (SRP).

Речь пойдет о тайной, сугубо анонимной организации, следы которой начал замечать еще в 2018-ом, работая в Яндексе. О целях и мотивах организации можно только догадываться: некоторые считают это кибер-луддизмом, другие — техно-анархизмом. Ясно одно: организация существует, ее члены уничтожают кодовые базы десятилетиями, и говорить об этом не принято.

Эта статья предназначена для разработчиков, архитекторов и технических лидеров, которые ищут способы оптимизации производительности и масштабируемости своих систем. Она поможет понять:

Когда стоит использовать более простые подходы (например, шардирование, репликацию, CQRS) вместо того, чтобы сразу переходить к микросервисам.

Какие trade-offs возникают при выборе каждого из паттернов или архитектурных решений.

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

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