Gamow bag эффективнее, чем просто вдыхание кислорода, если речь идет о лечении уже развившегося тяжелого отека мозга или легких - острых и часто фатальных форм высотной болезни. Альпинисты на самом деле дышат не чистым кислородом (его невозможно столько доставить), а смесью с атмосферным воздухом, то есть испытывают гипоксию.
Пересчитаем грузоподъемность аэростата непосредственно на высоте 10 000 м, где происходит отделение планирующего модуля. Плотность воздуха на 10 000 м по стандартной атмосфере - 0,414 кг/м³, плотность гелия - 0,057 кг/м³. Подъемная сила одного кубометра гелия составляет 0,357 кг. Для подъема системы общей массой 15 кг (оболочка 2,5 кг, модуль 3-4 кг, полезный груз 9-10 кг) на этой высоте требуется объем аэростата не менее 42 м³.
При запуске из южного базового лагеря (5300 м) начальный объем оболочки - 25 м³. К высоте 10 000 м газ расширяется в 1,78 раза из-за падения давления и температуры, достигая 44,5 м³. Подъемная сила на целевой высоте - 15,9 кг, что с запасом перекрывает массу системы. Таким образом, аэростат объемом 25 м³ на старте уверенно доставляет модуль к точке сброса на 10 000 м, после чего планирующий модуль с Gamow bag и дополнительным снаряжением наводится на вершину Эвереста (8848 м) с точностью 1-5 м.
Хотя, возможно, проще системы жизнеобеспечения стационарно установить на популярных маршрутах для общего пользования, как сейчас кое-где навешены перила.
Непогода на вершине не означает непогоду в базовом лагере. Но и при непогоде в базовом лагере аэростат можно запускать из долины, а к месту посадки планирующий модуль долетит несколько километров. В крайнем случае сброс планирующего модуля с истребителя добавит 10-50 тыс.долл.
Рекордная высота, с которой удалось эвакуировать человека с помощью вертолета, составляет около 7800 метров над уровнем моря. В обычной практике вертолетная эвакуация с высот более 6000 метров над уровнем моря невозможна. Пострадавшего сначала спускают наземной группой до более низкой площадки, а затем забирают вертолётом.
Кодируйте UUIDv7 в выгузках в компактный текстовый формат. А вообще сравнивать идентификаторы глазами - это плохая идея. Пользователи вообще не должны видеть идентификаторы, ведь им нужны бизнес-данные. А для внешних потребителей нужно использовать стандартизованные классификаторы и преобразовывать суррогатные ключи в натуральные, действительные в отчетную дату.
Надо сказать, что ИИ в основном агрегируют те меры, которые уже предлагаются или описываются в интернете. Но хотелось бы видеть более творческий подход, основанный на глубоком анализе, а также на исследовании эффективности и побочных эффектов сложившейся практики в разных странах.
Например, формально поддерживаемый законодательством бессрочный наём фактически не работает. Заемный труд и принуждение к увольнению широко распространены. Нужно не закрывать на это глаза, а искать продуманные альтернативные решения, отвечающие интересам и работников/соискателей, и бизнеса. Трудовые отношения нужно вернуть в правовое поле и адаптировать к современным вызовам (удаленная работа, проектная работа, ротация и "горизонтальный рост", искусственный интеллект, гибкие организационные структуры и т.д.).
Это не "наём сломан" (правильное написание - наём), а классический образец market failure (фиаско рынка). Не поможет ни новая частная платформа найма, ни призывы к участникам рынка труда. Ничто не поможет, кроме эффективного государственного регулирования рынка труда. После Великой депрессии государственное регулирование («Новый курс» Франклина Рузвельта) прекрасно зарекомендовало себя на финансовых рынках всего мира. Свобода работодателей и посредников должна быть разумным образом ограничена. Я не имею в виду бюрократические фантазии и прямое государственное вмешательство. Серьезная проблема требует серьезного и беспристрастного научного подхода. Трудовой кодекс несостоятелен, так как слабо связан с реальностью. Но не заметно, что российское государство и олигархи замечают проблему. Пока у них всё вроде хорошо. Проблема должна дозреть до состояния катастрофы, чтобы ею занялись.
Производитель памяти Micron Technology пытается подстегнуть спрос на память. Это просто маркетинговый ход. Если внимательно прочитать, что имеется в виду под Level 4 по классификации SAE, то вырисовывается совершенно противоположная картина. Такой автономный автомобиль способен выполнять все задачи по вождению самостоятельно и без вмешательства человека, но только в определенных условиях (географических, погодных или в конкретных сценариях). Это фактически будет означать, что реальная автономность потребуется лишь на физически изолированных от обычного транспорта и пешеходов специальных выделенных полосах движения или дорогах. В таких "тепличных" условиях, где значительная нагрузка по регулированию движения будет переложена на инфраструктуру ("умную дорогу"), не понадобятся суперумные транспортые средства с запредельными объемами памяти.
Вы хотите, чтобы в одном человеке сочетались несочетаемые и даже взаимоисключающие вещи. В результате получите недоспециалиста во всех областях с хорошо подвешенным языком («и швец, и жнец, и на дуде игрец»).
Судя по тексту вакансии Вам нужны три разных человека:
Backend Engineer (Python разработчик инфраструктуры и API для интеграции моделей)
Machine Learning Engineer (специалист по RAG, агентам и пайплайнам на базе LLM)
Applied Scientist (исследователь, улучшающий качество моделей и архитектуры)
Я не поленился сходить на сайт https://gptunnel.ru/, заблудился там, и вижу, что остро необходим еще и Product Designer.
А если вам еще нужен и лидер (хотя мне кажется, что он уже есть), то ищите еще и Project Manager.
Понятно, что бюджет ограничен. Кого-то можно взять на ограниченный срок, не сразу или по совместительству. А может быть он у вас уже и есть, просто хотелось сразу всего и побольше от нового кандидата.
Вот это хотелки у работодателя! От души посмеялся! Интересно, чем заняты остальные 30-50 сотрудников помимо креативной рекламы, если столько хотят взвалить на одного человека? И кто клюнет на такую вакансию? Должно быть, такой же великий комбинатор. Чувство меры иногда полезно.
В свете того, что Китай собирается удорожать доступ к своим LLM, бизнес-идея агрегатора с оплатой по мере использования может действительно взлететь. Пожелаю ему удачи!
Таблица курсов валют. Дата, Валюта, Курс.Объясните здесь смысл поля id?
Валюта российский рубль имела обозначение RUR, а с 1998 года стала RUB. И это не единственный такой пример. Не существует в природе гарантированно неизменных и уникальных натуральных ключей. Например, известны дубликаты ИНН, MAC-адресов. А ключ для связи таблиц (поле id) изменяться не должен.
Каждая таблица ОБЯЗАНА иметь created_at и updated_at Не обязана. Должна быть целесообразность. Не надо категорических суждений.
Та же таблица курсов валют. Ее можно хоть всю передавать, хоть загрузить из интернетов.
В этом случае будет только актуальная таблица. А если в целях аудита понадобится посмотреть или вставить в расчеты ошибочные исторические данные?
Я бы посоветовал: используйте uuid7 для id, если база не требует экстремальной производительности.
Я уже устал опровергать взятый с потолка миф, что UUIDv7 якобы снижает производительность по сравнению с целочисленными ID.
С внешними ключами это еще та морока, не забыть словить какой нибудь каскадный update или delete.
Никаких update или delete с ключами происходить не должно. Ключи должны быть вечными и неизменными. Значения атрибутов и связей могут изменяться с течением времени - для этого есть поля valid_from и valid_to (или их синонимы start_date и end_date).
Внешних ключей (и других ограничений) не должно быть только у таблиц, куда загружаются сырые данные, чтобы загрузка происходила без помех. Потом эти данные всё равно нужно валидировать, прежде чем использовать.
Миграция - слишком громкое слово. Достаточно только заменить прежнюю функцию генерации UUID на uuidv7(). Это возможно всегда, быстро и без побочных эффектов. Ни столбец с типом данных UUID, ни прежние UUID трогать не надо. В одном столбце с типом данных UUID мирно уживаются UUID разных версий. По мере роста количества свежих UUIDv7 скорость работы БД будет увеличиваться.
В-третьих, работает - не трогай.
Значит, еще не припекло. Когда БД начнет с трудом ворочаться, тронете.
Джойны по UUIDv7 и по числовым ID работают одинаково быстро. Сравнение происходит уже по небольшому количеству старших битов UUIDv7, а не по всем 128 битам.
Числовые ID занимают меньше места только на первый взгляд. Ведь при слиянии данных из нескольких таблиц (систем-источников) приходится дублировать данные - теперь уже с новыми уникальными ключами, так как числовые ID совершенно разных записей из разных источников часто совпадают.
В целом статья мне понравилась, но ее нужно "полировать".
-- Распределённая система / микросервисы:
id UUID PRIMARY KEY
DEFAULT gen_random_uuid() -- v4
-- Или генерируйте UUIDv7 на стороне приложения
После появления встроенной функции uuidv7() в PostgreSQL не осталось ни одного разумного аргумента в пользу UUIDv4. Заранее отвечаю тем, кто боится раскрыть дату и время генерации UUIDv7, - функция uuidv7() позволяет исказить эту дату путем смещения значения таймстемпа даже не на дни, а на тысячелетия, причем очень удобным и безопасным способом.
Совершенно непонятно, зачем в случае микросервисов нужно генерировать UUIDv7 на стороне приложения, если есть такая замечательная встроенная функция uuidv7() в PostgreSQL, формирующая таймстемп с точностью 250 наносекунд.
В случае распределенной системы удобно иметь два ключа в записи: один генерится на клиенте (для сверки), а второй на сервере (для лучшей монотонности ключей, первичный ключ) - функцией uuidv7(). Об этом упоминается в RFC 9562:
Applications using a monolithic database may find using database-generated UUIDs (as opposed to client-generated UUIDs) provides the best UUID monotonicity. In addition to UUIDs, additional identifiers MAY be used to ensure integrity and feedback.
Проблема в клиентуре: соискатели не станут тратить еще много часов в сутки на второй сервис, а работодатели тоже не захотят платить второму сервису. Вся клиентура стекается на один сервис. Там соискатели имеют самый широкий выбор работодателей, а работодатели - самый широкий выбор соискателей. Поэтому значимый второй сервис не возникнет, даже если его можно сделать за копейки.
Трудоустройство должно быть организованным рынком, как, например, финансы, где практически все торги внутри страны сосредоточены на одной национальной фондовой бирже. Национальная фондовая биржа - это не бюрократический государственный сервис, но и не частная монополия (в отличие от HH). Ее строго контролируют с одной стороны брокеры (они ее акционеры), а с другой - центральный банк или другой государственный финансовый регулятор. Но к такому строгому, но не забюрократизированному регулированию финансов государства пришли не сразу, а через череду ужасных финансовых кризисов.
В России государство просто закрывает глаза на безобразия дикого рынка труда в IT, ведь техноолигархов всё устраивает - у них тысячи соискателей на одну вакансию. Да и IT отрасль сложная - кто из госчиновников понимает, как ее регулировать?
Есть целый ТК РФ на эту тему, который даже соблюдается обычно.
Это как сталинская конституция - на бумаге всё выглядело просто замечательно. И соблюдалось! Правда, с реальной жизнью это никак не соприкасалось
Да, нужна конкуренция, причём даже не обязательно зарубежная.
Импортозамещенная? Среди аккредитованных компаний? С исключением реального сильнейшего конкурента? В общем, выхолощенная
Есть же дипломы
Я про стандарты отношений между работодателем/рекрутером и кандидатом. Сейчас это не регулируется ничем, кроме благих пожеланий не дискриминировать некоторые категории граждан. В большинстве случаев кандидат "покупает кота в мешке". "Оффер" может скрывать "подводные камни". Реальный отбор кандидатов далеко не всегда делается в истинных интересах работодателя, особенно в крупных и государственных компаниях. Про такую дикость, как отбор по гороскопу, уже упоминали. А есть еще фаворитизм, заемный труд и другие неприглядные практики. Бессрочный трудовой договор в реальности таковым не является (у работодателя масса способов вынудить работника уволиться), и лучше бы это признать в ТК, чтобы заранее защитить интересы сторон соответствующими стимулами и компенсациями
Здесь нужны организационные решения, а не технические, потому что технические решения могут оказаться неверными, да HH и не будет их внедрять - его всё устраивает.
Чего на самом деле не хватает:
Отраслевые стандарты, выработанные с участием всех заинтересованных сторон (не только крупных компаний и вообще не только работодателей, но и, например, заслуженных профессионалов в IT) и подкрепленные законодательством
Пристальное внимание Федеральной антимонопольной службы к проблеме и реабилитация LinkedIn как главного конкурента HH
Реформа трудового законодательства исходя из доктрины, что прием на работу и дальнейшие трудовые отношения - это не частное дело работодателя и кандидата, не традиция, не "дикий рынок" (с правом сильного, непрозрачностью и т.д.), а сфера общественного интереса (но не объект для бюрократизации - я против госсервиса и против госоценки кандидатов). Здесь полезно присмотрется к проверенному позитивному зарубежному опыту (без слепого копирования)
Gamow bag эффективнее, чем просто вдыхание кислорода, если речь идет о лечении уже развившегося тяжелого отека мозга или легких - острых и часто фатальных форм высотной болезни. Альпинисты на самом деле дышат не чистым кислородом (его невозможно столько доставить), а смесью с атмосферным воздухом, то есть испытывают гипоксию.
Пересчитаем грузоподъемность аэростата непосредственно на высоте 10 000 м, где происходит отделение планирующего модуля.
Плотность воздуха на 10 000 м по стандартной атмосфере - 0,414 кг/м³, плотность гелия - 0,057 кг/м³. Подъемная сила одного кубометра гелия составляет 0,357 кг.
Для подъема системы общей массой 15 кг (оболочка 2,5 кг, модуль 3-4 кг, полезный груз 9-10 кг) на этой высоте требуется объем аэростата не менее 42 м³.
При запуске из южного базового лагеря (5300 м) начальный объем оболочки - 25 м³. К высоте 10 000 м газ расширяется в 1,78 раза из-за падения давления и температуры, достигая 44,5 м³. Подъемная сила на целевой высоте - 15,9 кг, что с запасом перекрывает массу системы.
Таким образом, аэростат объемом 25 м³ на старте уверенно доставляет модуль к точке сброса на 10 000 м, после чего планирующий модуль с Gamow bag и дополнительным снаряжением наводится на вершину Эвереста (8848 м) с точностью 1-5 м.
Хотя, возможно, проще системы жизнеобеспечения стационарно установить на популярных маршрутах для общего пользования, как сейчас кое-где навешены перила.
Непогода на вершине не означает непогоду в базовом лагере. Но и при непогоде в базовом лагере аэростат можно запускать из долины, а к месту посадки планирующий модуль долетит несколько километров. В крайнем случае сброс планирующего модуля с истребителя добавит 10-50 тыс.долл.
Рекордная высота, с которой удалось эвакуировать человека с помощью вертолета, составляет около 7800 метров над уровнем моря. В обычной практике вертолетная эвакуация с высот более 6000 метров над уровнем моря невозможна. Пострадавшего сначала спускают наземной группой до более низкой площадки, а затем забирают вертолётом.
Кодируйте UUIDv7 в выгузках в компактный текстовый формат. А вообще сравнивать идентификаторы глазами - это плохая идея. Пользователи вообще не должны видеть идентификаторы, ведь им нужны бизнес-данные. А для внешних потребителей нужно использовать стандартизованные классификаторы и преобразовывать суррогатные ключи в натуральные, действительные в отчетную дату.
А можно ли сделать так, чтобы LLM-ка сама последовательно задавала все необходимые уточняющие вопросы промпта с учетом того, что ей уже известно?
А вот какие решения проблемы предложил искусственный интеллект DeepSeek: https://chat.deepseek.com/share/ptfw1ihgzjp9iorbpw
Я с большим интересом это прочитал. Надо сказать, что ответ DeepSeek превзошел мои ожидания. Это вовсе не AI slop, а весьма продуманная система мер.
А вот, что предложил Perplexity без использования мощных платных моделей (LLM): https://www.perplexity.ai/search/2136f90b-8760-44d0-afd2-b01d94fe478e
Не так блестяще, но тоже интересно.
Надо сказать, что ИИ в основном агрегируют те меры, которые уже предлагаются или описываются в интернете. Но хотелось бы видеть более творческий подход, основанный на глубоком анализе, а также на исследовании эффективности и побочных эффектов сложившейся практики в разных странах.
Например, формально поддерживаемый законодательством бессрочный наём фактически не работает. Заемный труд и принуждение к увольнению широко распространены. Нужно не закрывать на это глаза, а искать продуманные альтернативные решения, отвечающие интересам и работников/соискателей, и бизнеса. Трудовые отношения нужно вернуть в правовое поле и адаптировать к современным вызовам (удаленная работа, проектная работа, ротация и "горизонтальный рост", искусственный интеллект, гибкие организационные структуры и т.д.).
Это не "наём сломан" (правильное написание - наём), а классический образец market failure (фиаско рынка). Не поможет ни новая частная платформа найма, ни призывы к участникам рынка труда. Ничто не поможет, кроме эффективного государственного регулирования рынка труда. После Великой депрессии государственное регулирование («Новый курс» Франклина Рузвельта) прекрасно зарекомендовало себя на финансовых рынках всего мира. Свобода работодателей и посредников должна быть разумным образом ограничена. Я не имею в виду бюрократические фантазии и прямое государственное вмешательство. Серьезная проблема требует серьезного и беспристрастного научного подхода. Трудовой кодекс несостоятелен, так как слабо связан с реальностью. Но не заметно, что российское государство и олигархи замечают проблему. Пока у них всё вроде хорошо. Проблема должна дозреть до состояния катастрофы, чтобы ею занялись.
Производитель памяти Micron Technology пытается подстегнуть спрос на память. Это просто маркетинговый ход. Если внимательно прочитать, что имеется в виду под Level 4 по классификации SAE, то вырисовывается совершенно противоположная картина. Такой автономный автомобиль способен выполнять все задачи по вождению самостоятельно и без вмешательства человека, но только в определенных условиях (географических, погодных или в конкретных сценариях). Это фактически будет означать, что реальная автономность потребуется лишь на физически изолированных от обычного транспорта и пешеходов специальных выделенных полосах движения или дорогах. В таких "тепличных" условиях, где значительная нагрузка по регулированию движения будет переложена на инфраструктуру ("умную дорогу"), не понадобятся суперумные транспортые средства с запредельными объемами памяти.
Вы хотите, чтобы в одном человеке сочетались несочетаемые и даже взаимоисключающие вещи. В результате получите недоспециалиста во всех областях с хорошо подвешенным языком («и швец, и жнец, и на дуде игрец»).
Судя по тексту вакансии Вам нужны три разных человека:
Backend Engineer (Python разработчик инфраструктуры и API для интеграции моделей)
Machine Learning Engineer (специалист по RAG, агентам и пайплайнам на базе LLM)
Applied Scientist (исследователь, улучшающий качество моделей и архитектуры)
Я не поленился сходить на сайт https://gptunnel.ru/, заблудился там, и вижу, что остро необходим еще и Product Designer.
А если вам еще нужен и лидер (хотя мне кажется, что он уже есть), то ищите еще и Project Manager.
Понятно, что бюджет ограничен. Кого-то можно взять на ограниченный срок, не сразу или по совместительству. А может быть он у вас уже и есть, просто хотелось сразу всего и побольше от нового кандидата.
Вот это хотелки у работодателя! От души посмеялся! Интересно, чем заняты остальные 30-50 сотрудников помимо креативной рекламы, если столько хотят взвалить на одного человека? И кто клюнет на такую вакансию? Должно быть, такой же великий комбинатор. Чувство меры иногда полезно.
В свете того, что Китай собирается удорожать доступ к своим LLM, бизнес-идея агрегатора с оплатой по мере использования может действительно взлететь. Пожелаю ему удачи!
Это неудачное правило. Тот, кто присылает данные, может изменить свой классификатор, и что тогда делать?
Валюта российский рубль имела обозначение RUR, а с 1998 года стала RUB. И это не единственный такой пример. Не существует в природе гарантированно неизменных и уникальных натуральных ключей. Например, известны дубликаты ИНН, MAC-адресов. А ключ для связи таблиц (поле id) изменяться не должен.
В этом случае будет только актуальная таблица. А если в целях аудита понадобится посмотреть или вставить в расчеты ошибочные исторические данные?
Я уже устал опровергать взятый с потолка миф, что UUIDv7 якобы снижает производительность по сравнению с целочисленными ID.
Никаких update или delete с ключами происходить не должно. Ключи должны быть вечными и неизменными. Значения атрибутов и связей могут изменяться с течением времени - для этого есть поля valid_from и valid_to (или их синонимы start_date и end_date).
Внешних ключей (и других ограничений) не должно быть только у таблиц, куда загружаются сырые данные, чтобы загрузка происходила без помех. Потом эти данные всё равно нужно валидировать, прежде чем использовать.
Для старых версий PostgreSQL рекомендую расширение pg_uuidv7.
Миграция - слишком громкое слово. Достаточно только заменить прежнюю функцию генерации UUID на uuidv7(). Это возможно всегда, быстро и без побочных эффектов. Ни столбец с типом данных UUID, ни прежние UUID трогать не надо. В одном столбце с типом данных UUID мирно уживаются UUID разных версий. По мере роста количества свежих UUIDv7 скорость работы БД будет увеличиваться.
Значит, еще не припекло. Когда БД начнет с трудом ворочаться, тронете.
Это не так.
Джойны по UUIDv7 и по числовым ID работают одинаково быстро. Сравнение происходит уже по небольшому количеству старших битов UUIDv7, а не по всем 128 битам.
Числовые ID занимают меньше места только на первый взгляд. Ведь при слиянии данных из нескольких таблиц (систем-источников) приходится дублировать данные - теперь уже с новыми уникальными ключами, так как числовые ID совершенно разных записей из разных источников часто совпадают.
В целом статья мне понравилась, но ее нужно "полировать".
После появления встроенной функции uuidv7() в PostgreSQL не осталось ни одного разумного аргумента в пользу UUIDv4. Заранее отвечаю тем, кто боится раскрыть дату и время генерации UUIDv7, - функция uuidv7() позволяет исказить эту дату путем смещения значения таймстемпа даже не на дни, а на тысячелетия, причем очень удобным и безопасным способом.
Совершенно непонятно, зачем в случае микросервисов нужно генерировать UUIDv7 на стороне приложения, если есть такая замечательная встроенная функция uuidv7() в PostgreSQL, формирующая таймстемп с точностью 250 наносекунд.
В случае распределенной системы удобно иметь два ключа в записи: один генерится на клиенте (для сверки), а второй на сервере (для лучшей монотонности ключей, первичный ключ) - функцией uuidv7(). Об этом упоминается в RFC 9562:
Проблема в клиентуре: соискатели не станут тратить еще много часов в сутки на второй сервис, а работодатели тоже не захотят платить второму сервису. Вся клиентура стекается на один сервис. Там соискатели имеют самый широкий выбор работодателей, а работодатели - самый широкий выбор соискателей. Поэтому значимый второй сервис не возникнет, даже если его можно сделать за копейки.
Трудоустройство должно быть организованным рынком, как, например, финансы, где практически все торги внутри страны сосредоточены на одной национальной фондовой бирже. Национальная фондовая биржа - это не бюрократический государственный сервис, но и не частная монополия (в отличие от HH). Ее строго контролируют с одной стороны брокеры (они ее акционеры), а с другой - центральный банк или другой государственный финансовый регулятор. Но к такому строгому, но не забюрократизированному регулированию финансов государства пришли не сразу, а через череду ужасных финансовых кризисов.
В России государство просто закрывает глаза на безобразия дикого рынка труда в IT, ведь техноолигархов всё устраивает - у них тысячи соискателей на одну вакансию. Да и IT отрасль сложная - кто из госчиновников понимает, как ее регулировать?
Это как сталинская конституция - на бумаге всё выглядело просто замечательно. И соблюдалось! Правда, с реальной жизнью это никак не соприкасалось
Импортозамещенная? Среди аккредитованных компаний? С исключением реального сильнейшего конкурента? В общем, выхолощенная
Я про стандарты отношений между работодателем/рекрутером и кандидатом. Сейчас это не регулируется ничем, кроме благих пожеланий не дискриминировать некоторые категории граждан. В большинстве случаев кандидат "покупает кота в мешке". "Оффер" может скрывать "подводные камни". Реальный отбор кандидатов далеко не всегда делается в истинных интересах работодателя, особенно в крупных и государственных компаниях. Про такую дикость, как отбор по гороскопу, уже упоминали. А есть еще фаворитизм, заемный труд и другие неприглядные практики. Бессрочный трудовой договор в реальности таковым не является (у работодателя масса способов вынудить работника уволиться), и лучше бы это признать в ТК, чтобы заранее защитить интересы сторон соответствующими стимулами и компенсациями
Здесь нужны организационные решения, а не технические, потому что технические решения могут оказаться неверными, да HH и не будет их внедрять - его всё устраивает.
Чего на самом деле не хватает:
Отраслевые стандарты, выработанные с участием всех заинтересованных сторон (не только крупных компаний и вообще не только работодателей, но и, например, заслуженных профессионалов в IT) и подкрепленные законодательством
Пристальное внимание Федеральной антимонопольной службы к проблеме и реабилитация LinkedIn как главного конкурента HH
Реформа трудового законодательства исходя из доктрины, что прием на работу и дальнейшие трудовые отношения - это не частное дело работодателя и кандидата, не традиция, не "дикий рынок" (с правом сильного, непрозрачностью и т.д.), а сфера общественного интереса (но не объект для бюрократизации - я против госсервиса и против госоценки кандидатов). Здесь полезно присмотрется к проверенному позитивному зарубежному опыту (без слепого копирования)
Может ли поднять человека? Какой статический потолок?