Что происходит при добавлении объекта в векторную базу данных
(продолжение предыдущего поста)
Со стороны это выглядит как один вызов API, но на самом деле процесс гораздо сложнее, чем может показаться.
При добавлении объекта параллельно запускаются четыре процесса:
Индексация свойств
Все свойства вашего объекта индексируются для быстрого фильтрации и поиска по ключевым словам.
Генерация векторов
Если вы не предоставили векторы, внешние модели (Cohere, OpenAI, JinaAI и др.) создают эмбеддинги на основе ваших данных.
Индексация векторов
Эти векторы организуются в специализированные структуры данных (например, HNSW) для эффективного поиска по схожести.
Хранение объекта
Полный объект вместе с его векторным представлением сохраняется для последующего извлечения.
Каждый из этих процессов имеет собственное время обработки и задержки ввода‑вывода. Одна только индексация векторов предполагает организацию эмбеддингов таким образом, чтобы данные можно было эффективно извлекать. А для генерации эмбеддингов могут потребоваться вызовы внешних API, что добавляет сетевые задержки.
Понимание того, как работают векторные базы данных, поможет вам эффективнее оптимизировать их производительность. Если ваша модель генерации эмбеддингов работает медленно, она становится узким местом. Если векторный индекс настроен неправильно, ухудшается скорость поиска. Если индексация свойств перегружена, возникают проблемы с фильтрацией
(продолжение предыдущего поста)
Со стороны это выглядит как один вызов API, но на самом деле процесс гораздо сложнее, чем может показаться.
При добавлении объекта параллельно запускаются четыре процесса:
Индексация свойств
Все свойства вашего объекта индексируются для быстрого фильтрации и поиска по ключевым словам.
Генерация векторов
Если вы не предоставили векторы, внешние модели (Cohere, OpenAI, JinaAI и др.) создают эмбеддинги на основе ваших данных.
Индексация векторов
Эти векторы организуются в специализированные структуры данных (например, HNSW) для эффективного поиска по схожести.
Хранение объекта
Полный объект вместе с его векторным представлением сохраняется для последующего извлечения.
Каждый из этих процессов имеет собственное время обработки и задержки ввода‑вывода. Одна только индексация векторов предполагает организацию эмбеддингов таким образом, чтобы данные можно было эффективно извлекать. А для генерации эмбеддингов могут потребоваться вызовы внешних API, что добавляет сетевые задержки.
Понимание того, как работают векторные базы данных, поможет вам эффективнее оптимизировать их производительность. Если ваша модель генерации эмбеддингов работает медленно, она становится узким местом. Если векторный индекс настроен неправильно, ухудшается скорость поиска. Если индексация свойств перегружена, возникают проблемы с фильтрацией
Telegram
METANIT.COM
Что происходит при добавлении объекта в векторную базу данных
(продолжение в следующем посте)
(продолжение в следующем посте)
👍4👾3❤2🔥2
Обратное давление и архитектура
(описание к предыдущему посту)
Обратное давление — ключевой элемент корректно работающей инфраструктуры.
Когда базы данных, очереди сообщений, пулы соединений или другие системы оказываются перегружены, как они справляются с нагрузкой?
Некоторые программы реагируют на перегрузку тем, что позволяют своим ресурсам исчерпаться, в результате чего система аварийно завершается (например, из‑за нехватки памяти — OOM). С точки зрения реализации такое поведение просто, но оно вызывает каскадные сбои, которые могут привести к полному выходу системы из строя и даже к потере данных. Это недопустимо!
Более удачный подход: каждый компонент оказывает обратное давление на своих клиентов. Обратное давление — это принцип, согласно которому программный сервис, обнаружив, что он достиг предела возможностей или приближается к нему (максимальное число соединений, полное использование доступных буферов памяти и т. п.), сообщает об этом клиентам — либо посредством явных сообщений, либо путём отказа в соединении. Иными словами, сервис защищает собственное состояние ценой снижения качества обслуживания или отказа в обслуживании некоторых клиентов.
Если серверные компоненты спроектированы с учётом сигналов обратного давления, неожиданные скачки нагрузки приводят лишь к снижению производительности, а не к полному отключению всей системы.
(описание к предыдущему посту)
Обратное давление — ключевой элемент корректно работающей инфраструктуры.
Когда базы данных, очереди сообщений, пулы соединений или другие системы оказываются перегружены, как они справляются с нагрузкой?
Некоторые программы реагируют на перегрузку тем, что позволяют своим ресурсам исчерпаться, в результате чего система аварийно завершается (например, из‑за нехватки памяти — OOM). С точки зрения реализации такое поведение просто, но оно вызывает каскадные сбои, которые могут привести к полному выходу системы из строя и даже к потере данных. Это недопустимо!
Более удачный подход: каждый компонент оказывает обратное давление на своих клиентов. Обратное давление — это принцип, согласно которому программный сервис, обнаружив, что он достиг предела возможностей или приближается к нему (максимальное число соединений, полное использование доступных буферов памяти и т. п.), сообщает об этом клиентам — либо посредством явных сообщений, либо путём отказа в соединении. Иными словами, сервис защищает собственное состояние ценой снижения качества обслуживания или отказа в обслуживании некоторых клиентов.
Если серверные компоненты спроектированы с учётом сигналов обратного давления, неожиданные скачки нагрузки приводят лишь к снижению производительности, а не к полному отключению всей системы.
Telegram
METANIT.COM
Обратное давление и архитектура
(описание в следующем посте)
(описание в следующем посте)
👍8👏8❤3❤🔥1🤣1
RuStore с 1 февраля 2026 года отключает монетизацию приложений для физлиц и самозанятых через инструменты RuStore. Чтобы продолжать публиковать планые приложения, необходимо зарегистрировать ИП или юрлицо в ФНС, затем создать новый аккаунт и заново подключить монетизацию
В качестве альтернативы можно продолжить работу в RuStore в текущем статусе, но без монетизации через платёжные инструменты платформы. В этом случае можно перевести платные приложения в бесплатные и продолжать публиковать и обновлять приложения без ограничений, либо при необходимости использовать альтернативные инструменты монетизации
Если же не успеть внести изменения до 1 февраля 2026 года, то платные приложения будут автоматически скрыты c витрины RuStore, а платёжные SDK — BillingClient SDK и Pay SDK — перестанут работать, списания по активным подпискам будут остановлены
https://www.rustore.ru/help/developers/monetization/disable-monetization-selfemployed
В качестве альтернативы можно продолжить работу в RuStore в текущем статусе, но без монетизации через платёжные инструменты платформы. В этом случае можно перевести платные приложения в бесплатные и продолжать публиковать и обновлять приложения без ограничений, либо при необходимости использовать альтернативные инструменты монетизации
Если же не успеть внести изменения до 1 февраля 2026 года, то платные приложения будут автоматически скрыты c витрины RuStore, а платёжные SDK — BillingClient SDK и Pay SDK — перестанут работать, списания по активным подпискам будут остановлены
https://www.rustore.ru/help/developers/monetization/disable-monetization-selfemployed
🤡46🤣8🤔4🤷♂1👍1🤬1😭1
Сравнительный анализ технологий обмена данными между клиентом и сервером: Short Polling, Long Polling, SSE (Server‑Sent Events) и WebSocket.
(продолжение в следующем посте)
(продолжение в следующем посте)
👍2🔥1
Сравнительный анализ технологий обмена данными между клиентом и сервером: Short Polling, Long Polling, SSE (Server‑Sent Events) и WebSocket.
(продолжение предыдущего поста)
## 1. Short Polling (короткий опрос)
Принцип работы:
Клиент регулярно (с фиксированным интервалом) отправляет HTTP‑запросы на сервер: *«Есть ли новые данные?»*
Сервер отвечает сразу, даже если данных нет.
Схема:
Плюсы:
- Простота реализации.
- Работает на любом HTTP‑сервере.
- Совместим со всеми браузерами.
Минусы:
- Высокий overhead: много пустых ответов.
- Задержка между обновлениями = интервал опроса.
- Нагрузка на сеть и сервер из‑за частых запросов.
Когда использовать:
Редкие обновления, простота важнее эффективности.
## 2. Long Polling (длинный опрос)
Принцип работы:
Клиент отправляет запрос. Сервер держит соединение открытым и отвечает только когда есть данные (или по таймауту). После ответа клиент сразу отправляет новый запрос.
Схема:
Плюсы:
- Меньше пустых ответов, чем в Short Polling.
- Почти мгновенная доставка данных (как только они появляются).
- Простая реализация.
Минусы:
- Соединение постоянно переподключается.
- Высокая задержка при потерях пакетов (нужно ждать таймаут).
- Нагрузка на сервер из‑за долгих соединений.
Когда использовать:
Средние требования к скорости, устаревшие системы без WebSocket.
## 3. SSE (Server‑Sent Events)
Принцип работы:
Однонаправленный канал: сервер самостоятельно отправляет данные клиенту через постоянное HTTP‑соединение. Клиент слушает события.
Схема:
Плюсы:
- Автоматическая доставка данных от сервера.
- Низкое потребление ресурсов (одно соединение).
- Встроенная поддержка перезапуска при обрыве.
- Простой API в браузерах (
Минусы:
- Только сервер → клиент (однонаправленный).
- Ограниченная поддержка в старых браузерах.
- Может конфликтовать с прокси/файрволами.
Когда использовать:
Новостные ленты, уведомления, мониторинг (где нужен только push от сервера).
## 4. WebSocket
Принцип работы:
Двунаправленный полнодуплексный канал. После рукопожатия (HTTP → WebSocket) клиент и сервер могут одновременно отправлять данные.
Схема:
Плюсы:
- Мгновенный двусторонний обмен.
- Минимальный overhead (нет HTTP‑заголовков).
- Подходит для чатов, игр, коллаборативных приложений.
Минусы:
- Сложнее реализовать (нужен WebSocket‑сервер).
- Требует поддержки на стороне сервера и клиента.
- Может блокироваться корпоративными сетями.
Когда использовать:
Интерактивные приложения (чаты, онлайн‑игры, трейдинг).
(продолжение предыдущего поста)
## 1. Short Polling (короткий опрос)
Принцип работы:
Клиент регулярно (с фиксированным интервалом) отправляет HTTP‑запросы на сервер: *«Есть ли новые данные?»*
Сервер отвечает сразу, даже если данных нет.
Схема:
Клиент → запрос → Сервер
Клиент ← ответ (пустой/с данными) ← Сервер
( пауза )
Клиент → запрос → Сервер
...
Плюсы:
- Простота реализации.
- Работает на любом HTTP‑сервере.
- Совместим со всеми браузерами.
Минусы:
- Высокий overhead: много пустых ответов.
- Задержка между обновлениями = интервал опроса.
- Нагрузка на сеть и сервер из‑за частых запросов.
Когда использовать:
Редкие обновления, простота важнее эффективности.
## 2. Long Polling (длинный опрос)
Принцип работы:
Клиент отправляет запрос. Сервер держит соединение открытым и отвечает только когда есть данные (или по таймауту). После ответа клиент сразу отправляет новый запрос.
Схема:
Клиент → запрос → Сервер
(сервер ждёт данных)
Клиент ← ответ (с данными) ← Сервер
Клиент → запрос → Сервер
...
Плюсы:
- Меньше пустых ответов, чем в Short Polling.
- Почти мгновенная доставка данных (как только они появляются).
- Простая реализация.
Минусы:
- Соединение постоянно переподключается.
- Высокая задержка при потерях пакетов (нужно ждать таймаут).
- Нагрузка на сервер из‑за долгих соединений.
Когда использовать:
Средние требования к скорости, устаревшие системы без WebSocket.
## 3. SSE (Server‑Sent Events)
Принцип работы:
Однонаправленный канал: сервер самостоятельно отправляет данные клиенту через постоянное HTTP‑соединение. Клиент слушает события.
Схема:
Клиент → открывает поток → Сервер
(соединение держится)
Сервер → событие → Клиент
Сервер → событие → Клиент
...
Плюсы:
- Автоматическая доставка данных от сервера.
- Низкое потребление ресурсов (одно соединение).
- Встроенная поддержка перезапуска при обрыве.
- Простой API в браузерах (
EventSource).Минусы:
- Только сервер → клиент (однонаправленный).
- Ограниченная поддержка в старых браузерах.
- Может конфликтовать с прокси/файрволами.
Когда использовать:
Новостные ленты, уведомления, мониторинг (где нужен только push от сервера).
## 4. WebSocket
Принцип работы:
Двунаправленный полнодуплексный канал. После рукопожатия (HTTP → WebSocket) клиент и сервер могут одновременно отправлять данные.
Схема:
Клиент → HTTP-рукопожатие → Сервер
(переход на WebSocket)
Клиент ↔️ данные ↔️ Сервер
(двусторонний обмен в реальном времени)
Плюсы:
- Мгновенный двусторонний обмен.
- Минимальный overhead (нет HTTP‑заголовков).
- Подходит для чатов, игр, коллаборативных приложений.
Минусы:
- Сложнее реализовать (нужен WebSocket‑сервер).
- Требует поддержки на стороне сервера и клиента.
- Может блокироваться корпоративными сетями.
Когда использовать:
Интерактивные приложения (чаты, онлайн‑игры, трейдинг).
Telegram
METANIT.COM
Сравнительный анализ технологий обмена данными между клиентом и сервером: Short Polling, Long Polling, SSE (Server‑Sent Events) и WebSocket.
(продолжение в следующем посте)
(продолжение в следующем посте)
🔥10❤1👍1🥰1👏1
CORS (Cross-Origin Resource Sharing)
(продолжение предыдущего поста)
CORS (Cross-Origin Resource Sharing) — это HTTP-механизм, который позволяет запрашивать данные с одного URL на другой URL, обходя ограничения политики одинакового происхождения (Same-Origin Policy).
CORS обеспечивает баланс между безопасностью и возможностью взаимодействия между ресурсами разных источников, предотвращая несанкционированный доступ к данным.
Как работает CORS:
1. Клиент (a.com) хочет отправить запрос (например, POST /products) на сервер с другим источником (b.com).
2. Браузер обнаруживает, что источник отличается, и перед отправкой основного запроса отправляет предварительный (preflight) запрос с методом OPTIONS на сервер (b.com). Это делается для проверки, разрешены ли такие запросы.
3. В preflight-запросе браузер указывает:
- метод основного запроса (например, POST);
- заголовки, которые будут использоваться.
4. Сервер (b.com) отвечает на preflight-запрос кодом 204 No Content и включает специальные заголовки:
- Access-Control-Allow-Origin: указывает, какой источник (origin) может отправлять запросы (в примере — a.com);
- Access-Control-Allow-Methods: перечисляет разрешённые HTTP-методы (в примере — POST).
5. Если сервер разрешает запрос, браузер отправляет основной запрос (POST /products).
6. Сервер обрабатывает основной запрос и возвращает ответ, если всё корректно.
Ключевые моменты:
- CORS работает как на стороне браузера, так и на стороне сервера.
- Без правильной настройки CORS браузер блокирует запросы к ресурсам с других доменов.
- Заголовки Access-Control-Allow-Origin и Access-Control-Allow-Methods критически важны для разрешения запросов.
- Предварительные (OPTIONS) запросы помогают убедиться, что основной запрос безопасен.
(продолжение предыдущего поста)
CORS (Cross-Origin Resource Sharing) — это HTTP-механизм, который позволяет запрашивать данные с одного URL на другой URL, обходя ограничения политики одинакового происхождения (Same-Origin Policy).
CORS обеспечивает баланс между безопасностью и возможностью взаимодействия между ресурсами разных источников, предотвращая несанкционированный доступ к данным.
Как работает CORS:
1. Клиент (a.com) хочет отправить запрос (например, POST /products) на сервер с другим источником (b.com).
2. Браузер обнаруживает, что источник отличается, и перед отправкой основного запроса отправляет предварительный (preflight) запрос с методом OPTIONS на сервер (b.com). Это делается для проверки, разрешены ли такие запросы.
3. В preflight-запросе браузер указывает:
- метод основного запроса (например, POST);
- заголовки, которые будут использоваться.
4. Сервер (b.com) отвечает на preflight-запрос кодом 204 No Content и включает специальные заголовки:
- Access-Control-Allow-Origin: указывает, какой источник (origin) может отправлять запросы (в примере — a.com);
- Access-Control-Allow-Methods: перечисляет разрешённые HTTP-методы (в примере — POST).
5. Если сервер разрешает запрос, браузер отправляет основной запрос (POST /products).
6. Сервер обрабатывает основной запрос и возвращает ответ, если всё корректно.
Ключевые моменты:
- CORS работает как на стороне браузера, так и на стороне сервера.
- Без правильной настройки CORS браузер блокирует запросы к ресурсам с других доменов.
- Заголовки Access-Control-Allow-Origin и Access-Control-Allow-Methods критически важны для разрешения запросов.
- Предварительные (OPTIONS) запросы помогают убедиться, что основной запрос безопасен.
Telegram
METANIT.COM
CORS (Cross-Origin Resource Sharing)
(продолжение в следующем посте)
(продолжение в следующем посте)
❤7👍4🔥2❤🔥1
Компания Hynix - один из крупнейших производителей чипов памяти прогнозирует, что проблема на рынке памяти не будет решена до 2028 года.
Hynix отмечает, что запасы памяти сокращаются, а заметный рост поставок памяти DRAM, который сможет избавить рынок от дефицита, ожидается лишь в 2028 году, поскольку для наращивания объёмов производства нужны новые фабрики или расширение существующих объектах, а это долгий процесс. Исключением являются лишь чипы HBM и SOCAMM.
Тем не менее в Hynix считают, что продажи ПК в 2026 году останутся примерно на уровне текущего года.
К слову, на Amazon уже появилась оперативная память (Lexar 8GB DDR5-5600 UDIMM) доступная для предзаказа с датой релиза 31 августа 2027 года.
https://videocardz.com/newz/sk-hynix-outlook-points-to-tight-consumer-memory-supply-through-2028-as-a-lexar-ddr5-listing-shows-a-2027-ship-date
Hynix отмечает, что запасы памяти сокращаются, а заметный рост поставок памяти DRAM, который сможет избавить рынок от дефицита, ожидается лишь в 2028 году, поскольку для наращивания объёмов производства нужны новые фабрики или расширение существующих объектах, а это долгий процесс. Исключением являются лишь чипы HBM и SOCAMM.
Тем не менее в Hynix считают, что продажи ПК в 2026 году останутся примерно на уровне текущего года.
К слову, на Amazon уже появилась оперативная память (Lexar 8GB DDR5-5600 UDIMM) доступная для предзаказа с датой релиза 31 августа 2027 года.
https://videocardz.com/newz/sk-hynix-outlook-points-to-tight-consumer-memory-supply-through-2028-as-a-lexar-ddr5-listing-shows-a-2027-ship-date
👎12🤡5🤯2👏1👻1
Вполне валидные выражения в C++:
[](){};
[](){}();;
[]{};
[]{}();😁39👍10🥰4🤔3🤮2
Краткий совет по Linux:
У вас есть файлы логов, сжатые в формат .gz? Вам не нужно распаковывать их, чтобы прочитать или выполнить поиск по содержимому.
Используйте инструменты с префиксом «z» напрямую:
* `zcat` — просмотр файла;
* `zless` — прокрутка содержимого;
* `zgrep` — поиск внутри файла;
* `zegrep` — поиск с использованием расширенных регулярных выражений;
* `zfgrep` — поиск фиксированных строк;
* `zcmp`/`zdiff` — сравнение файлов.
Эти команды позволяют просматривать сжатые логи без предварительной распаковки — идеально для оперативного устранения неполадок.
У вас есть файлы логов, сжатые в формат .gz? Вам не нужно распаковывать их, чтобы прочитать или выполнить поиск по содержимому.
Используйте инструменты с префиксом «z» напрямую:
* `zcat` — просмотр файла;
* `zless` — прокрутка содержимого;
* `zgrep` — поиск внутри файла;
* `zegrep` — поиск с использованием расширенных регулярных выражений;
* `zfgrep` — поиск фиксированных строк;
* `zcmp`/`zdiff` — сравнение файлов.
Эти команды позволяют просматривать сжатые логи без предварительной распаковки — идеально для оперативного устранения неполадок.
🔥22❤4👏2
Covering indexes (Покрывающие индексы)
(описание к предыдущему посту)
Покрывающие индексы позволяют ускорить выполнение SQL-запросов за счёт исключения обращений к основной таблице, если все нужные данные уже есть в индексе. Они применябтся в базах данных для оптимизации запросов.
#### 1. Сравнение: Без покрывающего индекса vs с покрывающим индексом
Без покрывающего индекса (Without Covering Index):
- Система выполняет запрос, собирает все необходимые столбцы для запроса, но вынуждена обращаться к основной таблице базы данных
- Это менее эффективно, так как требует дополнительных операций чтения данных из таблицы.
С покрывающим индексом (With a Covering Index):
- Аналогичный процесс поиска активных пользователей, но теперь все необходимые столбцы для запроса уже включены в индекс.
- Система не нуждается в обращении к основной таблице, что значительно ускоряет выполнение запроса.
- Данные извлекаются напрямую из индекса, минуя основную таблицу.
#### 2. Пример создания покрывающего индекса (Covering Index)
В нижней правой части показан синтаксис создания покрывающего индекса:
Разъяснение элементов:
- Index Name (имя индекса):
- Key Columns (ключевые столбцы):
- Included Column (включённый столбец):
#### 3. Пример SQL-запроса (Query)
Этот запрос выбирает статус, фамилию, имя и email пользователей, у которых статус равен «Active», и сортирует результаты по фамилии и имени.
(описание к предыдущему посту)
Покрывающие индексы позволяют ускорить выполнение SQL-запросов за счёт исключения обращений к основной таблице, если все нужные данные уже есть в индексе. Они применябтся в базах данных для оптимизации запросов.
#### 1. Сравнение: Без покрывающего индекса vs с покрывающим индексом
Без покрывающего индекса (Without Covering Index):
- Система выполняет запрос, собирает все необходимые столбцы для запроса, но вынуждена обращаться к основной таблице базы данных
- Это менее эффективно, так как требует дополнительных операций чтения данных из таблицы.
С покрывающим индексом (With a Covering Index):
- Аналогичный процесс поиска активных пользователей, но теперь все необходимые столбцы для запроса уже включены в индекс.
- Система не нуждается в обращении к основной таблице, что значительно ускоряет выполнение запроса.
- Данные извлекаются напрямую из индекса, минуя основную таблицу.
#### 2. Пример создания покрывающего индекса (Covering Index)
В нижней правой части показан синтаксис создания покрывающего индекса:
CREATE INDEX IX_Users_Search
ON Users (Status, LastName, FirstName)
INCLUDE (Email);
Разъяснение элементов:
- Index Name (имя индекса):
IX_Users_Search — название созданного индекса.- Key Columns (ключевые столбцы):
Status, LastName, FirstName — используются для фильтрации (WHERE) и сортировки (ORDER BY) в запросе.- Included Column (включённый столбец):
Email — добавлен через INCLUDE для того, чтобы избежать обращения к основной таблице при извлечении email-адресов.#### 3. Пример SQL-запроса (Query)
SELECT
Status, LastName, FirstName, Email
FROM
Users
WHERE
Status = 'Active'
ORDER BY
LastName, FirstName;
Этот запрос выбирает статус, фамилию, имя и email пользователей, у которых статус равен «Active», и сортирует результаты по фамилии и имени.
Telegram
METANIT.COM
Covering indexes (Покрывающие индексы)
(описание в следующем посте)
(описание в следующем посте)
❤5✍5🤝2
Добавлены вводные статьи по фреймворку PyTorch и Deep Learning
https://metanit.com/python/pytorch/
#python #pytorch #deeplearning
https://metanit.com/python/pytorch/
#python #pytorch #deeplearning
❤13🥰4👏3👍1🤮1
Краткий совет по Linux:
Если вы хотите очистить пустые директории, команда
Опция
Команда
В качестве альтернативы для выполнения той же задачи можно использовать следующую команду:
Если вы хотите очистить пустые директории, команда
find значительно упростит эту задачу:find . -type d -empty -exec rmdir -v {} +Опция
-type d осуществляет поиск директорий, -empty выбирает именно пустые из них, а -exec rmdir {} запускает команду rmdir для их удаления.Команда
rmdir перед удалением проверяет, что директория действительно пуста.В качестве альтернативы для выполнения той же задачи можно использовать следующую команду:
find . -type d -empty -delete
✍17❤4🥰1
В Anthropic 27% работы выполняет ИИ, однако работники боятся потерять квалификацию
Согласно последнему отчету Anthropic, 27% работы в компании теперь выполняется ИИ. Около 60% инженеров-программистов Anthropic обращаются к ИИ почти каждый день. Чаще всего за отладкой кода, разбором незнакомых проектов и помощью в улучшении архитектуры. ИИ активно используется и для решения более сложных задач. Так, в участие ИИ в проектировании и планировании выросло с 1% до 10%, во внедрении новых функций — с 14% до 37%. Производительность труда, по оценке сотрудников, выросла примерно наполовину. Более того, Claude позволил решить задачи, которые без ИИ вообще не были бы решены: их сочли бы избыточным по затратам, отмечают в компании.
Однако работники компании утверждают, что это снижает их квалификацию. Многие сотрудники Anthropic указывают, что из-за привычки полагаться на ИИ они стали меньше тренировать базовые навыки. Один специалист отметил, что «70% времени теперь уходит на проверку и редактирование кода вместо написания». Другой предположил, что в будущем программисты будут «контролировать работу сразу нескольких Claude» вместо прямого участия в разработке.
Некоторые разработчики признаются, что им не хватает творческого удовлетворения. Раньше процесс написания и отладки кода приносил удовольствие, теперь работа всё чаще сводится к контролю за ИИ, отмечают они. Исчезают и естественные точки взаимодействия между коллегами: меньше совместного программирования, реже случаются импровизированные обсуждения. Один сотрудник отметил, что испытывает грусть, замечая, как младшие коллеги обращаются за советами и наставничеством всё реже, предпочитая решать задачи с ИИ.
https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic
Согласно последнему отчету Anthropic, 27% работы в компании теперь выполняется ИИ. Около 60% инженеров-программистов Anthropic обращаются к ИИ почти каждый день. Чаще всего за отладкой кода, разбором незнакомых проектов и помощью в улучшении архитектуры. ИИ активно используется и для решения более сложных задач. Так, в участие ИИ в проектировании и планировании выросло с 1% до 10%, во внедрении новых функций — с 14% до 37%. Производительность труда, по оценке сотрудников, выросла примерно наполовину. Более того, Claude позволил решить задачи, которые без ИИ вообще не были бы решены: их сочли бы избыточным по затратам, отмечают в компании.
Однако работники компании утверждают, что это снижает их квалификацию. Многие сотрудники Anthropic указывают, что из-за привычки полагаться на ИИ они стали меньше тренировать базовые навыки. Один специалист отметил, что «70% времени теперь уходит на проверку и редактирование кода вместо написания». Другой предположил, что в будущем программисты будут «контролировать работу сразу нескольких Claude» вместо прямого участия в разработке.
Некоторые разработчики признаются, что им не хватает творческого удовлетворения. Раньше процесс написания и отладки кода приносил удовольствие, теперь работа всё чаще сводится к контролю за ИИ, отмечают они. Исчезают и естественные точки взаимодействия между коллегами: меньше совместного программирования, реже случаются импровизированные обсуждения. Один сотрудник отметил, что испытывает грусть, замечая, как младшие коллеги обращаются за советами и наставничеством всё реже, предпочитая решать задачи с ИИ.
https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic
Anthropic
How AI Is Transforming Work at Anthropic
😢20🤔4👎2😁2🤯2🤬1