Sly32

Это как раз абсолютно грамотный ответ для того, кто в теме. Почитай про gitflow  хотя бы. Тут ИИ оказался грамотнее тебя) У бранчей гораздо болеше возможностей, чем приведенные тут.

Довел свой сервис до рабочего состояния. Теперь можно вернуться в давнему спору, начатому еще в другой теме. 

Хочу проверить, на что будет способен ИИ в плане кластеризации. В связи с этим просьба- кто готов поделиться данными? Мне нужно следующее: документ, который содержит сбор семантики по сайту и результирующий документ по кластеризации. Чем больше, тем лучше. Можно из старых загашников, можно урезанные, не включающие в себя коммерческую тайну. нужно на чем-то натренировать сервис. КАк это работает. Сначала загоняются ключевые слова и просто отправляются в SLMs(для проверки работаю с малыми моделями, если получится - можно и что-то серьезнее подключить. Смотрю результаты. Потом с помощью RAG  загоняю дополнительные документы и смотрю результат, сравниваю.

В любом формате можно доки - Ворд файлы, пдфки, фотки, система уже обучена все понимать. 
А, да, нужны англоязычные  примеры, языковые модули не подключал пока.

Интересно, какие это ты собираешься использовать БД, что тебе нужно отдельные классы писать?)))
Проблема в том что у тебя нет разделения логики и ты не очень понимаешь вообще что это такое. Советовать почитать "Основы алгоритмов " не стану, бесполезно. Помню, спрашивал я у тебя сто такое СОЛИД, ответа ты не знал тогда и не знаешь сейчас, раз не можешь решить такую задачу. 

Во-первых, связь с БД должна выть вынесена в адаптер, тогда не придется переписывать все под каждый тип. Нормальные люди используют ОРМ, но это не твой путь. А для получения файлов - отдельный класс, реализация которого не зависит от типа бд.

Во-вторых, хранить нужно минимум данных. Не смешивать служебные и пользовательские файлы. Я бы при загрузке файла создавал бы хэшированное имя и писал его в базу. В таком случае можно не городить папки для пользователя. 

И про какие файлы ты говоришь, которые пользователь должен загружать?

В начале 2000-х купил себе крутой сканер, который даже негативы цветные умел сканить в фото и там был FineReader к комплекте. Хорошая штука, но с нынешним Тессарактом не сравнить. Английский распознает почти идеально, даже в местах излома страниц и если тень попала. Вот с белорусским подкачал, не знает букву "Ы" например))) Но возможно, нужно подгружать языковые модули. 

Это работает только со специфичными документами - накладными, фактурами. Умеет вносить данные по шаблону.

Мой сервис имеет другую направленность совершенно, умеет распознавать любые документы в любых форматах ну и главное - обрабатывать информацию.

Да и опять же, вроде как говорим а возможностях, что можно сделать с использованием ИИ, а не  "А, это уже есть..."

И я не говорю про коммерческую направленность. 

Можешь рассказать, как что-то из приведенных мною примеров у вас реализовано на основе 1С? Очень любопытно.

Теперь мои новости)
Поняв, что многие документы имеются в виде картинок, вспомнил, про еще одну возможность нейросетей - распознавание обьектов, в частности текста. Поэтому прикрутил OCR использующую нейросети - Tesseract. Теперь достаточно загрузить фотку документа в систему, дальше она сама преобразует в ПДФ, потом обработает документ, создаст эмбеддинги, закинет все это в векторную базу. Теперь при работе я уже могу задавать вопросы и бот будет использовать не только пре-трэйнед модели, но и дополнения с помощью RAG. 
Пока думаю как это все хранить. Прикручивать еще и векторную базу данных типа  Pinecone не очень хочется, у меня и так уже есть скалярный Постгрес и графовая Neo4j. склоняюсь postgres c векторным модулем

У нас с вами разные представления о корпорациях) Но несколько миллионов инвестиций в прошлом году они, насколько я знаю, привлекли.

Фантастика тем и хороша, что в ней можно игнорировать ограничения, которые будут в реальной жизни. В данном случае концепция не задумывается о скорости соединения и об обьемах передаваемой информации. 

Я сталкивался с ситуациями, когда казалось бы верное решение, на практике упиралось в проблемы передачи информации. 

(Дальше можно не читать кому не интересны технические подробности) 
Писали сервис обработки создания документов. Заказчик хотел дешево, поэтому предложил использовать амазоновские лямбды. Кто не знает - это небольшой инстанс в спящем режиме. Когда на него приходит запрос - просыпается, делает свое дело, отправляет ответ и снова засыпает. А ты платищь только за время его работы, не как в случае с VPS -  все время. 
По итогу оказалось что вот это время просыпания на холодную превышает все требования закзчика, приходилось держать лямбду всегда горячей, а это лишало всего преимущества.

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

Опять же не существует алгоритмов поиска, оптимизированных под распределенный поиск. Ну и главное - верификация данных. Если в такой сети насоздавать нод с фейковыми данными - как их отличить?

Так что считаю, такое будет возможно реализовать еще не скоро.

Ты живешь в своем узком мирке вебмастера и не пытаешься посмотреть шире. А я стараюсь обьяснить это тебе. Вот тебе примеры из моего личного опыта, то над чем я лично работал.

- Проект по обработке архивных документов - данные по геологоразведке. Оказалось, что каждый штат хранит документацию как попало, у всех свой формат. На основе ML наша система могла разобрать самый потрепаный документ и вытянуть из него данные в автоматическом режиме. Это мы делали лет 5-7 назад, еще до всего этого хайпа с АИ.
- Создание контрактов по продаже дилерских и аукционных автомобилей в Америке. Опять же у каждого штата свои форматы документации. Приходилось писать отдельные блоки обработки под каждый штат. Если бы там применить АИ - в раз ы бы было все проще. Впрочем уверен, что счас они к этому уже пришли.

- Это корпоративные примеры. Но есть и из личного. Мой товарищ  открыл стартап в Америке - смарт-закупки. Как только заказчик не присылает свои требование, хорошо, что не голубями. У некоторых даже факсы еще живы)))
И вот все это летит в систему, распознающую это, нет надобности держать огромный отдел клерков, занимающихся вводом документации - все автоматически.

Я мог бы привести тебе массу  аргументов, Почему это не так. Сделаем проще, если тебе интересно. Я все равно работаю сейчас над такой системой. Типа дипломная работа. Когда закончу - дам тебе доступ и ты сам посмотришь, на что она способна.

Я и работаю. Все это - в рамках развития.

Отвечу еще раз. Пример - тебе нужно обрабатывать кучу документов, например результатов тестов, исследований, анализов... Тебе их в день присылают десятками, многостраничных, на разных языках, в разных форматах, а тебе нужно извлечь только пару параметров. Доки могут приходить в любых параметрах - как текстовый файл, как пдф, как картинка просто... Мой сервис сделает тебе  по каждому документу краткое описание и достанет нужный результат. Причем неважно как это прописано в документе - он поймет, расшифрует аббревиатуры и отдаст тебе только то, что ты ищешь. 

Кому? Ну например врачу, исследователю. Учителю упростит работу. Ты загружаешь например параграф по теме и просишь выбрать основные положения темы и сделать опросник - вот тебе готовый тест для учеников по теме... 

У тебя обратный подход))) Я сначала стану специалистом в этой теме, потому смогу обучать) 

Не согласен. Вот ты специалист по замеру окон, но не видишь, как тут можно упростить работу. Я - IT-architect  и я вижу что можно применить. Ты вообще похоже не очень знаешь, как работает все это в современном мире. Вот например ты в курсе, как наша компания получает клиентов?

Абсолютно - да. Более того - Она вытеснит и вытесняет многое в айти.

На сегодня для меня пет-разработка - хобби. Да, с прицелом на будущее. Поэтому и изучаю постоянно что-то новое. Пока же предпочтительнее  работа по найму. В ней одни плюсы.