Несколько человек и я в том числе спрашивали про собственную оценку в реальных исследованиях. Отвечаю.
Я попробовал для начала дать одну среднюю по сложности задачу, но которая выполнялась плану, в который другая LLM ранее внесла основные требования. Результат мне очень понравился и я подумал, что Grok 4.5 может стать одной из моих рабочих LLM.
После этого я дал Гроку ссылку на локальный бэклог и попросил выполнить 10 задач с указанными номерами. Все задачи выполнялись на максимальных настройках грока. Задачи были на питоне и их уровень не сложный, можно сказать даже часто простой. В результате из 10 задач одна была решена с критической ошибкой, две задачи были решены сомнительно, одна из простых задач была решена хоть и с безобидной, но с "детской" ошибкой. Сомнения в результатах выполнения у меня возникли сразу и я попросил другую LLM курсора Composer 2.5 сделать ревью комитов. В результате компоузер, который позиционируется как более простая по отношению к гроку модель, нашел все его ошибки и четко расписал. Итого я оставил из десяти шесть коммитов без изменений, два откатил полностью и в двух попросил композера исправить ошибки.
Пример критической ошибки. Есть сайт на фреймворке django. Этот фреймворк для всех LLM очень хорошо изучен. Раньше у меня для так называемых view - которые рендерят страницу, было кэширование полной страницы. Потом на сайте добавились пользователи и поскольку контент зависит от пользователя, я декоратор кэширования закомментировал и прямо в тех же строках указал причину. В бэклоге пункт, который выполнял грок, был ранее сформулирован другой llm как рекомендация по улучшению и звучал примерно так - вернуть закомментированное кэширование, там, где это безопасно и не поломает отображение страниц. Гроку в двух местах намекают, что кэширование может быть опасно, но он раскоментировал декораторы кэширования, добавил еще один декоратор, который не исправляет проблему и закомитил. Результат его действий, гости и боты могут видеть кэшированные страницы залогиненых пользователей. Залогиненные пользователи могут видеть страницы для гостей. Пользователи могут видеть страницы, предназначенные для ботов (где часть ссылок скрыта).
А детская ошибка следующая - нужно было сделать прогрессивную каптчу, которая после трех неправильно введенных паролей усложнялась. Грок это сделал, добавил счетчик, но этот счетчик терял единицу еще до проверки ввода пароля. Т.е. вместо трех попыток давалось только две.
И еще по-мелочи, а в других случаях это могут быть и не мелочи. Грок нарушил инструкцию, которая была указана в agents.md. Там был явный запрет добавлять Курсор в Ко-авторы в коммит месседжах при отправке в репозиторий.
Резюме Гроку 4.5 - как игрушка нормальный, как полноценный топовый инструмент - нет. И я не знаю почему его ставят выше последних моделей опуса и других. Когда не доверяешь LLM, то вместо полноценного вайб-кодинга приходится всё перепроверять самому или через ревью другими llm, выполнять промпты повторно, исправлять ошибки итп. Это очень утомляет и занимает много времени. Для сравнения Composer'у 2.5 от курсора я доверяю. Да Компоузер иногда делает ошибки, да компоузер не всегда может соревноваться с последним опусом, но ошибки компоузера встречается не часто и в гораздо более сложных задачах чем у Грока 4.5, а вгрызается он в суть процессов гораздо глубже. В общем пока моя рабочая лошадка остается Composer'у 2.5, а для самых сложных задач использую последние Claude Opus (сейчас 4.8) с настройками High.
Интересно, как компании, проводящие тесты, могут гарантировать их не-утечку?
Если набор тестов одинаковый, то значит и промпты должны быть одинаковые. И, если взять одну компанию, например, Anthropic, то она должна была получать промпты при выходе каждой версии Opus, Sonet, Fable итп.
И все, что нужно сделать этой компании, после выхода каждой модели в течение 1-2 недель отслеживать все промпты. Дальше отбирать повторяющиеся, отсеивать простые итп. И даже если запросы идут по отдельности с разных адресов, рано или поздно набор "независимых тестов" можно вычислить. А дальше уже дело техники. Сажаешь условного "индуса", который будет каждую нерешенную проблему разбирать долгими ночами и обучать модель, как именно ее нужно решать.
А еще помните, как бывает? Модель в закрытом доступе, а результаты бенчмарков уже опубликованы. Для той же Anthropic это означает, что из 100 пользователей, которым дали ранний доступ, несколько "пользователей" шлют задачи из бенчмарка.
Уточнение только: модель самого курсора называется не Cursor 2.5, а Composer 2.5. Пользуюсь ей постоянно и она действительно очень хороша и дешева. Курсор дает на модель Composer 2.5 отдельный лимит, который я на "тройной" подписке (Pro+ за 60$) ни разу ни смог выбрать, при том что ежемесячно использую около 500млн токенов только на этой модели. Grok 4.5 включили в этот же отдельный лимит, который идет "бонусом" к лимиту на все остальные модели (Claude, ChatGPT итп).
Composer 2.5 мне настолько нравится, что даже опасаюсь вместо него пробовать Grok 4.5 в текущих задачах. Хотелось бы дождаться отзывов реальных пользователей.
Кстати, совет тем, кто захочет попробовать курсор впервые. Можно найти реферальную ссылку от текущих пользователей и тогда первый месяц будет в два раза дешевле (10$ за подписку 20$ или 30$ за подписку 60$).
Хотя я сам нахожусь в РФ у меня курсор по умолчанию подключается через Эстонию, иначе модели Claude в курсоре могут не работать. Проверил прямо сейчас - по прежнему новый Grok не доступен. Отключил "прокси" и перезапустил IDE - Grok 4.5 появился. Включил прокси обратно и перезапустил IDE - Grok опять пропал.
Опытным путем установлено, что в европейских странах Грок 4.5 пока отключили, а в США и в РФ он появился. Неожиданное разделение стран. ))
Тоже использую платную подписку Cursor и тоже не вижу новой модели. Установил последнюю версию IDE - это ничего не меняет.
Я думаю причина вот в этом (цитата из анонса по ссылке в статье):
Note: Grok 4.5 is not yet available in the EU in any SpaceXAI products or the API console. EU availability is expected in mid-July.
Т.е. если подключаетесь с европейских IP адресов, то, вероятно, модель появится в IDE в "середине июля". Либо можно попробовать зайти через vpn с американским Ip-адресом. Сообщение выше как раз подтверждает эту версию.
Большинство услуг Роспатента, включая регистрацию программ для ЭВМ переносится на сайт госуслуг. Обновленный функционал Роспатента на госуслугах находится на этапе тестирования и момент переключения осталось ждать не долго. Переключают поэтапно и что-то могут через пару недель переключить, а что-то через пару месяцев.
Противоположный пример. У меня жена привязала apple_id к телефону, потом по какой-то причине, наверное, вышла из этой учетки и год или два пользовалась тем же телефоном, не входя в apple_id. Apple учетку заблокировала и теперь невозможно даже восстановить пароль при том, что к почте, на которую зарегистрирована учетка доступ есть.
В результате телефон превратился в кирпич. Зайти по apple_id нельзя, сменить его на том же телефоне нельзя, продать телефон нельзя итп. Год назад купили новый айфон и был выбор - или все с нуля заводить или перенести данные через резервную копию со старого, но с нерабочим apple_id. Перенесли через копию. Теперь новый телефон работает без apple_id, каждые ХХ минут просит пароль итп.
И теперь на новом телефоне остается выбор - или ограниченный функционал и постоянные просьбы ввести пароль или все снести и поставить заново. А чтобы снести все, нужно 300-400Гб данных через медленный интерфейс куда-то сохранить, а потом попробовать часть вернуть на телефон вручную. Очень “уважаю” в этом плане политику Apple.
На поле боя сейчас все идет к тому, что одни роботы будут сражаться с другими роботами.
А на рынке рекрутинга видимо скоро придем к тому, что одни LLM будут собеседовать других.
Предположим, что большая часть агентств заведут LLM системы, которые будут гарантировано обзванивать кандидатов, отправивших свои резюме. Зная это, кандидаты должны у себя настраивать свои LLM системы, которые будут максимально эффективно отвечать на входящие звонки/опросы, но при этом не будут уведомлять, что это робот.
И тогда процесс для кандидата будет следующий - накидал своей LLM пару абзацев чернового текста "о себе". LLM все красиво оформила разослала резюме в 100 компаний, которые сама отобрала по различным критериям. После этого LLM ответила на 100 голосовых опросов. А кандидат, живой человек, через пару дней получает 5 предложений на финальное собеседование из тех компаний, где он прошел предварительный отбор. При этом LLM кандидата ранжирует все прошедшие предложения по уровню дохода, удалению работодателя, режиму работы и дает сводку, как она отвечала на вопросы LLM работодателя. И при этом не требуется джуна представлять сеньором, а просто нужно при его описании выжать максимум из его положительных сторон и нивелировать его слабые стороны.
Конечно финальное собеседование с живым рекрутом отсеет часть кандидатов. Но для кандидата шансы получить место все равно гораздо выше, когда его уже пригласили на несколько интервью как одного из "лучших", чем когда такого кандидата вообще никуда не зовут месяцами...
Подскажите, а как решается вопрос с персональными данными? Здесь и сбор, и обработка, и хранение и трансграничная передача данных.
Сначала мы хранили все в Google Таблицах, но довольно быстро уперлись в ограничения такого подхода.
Мы используем GPT-4.1
Например, как выполнить это требование “трансграничная передача допустима только после уведомления Роскомнадзора, если обеспечивается защита прав субъектов”?
Конечно вы можете ответить, что гугл-таблицы в прошлом, а LLM еще вчера переключили на российскую... Российские LLM справляются с задачей и по сути и по скорости так же хорошо, как ChatGPT?
Вероятно, что большая часть отечественного ПО, особенно нового, будет писаться и дорабатываться с помощью иностранных AI-агентов. И даже разработчик такого ПО может понятия не иметь, на сколько процентов его код похож на какой-то открытый репозиторий, на котором ранее обучалась LLM модель.
Во время своей работы с ИИ я во многом делаю все противоположно тому, что советуется в статье, и получаю прекрасный результат. Я пишу промпт подробно и часто получаю то, что мне нужно, с первого раза. Секрет успеха в моем случае - подробный промпт и использование топовых моделей, даже для относительно несложных задач. Обычно я использую Claude Opus 4.5/4.6/4.7 в режиме Thinking. На этом можно было бы поставить точку.
Результат обычно настолько хорош, что в большинстве случаев его можно даже не проверять. Правила типа “не переписывай остальной код” зачастую не требуется писать в промптах. Для указанных выше моделей это часто избыточно, а если все равно хочется на этом сделать акцент, то это делается один раз в agents.md внутри проекта, либо в глобальных правилах. Использовать умышлено два языка - это перебор. Я всегда пишу на русском и согласно глобальных правил получаю ответы на русском. Если модель внутри размышлений думает на английском, я ее не ограничиваю.
Уже много раз сталкивался с тем, что лучше один раз потратить цену условно 5x, чем выбрать более простую модель и написать ей пять запросов по цене 2x. В конечном итоге выходит экономия и времени и денег.
А если выбирать модели попроще, то тогда да, требуется их всегда ограничивать, направлять, перенаправлять, наставлять итп. Пишем короткий промпт - ждем минуту результат - анализируем его и проверяем - указываем на ошибки и пишем короткое уточнение. Повторяем 5-10 раз, понимаем, что больше нет сил допиливать и результат уже доведен до состояния “и так сойдет”. А если изначально нужно было реализовать архитектурное решение, то неправильный выбор ИИ-моделью стратегии и многократное допиливание результата с помощью дополнительных промптов может привести к сложной дилемме. Переделать то, что делал несколько дней, или оставить, как сделал, но потом на протяжении нескольких лет при необходимости доработки, использовать костыли и делать двойную по сложности работу.
Спасибо за совет! Про django-cacheops раньше не слышал. Решил попробовать. 10 минут на настройку (с учетом того, что redis у меня уже был настроен) и всё летает в автоматическом режиме. Там, где я раньше тратил очень много времени на добавление в коде кэширования представлений (view), кусков шаблонов, специально выделенных для кэширования функций итп, при наличии этого плагина можно было ничего не делать. У меня на сайте, как думаю и у многих, вся тяжесть работы и замедление формирования страниц связаны с БД. После того, как включил кэширование запросов к БД, сайт получил вторую молодость. А ведь в django-cacheops есть еще куча других разных фич. Например, есть удобное кэширование функций с помощью декоратора, чего нет в Django из коробки (Django только view-функции примерно так кэширует), и многое другое.
@anazarta Благодарю вас, за то, что начали добавлять новые дела по ЦГА Москвы. Прошу обратить внимание ещё вот на какой момент.
Сейчас по ЦГА Москвы Яндексом загружено ~7+тыс дел. Предположим, я сделал десятки разных запросов по всем фамилиям и нашел 100 полезных записей. Через месяц Яндекс добавит еще ~тысячу новых дел. Я повторю свои запросы и найду 110 интересных записей. Из них всего 10 новых. При этом, чтобы понять, где новые находки, а где старые, нужно пересмотреть практически каждую картинку из найденных 110шт. Еще через месяц Яндекс загрузит еще тысячу дел. И придется опять и опять все пересматривать повторно изображения, чтобы найти несколько новых записей. И так до бесконечности.
Было бы удобно, если бы Яндекс как-то помечал новые дела или позволял их фильтровать по дате добавления. Например, если бы был фильтр "Отобразить дела добавленные за последний месяц" или за три месяца, или за произвольный период - это было бы очень удобно. Можно было бы искать только в тех делах, которые ранее не просматривались.
@anazarta Александр, примите в качестве идеи на будущее. У архивов есть большое количество описей дел, которые хранятся в их фондах. Небольшая часть из этих описей переведена в "текстовый" вид, по которому можно проводить поиск. Но бОльшая часть остается "нераспознанной".
К примеру, на сайте ЦГА Москвы выложено ~5500 отсканированных описей в формате PDF и это количество увеличивается. Из всего этого объема, я думаю, текстовый поиск доступен в лучшем случае в ~10%. В каждой описи может быть от нескольких страниц, до нескольких сотен страниц. На одной странице описи может быть до 10-20 заголовков единиц хранения. Т.е. в одной описи максимум может быть до 1-2 тыс записей.
В архивах очень много ценных документов, которые никто не смотрит десятилетиями, просто по той причине, что люди о них не знают. Например, я недавно смотрел ценный документ 17 века, который до меня с 1917года не посмотрел ни один человек... В заголовках дел в описи может быть много интересного. Например, почти по каждому уезду сохранились фонды, хранящие судебные дела. Заголовки в описи примерно такие: "Дело об оскорблении мещанина Иванова Ивана Ивановича мещанином Петровым П.П", "Дело о взыскании купцом Ивановым И.И. долга с ....", "Дело о духовном завещании купца ... своего состояния такой-то церкви и открытия при ней богадельни", "Дело крестьян деревни такой-то к ...". Ходатайства, обвинения, личные дела учащихся, служащих, арестованных итп. Все варианты заголовков не перечисляю. Их огромное количество. Даже в заголовках уже много ценной генеалогической информации. А если кто-то нашел нужный заголовок, то он может дополнительно в архиве посмотреть или удаленно заказать копию дела. А в одном таком деле может быть информации о предке больше, чем во всех остальных источниках.
Я понимаю, что для Яндекса задача распознавания описей в приоритетах далеко не на первых строчках. Но, может быть, когда-нибудь вы и на нее обратите внимание. С технической точки зрения распознавание таких документов намного проще распознавания метрик. Очень многие описи напечатаны на печатной машинке или в типографии, а более старые описи, хоть и написаны от руки, но обычно написаны "современным" почерком и в большинстве случаев имеют четкую структуру.
@anazarta Спасибо вам за замечательный проект! В моем случае качество распознания Яндексом и количество находок на очень высоком уровне. Уверен, что мелкие недочеты будут исправлены в бушующих версиях.
В каталоге Яндекса загружено 7155 дел ЦГА Москвы. В то же время на сайте самого ЦГАМ без учета дел иных конфессий выложено 10647 книги. Т.е. у Вас в каталоге всего около 67% от уже оцифрованных дел ЦГАМ. Многие пользователи пишут, что иногда Яндекс не находит то, что нашел Генотек. Полагаю, что, после добавления в ваш каталог ~3,5 тысяч нераспознанных дел вопросов о том, что Яндекс что-то пропустил, не останется. Подскажите, когда планируете добавить уже отсканированные дела ЦГА Москвы?
Полную статистику по количеству доступных online дел ЦГА Москвы в разрезе по фондам, описям, обновлениям и др. можно посмотреть на сайте https://epoisk.ru/ . Больше двух лет я занимаюсь регулярным сбором, обработкой и анализом данных по доступным делам ЦГА Москвы (метрические книги итп). Сначала публиковал собранные данные в открытом доступе в удобных excel-таблицах, а полтора месяца назад, чтобы еще больше облегчить поиск, разработал и запустил этот сайт. По ФИО он не ищет, но по описаниям и реквизитам дел ищет лучше и удобнее, чем какие-либо другие сайты.
Два похожих навигатора нарушают принцип DRY, соблюдение которого требуют большинство работодателей.
Я не удивлюсь, если эти навигаторы в Яндексе разрабатываются параллельно двумя разными командами, которые подсматривают новые идеи друг у друга и пишут код для каждой фичи дважды.
Реальный пример можете привести такого "развития межнационального бизнеса и обогащения культуры обеих стран", особенно со специалистами, уехавшими в "недружественные страны"?
Несколько человек и я в том числе спрашивали про собственную оценку в реальных исследованиях. Отвечаю.
Я попробовал для начала дать одну среднюю по сложности задачу, но которая выполнялась плану, в который другая LLM ранее внесла основные требования. Результат мне очень понравился и я подумал, что Grok 4.5 может стать одной из моих рабочих LLM.
После этого я дал Гроку ссылку на локальный бэклог и попросил выполнить 10 задач с указанными номерами. Все задачи выполнялись на максимальных настройках грока. Задачи были на питоне и их уровень не сложный, можно сказать даже часто простой. В результате из 10 задач одна была решена с критической ошибкой, две задачи были решены сомнительно, одна из простых задач была решена хоть и с безобидной, но с "детской" ошибкой. Сомнения в результатах выполнения у меня возникли сразу и я попросил другую LLM курсора Composer 2.5 сделать ревью комитов. В результате компоузер, который позиционируется как более простая по отношению к гроку модель, нашел все его ошибки и четко расписал. Итого я оставил из десяти шесть коммитов без изменений, два откатил полностью и в двух попросил композера исправить ошибки.
Пример критической ошибки. Есть сайт на фреймворке django. Этот фреймворк для всех LLM очень хорошо изучен. Раньше у меня для так называемых view - которые рендерят страницу, было кэширование полной страницы. Потом на сайте добавились пользователи и поскольку контент зависит от пользователя, я декоратор кэширования закомментировал и прямо в тех же строках указал причину. В бэклоге пункт, который выполнял грок, был ранее сформулирован другой llm как рекомендация по улучшению и звучал примерно так - вернуть закомментированное кэширование, там, где это безопасно и не поломает отображение страниц. Гроку в двух местах намекают, что кэширование может быть опасно, но он раскоментировал декораторы кэширования, добавил еще один декоратор, который не исправляет проблему и закомитил. Результат его действий, гости и боты могут видеть кэшированные страницы залогиненых пользователей. Залогиненные пользователи могут видеть страницы для гостей. Пользователи могут видеть страницы, предназначенные для ботов (где часть ссылок скрыта).
А детская ошибка следующая - нужно было сделать прогрессивную каптчу, которая после трех неправильно введенных паролей усложнялась. Грок это сделал, добавил счетчик, но этот счетчик терял единицу еще до проверки ввода пароля. Т.е. вместо трех попыток давалось только две.
И еще по-мелочи, а в других случаях это могут быть и не мелочи. Грок нарушил инструкцию, которая была указана в agents.md. Там был явный запрет добавлять Курсор в Ко-авторы в коммит месседжах при отправке в репозиторий.
Резюме Гроку 4.5 - как игрушка нормальный, как полноценный топовый инструмент - нет. И я не знаю почему его ставят выше последних моделей опуса и других. Когда не доверяешь LLM, то вместо полноценного вайб-кодинга приходится всё перепроверять самому или через ревью другими llm, выполнять промпты повторно, исправлять ошибки итп. Это очень утомляет и занимает много времени. Для сравнения Composer'у 2.5 от курсора я доверяю. Да Компоузер иногда делает ошибки, да компоузер не всегда может соревноваться с последним опусом, но ошибки компоузера встречается не часто и в гораздо более сложных задачах чем у Грока 4.5, а вгрызается он в суть процессов гораздо глубже. В общем пока моя рабочая лошадка остается Composer'у 2.5, а для самых сложных задач использую последние Claude Opus (сейчас 4.8) с настройками High.
Интересно, как компании, проводящие тесты, могут гарантировать их не-утечку?
Если набор тестов одинаковый, то значит и промпты должны быть одинаковые. И, если взять одну компанию, например, Anthropic, то она должна была получать промпты при выходе каждой версии Opus, Sonet, Fable итп.
И все, что нужно сделать этой компании, после выхода каждой модели в течение 1-2 недель отслеживать все промпты. Дальше отбирать повторяющиеся, отсеивать простые итп. И даже если запросы идут по отдельности с разных адресов, рано или поздно набор "независимых тестов" можно вычислить. А дальше уже дело техники. Сажаешь условного "индуса", который будет каждую нерешенную проблему разбирать долгими ночами и обучать модель, как именно ее нужно решать.
А еще помните, как бывает? Модель в закрытом доступе, а результаты бенчмарков уже опубликованы. Для той же Anthropic это означает, что из 100 пользователей, которым дали ранний доступ, несколько "пользователей" шлют задачи из бенчмарка.
Уточнение только: модель самого курсора называется не Cursor 2.5, а Composer 2.5. Пользуюсь ей постоянно и она действительно очень хороша и дешева. Курсор дает на модель Composer 2.5 отдельный лимит, который я на "тройной" подписке (Pro+ за 60$) ни разу ни смог выбрать, при том что ежемесячно использую около 500млн токенов только на этой модели. Grok 4.5 включили в этот же отдельный лимит, который идет "бонусом" к лимиту на все остальные модели (Claude, ChatGPT итп).
Composer 2.5 мне настолько нравится, что даже опасаюсь вместо него пробовать Grok 4.5 в текущих задачах. Хотелось бы дождаться отзывов реальных пользователей.
Кстати, совет тем, кто захочет попробовать курсор впервые. Можно найти реферальную ссылку от текущих пользователей и тогда первый месяц будет в два раза дешевле (10$ за подписку 20$ или 30$ за подписку 60$).
Хотя я сам нахожусь в РФ у меня курсор по умолчанию подключается через Эстонию, иначе модели Claude в курсоре могут не работать. Проверил прямо сейчас - по прежнему новый Grok не доступен. Отключил "прокси" и перезапустил IDE - Grok 4.5 появился. Включил прокси обратно и перезапустил IDE - Grok опять пропал.
Опытным путем установлено, что в европейских странах Грок 4.5 пока отключили, а в США и в РФ он появился. Неожиданное разделение стран. ))
А это ссылка, по которой сам курсор предлагает узнать дополнительные подробности https://cursor.com/blog/grok-4-5
А причина задержки в Европе вот в чем:
Grok 4.5 is not yet available in the European Union in accordance with the EU AI Act.Cсылка на EU AI Act.
Тоже использую платную подписку Cursor и тоже не вижу новой модели. Установил последнюю версию IDE - это ничего не меняет.
Я думаю причина вот в этом (цитата из анонса по ссылке в статье):
Note: Grok 4.5 is not yet available in the EU in any SpaceXAI products or the API console. EU availability is expected in mid-July.Т.е. если подключаетесь с европейских IP адресов, то, вероятно, модель появится в IDE в "середине июля". Либо можно попробовать зайти через vpn с американским Ip-адресом. Сообщение выше как раз подтверждает эту версию.
Большинство услуг Роспатента, включая регистрацию программ для ЭВМ переносится на сайт госуслуг. Обновленный функционал Роспатента на госуслугах находится на этапе тестирования и момент переключения осталось ждать не долго. Переключают поэтапно и что-то могут через пару недель переключить, а что-то через пару месяцев.
Для решения этой проблемы мы можем использовать нейросети с большим контекстным окном (Gemini 3, Claude 3).Это что за нейросети? Особенно вторая интересует. Где ее найти и как к ней подключиться?Противоположный пример. У меня жена привязала apple_id к телефону, потом по какой-то причине, наверное, вышла из этой учетки и год или два пользовалась тем же телефоном, не входя в apple_id. Apple учетку заблокировала и теперь невозможно даже восстановить пароль при том, что к почте, на которую зарегистрирована учетка доступ есть.
В результате телефон превратился в кирпич. Зайти по apple_id нельзя, сменить его на том же телефоне нельзя, продать телефон нельзя итп. Год назад купили новый айфон и был выбор - или все с нуля заводить или перенести данные через резервную копию со старого, но с нерабочим apple_id. Перенесли через копию. Теперь новый телефон работает без apple_id, каждые ХХ минут просит пароль итп.
И теперь на новом телефоне остается выбор - или ограниченный функционал и постоянные просьбы ввести пароль или все снести и поставить заново. А чтобы снести все, нужно 300-400Гб данных через медленный интерфейс куда-то сохранить, а потом попробовать часть вернуть на телефон вручную. Очень “уважаю” в этом плане политику Apple.
del
На поле боя сейчас все идет к тому, что одни роботы будут сражаться с другими роботами.
А на рынке рекрутинга видимо скоро придем к тому, что одни LLM будут собеседовать других.
Предположим, что большая часть агентств заведут LLM системы, которые будут гарантировано обзванивать кандидатов, отправивших свои резюме. Зная это, кандидаты должны у себя настраивать свои LLM системы, которые будут максимально эффективно отвечать на входящие звонки/опросы, но при этом не будут уведомлять, что это робот.
И тогда процесс для кандидата будет следующий - накидал своей LLM пару абзацев чернового текста "о себе". LLM все красиво оформила разослала резюме в 100 компаний, которые сама отобрала по различным критериям. После этого LLM ответила на 100 голосовых опросов. А кандидат, живой человек, через пару дней получает 5 предложений на финальное собеседование из тех компаний, где он прошел предварительный отбор. При этом LLM кандидата ранжирует все прошедшие предложения по уровню дохода, удалению работодателя, режиму работы и дает сводку, как она отвечала на вопросы LLM работодателя. И при этом не требуется джуна представлять сеньором, а просто нужно при его описании выжать максимум из его положительных сторон и нивелировать его слабые стороны.
Конечно финальное собеседование с живым рекрутом отсеет часть кандидатов. Но для кандидата шансы получить место все равно гораздо выше, когда его уже пригласили на несколько интервью как одного из "лучших", чем когда такого кандидата вообще никуда не зовут месяцами...
Интересная статья. Спасибо.
Подскажите, а как решается вопрос с персональными данными? Здесь и сбор, и обработка, и хранение и трансграничная передача данных.
Сначала мы хранили все в Google Таблицах, но довольно быстро уперлись в ограничения такого подхода.Мы используем GPT-4.1Например, как выполнить это требование “трансграничная передача допустима только после уведомления Роскомнадзора, если обеспечивается защита прав субъектов”?
Конечно вы можете ответить, что гугл-таблицы в прошлом, а LLM еще вчера переключили на российскую... Российские LLM справляются с задачей и по сути и по скорости так же хорошо, как ChatGPT?
Вероятно, что большая часть отечественного ПО, особенно нового, будет писаться и дорабатываться с помощью иностранных AI-агентов. И даже разработчик такого ПО может понятия не иметь, на сколько процентов его код похож на какой-то открытый репозиторий, на котором ранее обучалась LLM модель.
Во время своей работы с ИИ я во многом делаю все противоположно тому, что советуется в статье, и получаю прекрасный результат. Я пишу промпт подробно и часто получаю то, что мне нужно, с первого раза. Секрет успеха в моем случае - подробный промпт и использование топовых моделей, даже для относительно несложных задач. Обычно я использую Claude Opus 4.5/4.6/4.7 в режиме Thinking. На этом можно было бы поставить точку.
Результат обычно настолько хорош, что в большинстве случаев его можно даже не проверять. Правила типа “не переписывай остальной код” зачастую не требуется писать в промптах. Для указанных выше моделей это часто избыточно, а если все равно хочется на этом сделать акцент, то это делается один раз в agents.md внутри проекта, либо в глобальных правилах. Использовать умышлено два языка - это перебор. Я всегда пишу на русском и согласно глобальных правил получаю ответы на русском. Если модель внутри размышлений думает на английском, я ее не ограничиваю.
Уже много раз сталкивался с тем, что лучше один раз потратить цену условно 5x, чем выбрать более простую модель и написать ей пять запросов по цене 2x. В конечном итоге выходит экономия и времени и денег.
А если выбирать модели попроще, то тогда да, требуется их всегда ограничивать, направлять, перенаправлять, наставлять итп. Пишем короткий промпт - ждем минуту результат - анализируем его и проверяем - указываем на ошибки и пишем короткое уточнение. Повторяем 5-10 раз, понимаем, что больше нет сил допиливать и результат уже доведен до состояния “и так сойдет”. А если изначально нужно было реализовать архитектурное решение, то неправильный выбор ИИ-моделью стратегии и многократное допиливание результата с помощью дополнительных промптов может привести к сложной дилемме. Переделать то, что делал несколько дней, или оставить, как сделал, но потом на протяжении нескольких лет при необходимости доработки, использовать костыли и делать двойную по сложности работу.
Спасибо за совет!
Про django-cacheops раньше не слышал. Решил попробовать.
10 минут на настройку (с учетом того, что redis у меня уже был настроен) и всё летает в автоматическом режиме.
Там, где я раньше тратил очень много времени на добавление в коде кэширования представлений (view), кусков шаблонов, специально выделенных для кэширования функций итп, при наличии этого плагина можно было ничего не делать. У меня на сайте, как думаю и у многих, вся тяжесть работы и замедление формирования страниц связаны с БД. После того, как включил кэширование запросов к БД, сайт получил вторую молодость.
А ведь в django-cacheops есть еще куча других разных фич. Например, есть удобное кэширование функций с помощью декоратора, чего нет в Django из коробки (Django только view-функции примерно так кэширует), и многое другое.
@anazarta Благодарю вас, за то, что начали добавлять новые дела по ЦГА Москвы. Прошу обратить внимание ещё вот на какой момент.
Сейчас по ЦГА Москвы Яндексом загружено ~7+тыс дел. Предположим, я сделал десятки разных запросов по всем фамилиям и нашел 100 полезных записей. Через месяц Яндекс добавит еще ~тысячу новых дел. Я повторю свои запросы и найду 110 интересных записей. Из них всего 10 новых. При этом, чтобы понять, где новые находки, а где старые, нужно пересмотреть практически каждую картинку из найденных 110шт. Еще через месяц Яндекс загрузит еще тысячу дел. И придется опять и опять все пересматривать повторно изображения, чтобы найти несколько новых записей. И так до бесконечности.
Было бы удобно, если бы Яндекс как-то помечал новые дела или позволял их фильтровать по дате добавления. Например, если бы был фильтр "Отобразить дела добавленные за последний месяц" или за три месяца, или за произвольный период - это было бы очень удобно. Можно было бы искать только в тех делах, которые ранее не просматривались.
@anazarta Александр, примите в качестве идеи на будущее. У архивов есть большое количество описей дел, которые хранятся в их фондах. Небольшая часть из этих описей переведена в "текстовый" вид, по которому можно проводить поиск. Но бОльшая часть остается "нераспознанной".
К примеру, на сайте ЦГА Москвы выложено ~5500 отсканированных описей в формате PDF и это количество увеличивается. Из всего этого объема, я думаю, текстовый поиск доступен в лучшем случае в ~10%. В каждой описи может быть от нескольких страниц, до нескольких сотен страниц. На одной странице описи может быть до 10-20 заголовков единиц хранения. Т.е. в одной описи максимум может быть до 1-2 тыс записей.
В архивах очень много ценных документов, которые никто не смотрит десятилетиями, просто по той причине, что люди о них не знают. Например, я недавно смотрел ценный документ 17 века, который до меня с 1917года не посмотрел ни один человек... В заголовках дел в описи может быть много интересного. Например, почти по каждому уезду сохранились фонды, хранящие судебные дела. Заголовки в описи примерно такие: "Дело об оскорблении мещанина Иванова Ивана Ивановича мещанином Петровым П.П", "Дело о взыскании купцом Ивановым И.И. долга с ....", "Дело о духовном завещании купца ... своего состояния такой-то церкви и открытия при ней богадельни", "Дело крестьян деревни такой-то к ...". Ходатайства, обвинения, личные дела учащихся, служащих, арестованных итп. Все варианты заголовков не перечисляю. Их огромное количество. Даже в заголовках уже много ценной генеалогической информации. А если кто-то нашел нужный заголовок, то он может дополнительно в архиве посмотреть или удаленно заказать копию дела. А в одном таком деле может быть информации о предке больше, чем во всех остальных источниках.
Я понимаю, что для Яндекса задача распознавания описей в приоритетах далеко не на первых строчках. Но, может быть, когда-нибудь вы и на нее обратите внимание. С технической точки зрения распознавание таких документов намного проще распознавания метрик. Очень многие описи напечатаны на печатной машинке или в типографии, а более старые описи, хоть и написаны от руки, но обычно написаны "современным" почерком и в большинстве случаев имеют четкую структуру.
@anazarta Спасибо вам за замечательный проект! В моем случае качество распознания Яндексом и количество находок на очень высоком уровне. Уверен, что мелкие недочеты будут исправлены в бушующих версиях.
В каталоге Яндекса загружено 7155 дел ЦГА Москвы. В то же время на сайте самого ЦГАМ без учета дел иных конфессий выложено 10647 книги. Т.е. у Вас в каталоге всего около 67% от уже оцифрованных дел ЦГАМ. Многие пользователи пишут, что иногда Яндекс не находит то, что нашел Генотек. Полагаю, что, после добавления в ваш каталог ~3,5 тысяч нераспознанных дел вопросов о том, что Яндекс что-то пропустил, не останется. Подскажите, когда планируете добавить уже отсканированные дела ЦГА Москвы?
Полную статистику по количеству доступных online дел ЦГА Москвы в разрезе по фондам, описям, обновлениям и др. можно посмотреть на сайте https://epoisk.ru/ . Больше двух лет я занимаюсь регулярным сбором, обработкой и анализом данных по доступным делам ЦГА Москвы (метрические книги итп). Сначала публиковал собранные данные в открытом доступе в удобных excel-таблицах, а полтора месяца назад, чтобы еще больше облегчить поиск, разработал и запустил этот сайт. По ФИО он не ищет, но по описаниям и реквизитам дел ищет лучше и удобнее, чем какие-либо другие сайты.
Два похожих навигатора нарушают принцип DRY, соблюдение которого требуют большинство работодателей.
Я не удивлюсь, если эти навигаторы в Яндексе разрабатываются параллельно двумя разными командами, которые подсматривают новые идеи друг у друга и пишут код для каждой фичи дважды.
Реальный пример можете привести такого "развития межнационального бизнеса и обогащения культуры обеих стран", особенно со специалистами, уехавшими в "недружественные страны"?