Dimonchik

Вектор и Вектор+ - разные компании поэтому в общем виде задача не решается, решается только вот этими всеми ОКПО / ИНН и т.п.

но полуавтоматом - как описали выше - выбираешьт левенштейном похожие, конфирмишь, и заменяешь автоматом похожие на целевые, при должном подходе их никак не больше 20-50 штук

сначала читать такое
https://mangalib.me/mangadewakaru-senkei-daisu
найдешь в нете или телеге полную версию

там вообще вся серия "Занимательная математика" гуд, но не стоит лезть раньше времени, а вот линейная аглебра для программиста необходима

задача поставлена хреново

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

тут после т.е. явно не только к этому предложению относится

Т.е. все 400 вариантов объектов сейчас заранее достоверно неизвестны, их нет всех сразу в базе данных векторов.

и тут ХПЧ

вообще - нейронки это всегда вероятности (ну кроме выводов ChatGPT который пока дикий, но учится)

попробуйте декомпозировать
и не ждите чудес

reindexer

он завязан на inmemory, но на Го, возможно, алгоритмы подойдут

поиск - это индекс
со всеми "удобствами" навроде перестройки после каждой вставки, ага

берешь Postgre со всеми инмемору наворотами и nosql надстройками
берешь Монго (память, прощай) или Эластик (не, ну не перегибай...)
берешь Manticore

настраиваешь ,тестируешь на реальных данных

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

графовая БД

neo4j - самая известная
ArangoDB - вам подойдет

из пп 2-3 формируете два набора максимальной длины
и затем проходите по ним длинами паролей двигая слева направо с перекрытием по последнему символу

скачай
https://www.ozon.ru/context/detail/id/5497130/

есть отсканированная в сети
там ответы на все вопросы

изначально - все как и пишешь
индекс - это список документов в которое входит слова

два слова - два списка
их пересечение - обычный XOR, хз кто сказал что оно ресурсоемко

а вот уже чтобы ответ был РЕЛЕВАНТЕН - там дофига чего наворочено сверху, что Иван Шумов тебе и пытается объяснить

и да, в современном поиске индекс это список документов соответствующих ВЕКТОРУ запроса

никто его онлайн не делает - все просчитано заранее
онлайн только пытаются свести запрос к наилучшему (нескольким) заренее просчитанным векторам

тю, ну конечно: список, какой-нибудь особенный

ограничите время поиска - и вот Вам ложноотрицательные срабатывания ))

"Грокаем алгоритмы" посмотри, если Кнут не дается

но он и не должен легко даваться

hamming distance чем меньше, тем больше совпадений

вот тут поковыряй
https://benchmarksgame-team.pages.debian.net/bench...
и больше не майся фигней

есть тесты где асинхронный питон быстрее ноды и т.д и т.п.

все слишком многофакторно чтобы делать обобщения вида N быстрее / медленее M
достаточно знать порядок скорости

JS и Питон языки одного уровня и порядка

подойти итерационно

типа ИНДЕКС

проще привязывать к гео-времени

считать почасово + юзерфрендли

юзер начал в 20:35 пользование - начинаем считать с 21:00
лег сервер в 21:35 - считаем что лег в 21:00 и т.д.

допустим целых

хороший прикид

там, случаем, что множители целые "допустим" не отвалилось?

парсят + базы + эвристика

вам же никто доставку не гарантирует ))

в таком формате он норм отсортирует

проблемы начнутся без leading zero