Противоположный пример. У меня жена привязала 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, соблюдение которого требуют большинство работодателей.
Я не удивлюсь, если эти навигаторы в Яндексе разрабатываются параллельно двумя разными командами, которые подсматривают новые идеи друг у друга и пишут код для каждой фичи дважды.
Реальный пример можете привести такого "развития межнационального бизнеса и обогащения культуры обеих стран", особенно со специалистами, уехавшими в "недружественные страны"?
Я тоже думаю, что правильно было бы в самом начале куда-нибудь в кювет свернуть и отделаться легким испугом и незначительными повреждениями авто. Но предполагаю, что пока скорость была относительно невысокая, условно 30-50км/ч, водитель надеялся справиться с ситуацией. Он ведь заранее не знает, что дальше будет только разгон, а тормоза не работают. А когда машина разгоняется до 100-200км/ч все происходит так быстро, что не каждый может контролировать ситуацию и думать о чем-то кроме выживания в ближайшую секунду. Да и тормозить об здания на скорости 100-200км/ч уже не вариант.
Сам был в чем-то похожей ситуации. Поплыли с семьей на парусном катамаране, принадлежащему другу, на прогулку на водохранилище. Полчаса ветер был минимальный, а когда мы были на середине водохранилища, за несколько секунд ветер стал ураганным. (Позже в новостях покажут, что этот ураган повалил множество "вековых" деревьев.) Я был рулевым и во время разгона думал только о том, как бы удержать и не завалить на бок катамаран. А катамаран нереально разогнался и начинал отрывался от воды. В какой-то момент нос катамарана задрался на 1-2 метра вверх и, думаю, дальше намеревался сделать сальто в воздухе, но каркас катамарана (обе продольные прочные алюминиевые балки) сложился пополам, не выдержав нагрузки. Только чудом никто серьезно не пострадал... После этого добирались вплавь до берега и толкали перед собой обломки бывшего плав. средства. На берегу друг спросил: "А что вы парус не сбросили? Ведь тогда вообще не было бы никаких проблем." А я не знал, что ответить. Поскольку я не "моряк", в момент полета у меня даже мысль такая не возникла. На раздумья не было времени... Вот думаю и водитель Теслы тоже не успел принять правильное в тот момент решение.
В настоящий момент оплата с помощью СБП, это любопытная игрушка, а не необходимая мне "вещь". Она не ускоряет оплату и может пригодиться только, если забыл карты, но под рукой есть телефон. Выяснение нюансов оплаты по телефону банка или через чат банка связано с дополнительной потерей времени. По телефону сначала нужно победить "наберите1, наберите 2, сформулируйте свой вопрос, сформулируйте свой вопрос по другому, прослушайте условия... соединяем с оператором, переключаю на другого оператора итп". В чате тоже сначала нужно победить бота, а потом дождаться подключения оператора, а потом ждать каждый ответ. У меня карты трех банков. У всех банков могут быть разные условия. Мне легче достать карту из кармана и оплатить ей, чем тратить время на общение с банками.
Думал попробовать СБП, но из-за того, что пользуюсь в основном кредиткой, всегда возникало внутреннее сомнение, которое предостерегало от этого шага. А вопрос у меня вот какой возникал - Не посчитают ли случайно оплату кредитной картой через СБП операцией, приравнивающейся к снятию наличных? Раз используется СБП, технически это может ведь пройти и как перевод с карты (на какой-то счет, на карту итп), а не как обычная покупка в магазине. Скорее всего, приравнивать к снятию наличных не должны, но это нигде не разъясняется и пока не попробуешь, не узнаешь.
Привлечение покупателей скидками - это хорошо, но дополнительные разъяснения и информирование от платежной системы о всех нюансах нового способа оплаты были бы кстати. Банки то не спешат с информированием своих клиентов о особенностях оплаты с помощью СБП, поскольку теряют при такой оплате часть прибыли.
Оплата наличными через терминал - обычно это почти безналичная оплата. Продавец получает безналичные деньги на свой расчетный счет, причем не от физлица, а от юр.лица, которому принадлежит терминал. Покупатель с таким же успехом мог положить деньги на свой счет через терминал и опалить покупку картой. Но, видимо, есть люди с кучей кэша, которые не хотят светить свои большие покупки. Через карту все покупки физлица фиксируются, а через обезличенный взнос в терминале - нет.
Ваши аргументы убедительны. Но тем не менее, представим абонента Билайна, который хочет пополнить свой мобильный счет где-то. Откуда он знает какой будет merchant_name при оплате на сайте билайна или при оплате через другие ресурсы? Может это будет BEELINE, а может и «BEELINE AVTO». Пока не проверишь, не узнаешь. Разбираться, что такое "AVTO" никому не интересно. Может это что-то про автомобили, может про автоплатеж, а может это вообще любой платеж. А значит опять при оплате возникает ощущение возможного подвоха. Кроме того, если посмотреть ниже в списке операций, приравненных к снятию наличных, там есть Мегафон без всяких оговорок. Да, на Мегафон нельзя платить только с бизнес карт, но это еще один повод задуматься, а не изменится в какой-то момент это примечание. Вы же не проверяете ежемесячно приложения к тарифам... Это как в анекдоте с ложечками - "ложки-то нашлись, а осадочек остался".
Небольшое дополнение к предыдущему сообщению. Первая ссылка про квазикэш ведет в раздел Тинькофф-Бизнес (это для ИП и организаций). Но тоже самое относится и к физлицам.
А вот здесь на сайте Тинькова представлен "Полный перечень операций, приравненных к снятию наличных" https://acdn.tinkoff.ru/static/documents/docs-operations-list-with-other-credit-institution.pdf . Читаем с самого начала коды МСС приравненные к снятию наличных (1. Расходные операции с использованием любой Карты): MCC (4814)... Ниже в том же документе представлена расшифровка: 4814 — оплата мобильной связи, Интернета и телекоммуникаций, коммунальных услуг.
"Какая комиссия за квазикэш? В рамках каждого тарифа есть бесплатный лимит на квазикэш. Это 1000, 3000 или 15 000 ₽ на Простом, Продвинутом и Профессиональном тарифах соответственно. Все, что переводите сверх лимита, — с комиссией как за снятие наличных... ". Комиссию за снятие наличных с кредитки описывал выше. Для дебетовых карт это не имеет значения.
С какого-то времени у Тинькова появился бесплатный лимит на квазикэш. Я пользуюсь их картами с 2017года и раньше такого бесплатного лимита не было. Однажды в начале пользования кредиткой попав на приличную комиссию за пополнения мобильного в стороннем приложении мне больше не хочется экспериментировать, даже если теоретически сейчас уложусь в бесплатный лимит или что-то в правилах поменялось. Ежемесячно мне нужно платить за связь 1200руб. Разбираться, какой у меня тариф (простой, продвинутый итп) мне не интересно. Тарифы меняются, дополнения к тарифам тоже меняются. Мне легче платить за мобильный через приложение Тинькова без комиссии или платить картой другого банка, чем каждый раз при оплате "на стороне" думать попаду я на "штрафные" или нет.
Противоположный пример. У меня жена привязала 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, соблюдение которого требуют большинство работодателей.
Я не удивлюсь, если эти навигаторы в Яндексе разрабатываются параллельно двумя разными командами, которые подсматривают новые идеи друг у друга и пишут код для каждой фичи дважды.
Реальный пример можете привести такого "развития межнационального бизнеса и обогащения культуры обеих стран", особенно со специалистами, уехавшими в "недружественные страны"?
Я тоже думаю, что правильно было бы в самом начале куда-нибудь в кювет свернуть и отделаться легким испугом и незначительными повреждениями авто. Но предполагаю, что пока скорость была относительно невысокая, условно 30-50км/ч, водитель надеялся справиться с ситуацией. Он ведь заранее не знает, что дальше будет только разгон, а тормоза не работают. А когда машина разгоняется до 100-200км/ч все происходит так быстро, что не каждый может контролировать ситуацию и думать о чем-то кроме выживания в ближайшую секунду. Да и тормозить об здания на скорости 100-200км/ч уже не вариант.
Сам был в чем-то похожей ситуации. Поплыли с семьей на парусном катамаране, принадлежащему другу, на прогулку на водохранилище. Полчаса ветер был минимальный, а когда мы были на середине водохранилища, за несколько секунд ветер стал ураганным. (Позже в новостях покажут, что этот ураган повалил множество "вековых" деревьев.) Я был рулевым и во время разгона думал только о том, как бы удержать и не завалить на бок катамаран. А катамаран нереально разогнался и начинал отрывался от воды. В какой-то момент нос катамарана задрался на 1-2 метра вверх и, думаю, дальше намеревался сделать сальто в воздухе, но каркас катамарана (обе продольные прочные алюминиевые балки) сложился пополам, не выдержав нагрузки. Только чудом никто серьезно не пострадал... После этого добирались вплавь до берега и толкали перед собой обломки бывшего плав. средства. На берегу друг спросил: "А что вы парус не сбросили? Ведь тогда вообще не было бы никаких проблем." А я не знал, что ответить. Поскольку я не "моряк", в момент полета у меня даже мысль такая не возникла. На раздумья не было времени... Вот думаю и водитель Теслы тоже не успел принять правильное в тот момент решение.
В настоящий момент оплата с помощью СБП, это любопытная игрушка, а не необходимая мне "вещь". Она не ускоряет оплату и может пригодиться только, если забыл карты, но под рукой есть телефон. Выяснение нюансов оплаты по телефону банка или через чат банка связано с дополнительной потерей времени. По телефону сначала нужно победить "наберите1, наберите 2, сформулируйте свой вопрос, сформулируйте свой вопрос по другому, прослушайте условия... соединяем с оператором, переключаю на другого оператора итп". В чате тоже сначала нужно победить бота, а потом дождаться подключения оператора, а потом ждать каждый ответ. У меня карты трех банков. У всех банков могут быть разные условия. Мне легче достать карту из кармана и оплатить ей, чем тратить время на общение с банками.
Думал попробовать СБП, но из-за того, что пользуюсь в основном кредиткой, всегда возникало внутреннее сомнение, которое предостерегало от этого шага. А вопрос у меня вот какой возникал - Не посчитают ли случайно оплату кредитной картой через СБП операцией, приравнивающейся к снятию наличных? Раз используется СБП, технически это может ведь пройти и как перевод с карты (на какой-то счет, на карту итп), а не как обычная покупка в магазине. Скорее всего, приравнивать к снятию наличных не должны, но это нигде не разъясняется и пока не попробуешь, не узнаешь.
Привлечение покупателей скидками - это хорошо, но дополнительные разъяснения и информирование от платежной системы о всех нюансах нового способа оплаты были бы кстати. Банки то не спешат с информированием своих клиентов о особенностях оплаты с помощью СБП, поскольку теряют при такой оплате часть прибыли.
Оплата наличными через терминал - обычно это почти безналичная оплата. Продавец получает безналичные деньги на свой расчетный счет, причем не от физлица, а от юр.лица, которому принадлежит терминал. Покупатель с таким же успехом мог положить деньги на свой счет через терминал и опалить покупку картой. Но, видимо, есть люди с кучей кэша, которые не хотят светить свои большие покупки. Через карту все покупки физлица фиксируются, а через обезличенный взнос в терминале - нет.
Ваши аргументы убедительны. Но тем не менее, представим абонента Билайна, который хочет пополнить свой мобильный счет где-то. Откуда он знает какой будет merchant_name при оплате на сайте билайна или при оплате через другие ресурсы? Может это будет BEELINE, а может и «BEELINE AVTO». Пока не проверишь, не узнаешь. Разбираться, что такое "AVTO" никому не интересно. Может это что-то про автомобили, может про автоплатеж, а может это вообще любой платеж. А значит опять при оплате возникает ощущение возможного подвоха. Кроме того, если посмотреть ниже в списке операций, приравненных к снятию наличных, там есть Мегафон без всяких оговорок. Да, на Мегафон нельзя платить только с бизнес карт, но это еще один повод задуматься, а не изменится в какой-то момент это примечание. Вы же не проверяете ежемесячно приложения к тарифам... Это как в анекдоте с ложечками - "ложки-то нашлись, а осадочек остался".
Небольшое дополнение к предыдущему сообщению. Первая ссылка про квазикэш ведет в раздел Тинькофф-Бизнес (это для ИП и организаций). Но тоже самое относится и к физлицам.
Вот ссылки для фйизлиц. Читаем тарифы по самой распространенной кредитной карте https://www.tinkoff.ru/cards/credit-cards/tinkoff-platinum/tariffs/ Ниже приложены разные файлы. И в среди файлов есть тот же "Перечень операций, приравненных к снятию наличных" https://acdn.tinkoff.ru/static/documents/docs-operations-list-with-other-credit-institution.pdf . И там та же самая мобильная связь. Только в тарифах физлиц при беглом просмотре я не вижу "бесплатного лимита на квазикеш". Если бесплатного лимита нет, то тарифы физлиц еще жестче, чем бизнес-тарифы - попасть можно при любом пополнении мобильного в стороннем приложении.
Это не фейк. Тинькофф считает пополнение счета мобильного "Квазикэшем". Вот здесь на их сайте это описано: https://www.tinkoff.ru/business/account/help/withdraw-and-transfer/quasicash/
А вот здесь на сайте Тинькова представлен "Полный перечень операций, приравненных к снятию наличных" https://acdn.tinkoff.ru/static/documents/docs-operations-list-with-other-credit-institution.pdf . Читаем с самого начала коды МСС приравненные к снятию наличных (1. Расходные операции с использованием любой Карты): MCC (4814)... Ниже в том же документе представлена расшифровка: 4814 — оплата мобильной связи, Интернета и телекоммуникаций, коммунальных услуг.
"Какая комиссия за квазикэш? В рамках каждого тарифа есть бесплатный лимит на квазикэш. Это 1000, 3000 или 15 000 ₽ на Простом, Продвинутом и Профессиональном тарифах соответственно. Все, что переводите сверх лимита, — с комиссией как за снятие наличных... ". Комиссию за снятие наличных с кредитки описывал выше. Для дебетовых карт это не имеет значения.
С какого-то времени у Тинькова появился бесплатный лимит на квазикэш. Я пользуюсь их картами с 2017года и раньше такого бесплатного лимита не было. Однажды в начале пользования кредиткой попав на приличную комиссию за пополнения мобильного в стороннем приложении мне больше не хочется экспериментировать, даже если теоретически сейчас уложусь в бесплатный лимит или что-то в правилах поменялось. Ежемесячно мне нужно платить за связь 1200руб. Разбираться, какой у меня тариф (простой, продвинутый итп) мне не интересно. Тарифы меняются, дополнения к тарифам тоже меняются. Мне легче платить за мобильный через приложение Тинькова без комиссии или платить картой другого банка, чем каждый раз при оплате "на стороне" думать попаду я на "штрафные" или нет.