Они могут быть не лишними. Речь идёт о индивидуальном проекте, а не командной разработке. Тут может быть важнее сохранить все этапы. Даже если нет, то жпт не должен был однозначно отвечать Да.
Вот и видно что нет у тебя реального понимания этого инструмента. Плюс ты не умеешь ИИ пользоваться. Как задал вопрос - так и получил. Ты же не спросил про все недостатки и плюсы. А на такой вопрос ответ абсрлютно правильный.
Я вообще ни слова не понял. У тебя есть мастер-ветка. Разрабатывая новую фичу ты создаешь от нее новую ветку, допиливаешь все, тестируешь на дев стэйдже если есть. Потом сквошишь и мержишь в мэйн/мастер. Получаешь чистый мэйн без кучи лишних коммитов, получаешь историю разработки, получаешь возможность переключится на другую фичу. Препод твой не знает гитфлоу, если такое утверждает
Это как раз абсолютно грамотный ответ для того, кто в теме. Почитай про gitflow хотя бы. Тут ИИ оказался грамотнее тебя) У бранчей гораздо болеше возможностей, чем приведенные тут.
Довел свой сервис до рабочего состояния. Теперь можно вернуться в давнему спору, начатому еще в другой теме.
Хочу проверить, на что будет способен ИИ в плане кластеризации. В связи с этим просьба- кто готов поделиться данными? Мне нужно следующее: документ, который содержит сбор семантики по сайту и результирующий документ по кластеризации. Чем больше, тем лучше. Можно из старых загашников, можно урезанные, не включающие в себя коммерческую тайну. нужно на чем-то натренировать сервис. КАк это работает. Сначала загоняются ключевые слова и просто отправляются в SLMs(для проверки работаю с малыми моделями, если получится - можно и что-то серьезнее подключить. Смотрю результаты. Потом с помощью RAG загоняю дополнительные документы и смотрю результат, сравниваю.
В любом формате можно доки - Ворд файлы, пдфки, фотки, система уже обучена все понимать. А, да, нужны англоязычные примеры, языковые модули не подключал пока.
Интересно, какие это ты собираешься использовать БД, что тебе нужно отдельные классы писать?)))Проблема в том что у тебя нет разделения логики и ты не очень понимаешь вообще что это такое. Советовать почитать "Основы алгоритмов " не стану, бесполезно. Помню, спрашивал я у тебя сто такое СОЛИД, ответа ты не знал тогда и не знаешь сейчас, раз не можешь решить такую задачу.
Во-первых, связь с БД должна выть вынесена в адаптер, тогда не придется переписывать все под каждый тип. Нормальные люди используют ОРМ, но это не твой путь. А для получения файлов - отдельный класс, реализация которого не зависит от типа бд.
Во-вторых, хранить нужно минимум данных. Не смешивать служебные и пользовательские файлы. Я бы при загрузке файла создавал бы хэшированное имя и писал его в базу. В таком случае можно не городить папки для пользователя.
И про какие файлы ты говоришь, которые пользователь должен загружать?
Помню, в году так 2010-м сканил книжки и пропускал их через прогу распознавания текста. Потом править приходилось. Нейросети ж не было. Буквы могли быть распознаны не так, а поправить программа не могла. В добавок тире, переходы на новые строки создавали проблемы. Править надо было вручную.
Но чтобы все это происходило автоматом, там проработка "ИИ" должна быть весьма детальная. Распознавание опечаток (неправильно распознанных букв) в отдельных словах - это самое простое. Выборка из контекста графики, переносы, абзацы - эта обработка уже сложнее.
В начале 2000-х купил себе крутой сканер, который даже негативы цветные умел сканить в фото и там был FineReader к комплекте. Хорошая штука, но с нынешним Тессарактом не сравнить. Английский распознает почти идеально, даже в местах излома страниц и если тень попала. Вот с белорусским подкачал, не знает букву "Ы" например))) Но возможно, нужно подгружать языковые модули.
Это работает только со специфичными документами - накладными, фактурами. Умеет вносить данные по шаблону.
Мой сервис имеет другую направленность совершенно, умеет распознавать любые документы в любых форматах ну и главное - обрабатывать информацию.
Да и опять же, вроде как говорим а возможностях, что можно сделать с использованием ИИ, а не "А, это уже есть..."
И я не говорю про коммерческую направленность.
Можешь рассказать, как что-то из приведенных мною примеров у вас реализовано на основе 1С? Очень любопытно.Теперь мои новости)Поняв, что многие документы имеются в виде картинок, вспомнил, про еще одну возможность нейросетей - распознавание обьектов, в частности текста. Поэтому прикрутил OCR использующую нейросети - Tesseract. Теперь достаточно загрузить фотку документа в систему, дальше она сама преобразует в ПДФ, потом обработает документ, создаст эмбеддинги, закинет все это в векторную базу. Теперь при работе я уже могу задавать вопросы и бот будет использовать не только пре-трэйнед модели, но и дополнения с помощью RAG. Пока думаю как это все хранить. Прикручивать еще и векторную базу данных типа Pinecone не очень хочется, у меня и так уже есть скалярный Постгрес и графовая Neo4j. склоняюсь postgres c векторным модулем
У нас с вами разные представления о корпорациях) Но несколько миллионов инвестиций в прошлом году они, насколько я знаю, привлекли.
Фантастика тем и хороша, что в ней можно игнорировать ограничения, которые будут в реальной жизни. В данном случае концепция не задумывается о скорости соединения и об обьемах передаваемой информации.
Я сталкивался с ситуациями, когда казалось бы верное решение, на практике упиралось в проблемы передачи информации.
(Дальше можно не читать кому не интересны технические подробности) Писали сервис обработки создания документов. Заказчик хотел дешево, поэтому предложил использовать амазоновские лямбды. Кто не знает - это небольшой инстанс в спящем режиме. Когда на него приходит запрос - просыпается, делает свое дело, отправляет ответ и снова засыпает. А ты платищь только за время его работы, не как в случае с VPS - все время. По итогу оказалось что вот это время просыпания на холодную превышает все требования закзчика, приходилось держать лямбду всегда горячей, а это лишало всего преимущества.
Это я к чему - децентрализованная система будет ооочень медленной за счет типа соединения и обьема передаваемых данных. Если при серверном поиске ты получаешь информацию с одного источника, то тут тебе нужно создать сотни, если не тысячи соединений для получения результата.
Опять же не существует алгоритмов поиска, оптимизированных под распределенный поиск. Ну и главное - верификация данных. Если в такой сети насоздавать нод с фейковыми данными - как их отличить?
Так что считаю, такое будет возможно реализовать еще не скоро.
