Эта тема многогранно показана в мультфильме Южный Парк: Присоединение к Пандервселенной. Когда юрист, гидрогеолог и другие представители среднего класса возмущались на несправедливость что ИИ лишил их доходов и вымещали свой гнев на здании колледжа (за обучение в котором они платили).
Тема сегментации пользователей безусловно интересна! Уверен, что студенты о ней особо интересного не думают, ещё мало жизненного опыта и "насмотренности".
В связи с дороговизной эксплуатации систем на основе LLM (типа чатов и агентов) не думаю что возможно долгосрочно поддерживать проект с минимальной стоимостью для пользователя. Здесь могут помочь классические интерфейсы и системы, с небольшими "вкраплениями" LLM с небольшими числом весов.
Отлично! Будет чем поразвлечься, как доберусь. К распознаванию речи я не возвращался с момента использования Dragon Dictate в 1998 году.
Пару недель назад пробовал запустить whisper docker на cuda и coqui-ai TTS но с первой попытки у меня это не заработало. Идея была подключить это к openweb-ui и взаимодействовать с базой данных голосом и слушать результаты.
Когда звук с источника(микрофона) поступает сразу же в пайпалайн обработки, распознаётся и передает распознанный текст так же в виде потока, только символов или токенов в другой пайпалайн.
Например для синхронного перевода с одного языка на другой. Или для взаимодействия с какой-либо программой.
Подскажи есть ли примеры как встроить детектор в пайпалайн потоковой обработки звука? Как я понял что это всего лишь компонент чтобы не обрабатывать тишину и фоновые звуки.
Проблемы в том, что все работники не смогут так сказать. В итоге кто-то будет демпенговать и перерабатывать за небольшую оплату. Свое мнение на этот счёт я недавно высказал.
Когда-нибудь так и будет. А пока программистам работы становится только больше чтобы превратить прототипы в решения пригодные для эксплуатации бизнесом.
В той истории закончилось тем что я попрощался с ними и ушел, не замарав свою трудовую книжку. Ну и конечно это был не оплачиваемый рабочий день для меня - подарил 8 часов своей жизни распильно-откатной конторе.
Нет во втором пункте никакого противоречия, поправил текст так, чтобы можно было не заниматься литературным анализом: <sarkazm_on>Ведь LLM уже делают работу лучше программистов.</sarkazm_on>
Отличная идея для самообслуживания аналитиков! У вас в проекте как понимаю много таких функций создается самими пользователями? Они их как-то версионируют/сдабривают комментариями или это больше для разовых экспрементов с трансформацией данных, а потом разработчики переписывают это на java/scala для переиспользования в разных pipeline?
Ваш комментарий, увы, продолжает прежнюю тенденцию — вы подменяете дискуссию по сути статьи на обсуждение второстепенных технических деталей, игнорируя её основную цель: демонстрацию практического подхода к семантической индексации текстов с использованием локальных LLM моделей и PostgreSQL / pgvector.
>>Примеры кода должны быть хорошими Статья не претендует на роль руководства по идеальному стилю кодирования. Она показывает рабочую реализацию концепции, где фокус — на логике работы системы, а не на соблюдении всех best practices Java-сообщества. Если бы цель была в демонстрации идеального кода, статья превратилась бы в курс по Java-паттернам, а не в разбор ИИ-задачи.
Я принимаю конструктивную обратную связь, но ваш комментарий больше похож на демагогию со сменой контекста обсуждения. Вы сами выбрали свое "соломенное чучело - идеальный код" и пытаетесь дискредитировать содержание этой статьи. Делаете это с помощью указаний на несоответствие кода вашим представлениям о прекрасном.
В итоге в ваших комментариях оффтоп о стиле кода, а не на семантическом поиске и запуске локальных LLM моделей с помощь Spring AI. Статью я написал для тех, кто хочет разобраться, как применить LLM в Java проекте без использования облачных сервисов - API нейросетей.
У меня возникает двоякое чувство, что оба критических комментария похожи на результаты сгенерированые не совсем хорошей моделью по стандартному промпту для критики кода на java. И это даже пока без анализа профилей коментаторов на экспертность в обсуждаемой теме, статистики комментариев по тону, наличию обесценивания и конструктивности.
Ваш комментарий рекомендует распространенную ошибку в разработке систем: слишком большое внимание к следованию предполагаемым «лучшим практикам» без учета конкретного контекста и целей проекта. Я и не претендовал здесь на абсолютную архитектурную чистоту примера и сделал все что считаю полезным написания этого кода.
Вашим советам тут не следует следовать по нескольким причинам...
Для работы с БД стоило использовать spring-jdbc с его пулом коннекций и jdbcTemplate.
Код здесь предназначен для демонстрации примера реализации семантического поиска, а не для готового к производству корпоративного приложения. Основное внимание уделяется иллюстрации концепции, а не соблюдению абсолютно всех практик разработки и модулей фреймворка. Поскольку я автор, то и выбор/баланс что мне использовать из Spring, а что не нужно в этом проекте за мной.
Если в проекте spring boot, почему приложение не построено как классическое boot приложение с разделением на сервисы / репозитории?
Предложение полной архитектуры Spring с сервисами/репозиториями добавит сюда избыточной сложности. Когда потребуется, то я добавлю все необходимые дополнительные абстракции и слои.
Работа с файлами через File устарела на лет 15, давно есть более удобный java.nio.file.Files
Утверждение, что "работа с файлами через File устарела на 15 лет", преувеличено. java.nio.file.Files предлагает определенные преимущества, но java.io.File по-прежнему широко используется и вполне подходит для тех операций с файлами, что используются в этом примере
Для логирования ошибок стоило использовать spring-logging / ломбоковский @slf4j
Вполне возможно, так же как можно подключить сбор стуртурированных логов в OpenTelemetry, добавить трейсинг и сбор метрик для улучшения observability. Тогда это будет совсем другая статья и уровень сложности. И главный вопрос зачем это мне сейчас.
зачем тут обертки? достаточно примитивов float[]
Преобразование упакованного массива необходимо при работе с массивами JDBC, поскольку метод createArrayOf требует массивы объектов, а не примитивные массивы.
Я уже объяснил в предыдущем комментарии, какой я сделал выбор, чтобы сосредоточиться на реализации семантического поиска и тем подходам к расширяемости прототипа что я считаю рациональными, а не на применении здесь всех лучших практик разработки на Java.
Комментарий оставляет двоякое впечатление. С первого взгляда похож на конструктивный вопрос о выборе технологий, но по своему тону и форме выражение больше на попытку обесценить работу автора и завязать спор на эмоциях.
"Тут технология X, а почему не Y?". Краткий мой ответ на вопросы такого типа - это личные предпочтения, основанные на опыте разработки прототипов систем. Бывает что код со временем прототипы превращаются в систему, где важнее читаемость и простота расширения, а не отсутствие фреймворков и внешних зависимостей.
Эта статья иллюстрирует подход, который можно адаптировать под конкретные задачи. Почти любой проект можно реализовать на разных технологиях в зависимости от целей, а в данном случае баланс между образовательной ценностью и "написанием с минимумом фреймворков" казался приоритетным в первом. ИИ для кодинга это вообще отдельная тема про агенты и RAG и совсем не gemma3.
Для минимального примера можно обойтись без Spring и Lombok. Однако цель этой публикации — демонстрация практической реализации с легкой повторяемостью и фокусе на сути идеи, а не на написании кода без использования фреймворков. Spring Boot уменьшает усилия на подключение Ollama в Spring AI и в логику индексации данных. Lombok сокращает boilerplate с сеттерами и try/catch, что важно в статье, где фокус на логике, а не на многословном синтаксисе языка программирования. В образовательных целей такой подход позволяет читателю сосредоточиться на главном.
Выбор TestContainers здесь для быстрого старта примера, без описаний инструкций как запустить и настроить PostgreSQL. Опять же фокус на сути, а не командах развертывания СУБД. Мне был нужен именно PostgreSQL c pgvector для долгосрочного хранения данных и написаний произвольных по сложности запросов, а не Sqlite/H2database итп
Спасибо, про семантический поиск ваш комментарий справедлив хоть и забежал в мою будущую публикацию по этой теме. В этой статье показана базовая реализация индексации текстов, вычисление эмбеддингов, но без интерфейса для пользовательского поиска. Добавление интерфейса — логичный следующий этап, который можно реализовать на основе предложенной архитектуры. Например, можно было бы расширить приложение методом вроде searchByQuery() с использованием этих же эмбеддингов. Дополнил эту статью примером получения вектора SELECT get_embedding('SQL final state machine') для ее логической завершенности.
Проект действительно начался как эксперимент и превратился в прототип, демонстрирующий потенциал локальных LLM для структурирования данных. Я показал, как интегрировать PostgreSQL, Ollama и Java для решения задачи, которая обычно требует облачных сервисов или отдельных pipeline с DS/DevOPS экспертизой. Для меня это комплимент, что сложный функционал удалось реализовать по виду как лабораторную работу, что говорит об умении делать сложное проще для понимания читателями без ущерба для цели проекта.
Конечно, я использую и другие модели в разных задачах, с учётом в том числе и лицензий. Но конкретно в этом сценарии gemma3 лучше всего показала себя, с учётом размера ее контекстного окна / числа параметров.
Т.е. для второй сетки, которая фомирует эмбеддинги, это просто отдельные слова и фразы.
Да, это так. Но верно если только генерировать эмбеддинги только для ключевых слов. В этом примере я подмешиваю ключевые слова к описанию темы.
Из плюсов отдельной LLM и эмбеддинг нейросети - высокая специализация каждой и производительность. А значит можно например убрать "подмешивание" ключевых слов и заменить на подмешивание краткого описания всей статьи в отдельную тему и быстро пересчитать.
Ваше предложение действительно рабочее для генерации эмбеддингов для исходных кодов программ, там также важно и большее контекстное окно, так как в отличии от обычного текста - без ущерба не разделить большой метод на независимые фрагменты.
у нас был лайфхак - ходить на спортивные площадки с резиновым покрытием, которые никто не занимает в осеннюю погоду вечерами. Но здесь таких площадок нет.
И это не единственный минус места где я живу, есть еще, но больше конечно плюсов. И этой информацией я бы мог делиться с людьми, которые ищут свое уютное место. Но как и где непонятно.
А проще было бы проставить в OpenStreetMap типы покрытия в городе спортивным площадкам и доставать потом запросом leisure=pitch AND surface=acrylic или же (tartan, clay) чем полагаться на отзывы.
Эта тема многогранно показана в мультфильме Южный Парк: Присоединение к Пандервселенной. Когда юрист, гидрогеолог и другие представители среднего класса возмущались на несправедливость что ИИ лишил их доходов и вымещали свой гнев на здании колледжа (за обучение в котором они платили).
Уже начали перепаивать чипы памяти, как было для RTX4090 с 48Гб? У этих 64 Гб?
Тема сегментации пользователей безусловно интересна! Уверен, что студенты о ней особо интересного не думают, ещё мало жизненного опыта и "насмотренности".
В связи с дороговизной эксплуатации систем на основе LLM (типа чатов и агентов) не думаю что возможно долгосрочно поддерживать проект с минимальной стоимостью для пользователя. Здесь могут помочь классические интерфейсы и системы, с небольшими "вкраплениями" LLM с небольшими числом весов.
Отлично! Будет чем поразвлечься, как доберусь. К распознаванию речи я не возвращался с момента использования Dragon Dictate в 1998 году.
Пару недель назад пробовал запустить whisper docker на cuda и coqui-ai TTS но с первой попытки у меня это не заработало. Идея была подключить это к openweb-ui и взаимодействовать с базой данных голосом и слушать результаты.
Когда звук с источника(микрофона) поступает сразу же в пайпалайн обработки, распознаётся и передает распознанный текст так же в виде потока, только символов или токенов в другой пайпалайн.
Например для синхронного перевода с одного языка на другой. Или для взаимодействия с какой-либо программой.
Спасибо, поизучаю и этот подход!
@snakers4 спасибо!
Подскажи есть ли примеры как встроить детектор в пайпалайн потоковой обработки звука? Как я понял что это всего лишь компонент чтобы не обрабатывать тишину и фоновые звуки.
Проблемы в том, что все работники не смогут так сказать. В итоге кто-то будет демпенговать и перерабатывать за небольшую оплату. Свое мнение на этот счёт я недавно высказал.
Вот только хорошо платить за разгребание за вайбкодерами вряд ли кто будет. С точки зрения работодателя: все же почти готово в коде...
Когда-нибудь так и будет. А пока программистам работы становится только больше чтобы превратить прототипы в решения пригодные для эксплуатации бизнесом.
В той истории закончилось тем что я попрощался с ними и ушел, не замарав свою трудовую книжку. Ну и конечно это был не оплачиваемый рабочий день для меня - подарил 8 часов своей жизни распильно-откатной конторе.
Нет во втором пункте никакого противоречия, поправил текст так, чтобы можно было не заниматься литературным анализом: <sarkazm_on>Ведь LLM уже делают работу лучше программистов.</sarkazm_on>
Было бы полезно автоматически публиковать часть таких метрик по конфигурации в OpenTelemetry метрики для мониторинга приложения!
Отличная идея для самообслуживания аналитиков! У вас в проекте как понимаю много таких функций создается самими пользователями? Они их как-то версионируют/сдабривают комментариями или это больше для разовых экспрементов с трансформацией данных, а потом разработчики переписывают это на java/scala для переиспользования в разных pipeline?
Спасибо, статью отредактировал.
Ваш комментарий, увы, продолжает прежнюю тенденцию — вы подменяете дискуссию по сути статьи на обсуждение второстепенных технических деталей, игнорируя её основную цель: демонстрацию практического подхода к семантической индексации текстов с использованием локальных LLM моделей и PostgreSQL / pgvector.
>>Примеры кода должны быть хорошими
Статья не претендует на роль руководства по идеальному стилю кодирования. Она показывает рабочую реализацию концепции, где фокус — на логике работы системы, а не на соблюдении всех best practices Java-сообщества. Если бы цель была в демонстрации идеального кода, статья превратилась бы в курс по Java-паттернам, а не в разбор ИИ-задачи.
Я принимаю конструктивную обратную связь, но ваш комментарий больше похож на демагогию со сменой контекста обсуждения. Вы сами выбрали свое "соломенное чучело - идеальный код" и пытаетесь дискредитировать содержание этой статьи. Делаете это с помощью указаний на несоответствие кода вашим представлениям о прекрасном.
В итоге в ваших комментариях оффтоп о стиле кода, а не на семантическом поиске и запуске локальных LLM моделей с помощь Spring AI. Статью я написал для тех, кто хочет разобраться, как применить LLM в Java проекте без использования облачных сервисов - API нейросетей.
У меня возникает двоякое чувство, что оба критических комментария похожи на результаты сгенерированые не совсем хорошей моделью по стандартному промпту для критики кода на java. И это даже пока без анализа профилей коментаторов на экспертность в обсуждаемой теме, статистики комментариев по тону, наличию обесценивания и конструктивности.
Ваш комментарий рекомендует распространенную ошибку в разработке систем: слишком большое внимание к следованию предполагаемым «лучшим практикам» без учета конкретного контекста и целей проекта. Я и не претендовал здесь на абсолютную архитектурную чистоту примера и сделал все что считаю полезным написания этого кода.
Вашим советам тут не следует следовать по нескольким причинам...
Код здесь предназначен для демонстрации примера реализации семантического поиска, а не для готового к производству корпоративного приложения. Основное внимание уделяется иллюстрации концепции, а не соблюдению абсолютно всех практик разработки и модулей фреймворка. Поскольку я автор, то и выбор/баланс что мне использовать из Spring, а что не нужно в этом проекте за мной.
Предложение полной архитектуры Spring с сервисами/репозиториями добавит сюда избыточной сложности. Когда потребуется, то я добавлю все необходимые дополнительные абстракции и слои.
Утверждение, что "работа с файлами через File устарела на 15 лет", преувеличено. java.nio.file.Files предлагает определенные преимущества, но java.io.File по-прежнему широко используется и вполне подходит для тех операций с файлами, что используются в этом примере
Вполне возможно, так же как можно подключить сбор стуртурированных логов в OpenTelemetry, добавить трейсинг и сбор метрик для улучшения observability. Тогда это будет совсем другая статья и уровень сложности. И главный вопрос зачем это мне сейчас.
Преобразование упакованного массива необходимо при работе с массивами JDBC, поскольку метод createArrayOf требует массивы объектов, а не примитивные массивы.
Я уже объяснил в предыдущем комментарии, какой я сделал выбор, чтобы сосредоточиться на реализации семантического поиска и тем подходам к расширяемости прототипа что я считаю рациональными, а не на применении здесь всех лучших практик разработки на Java.
Комментарий оставляет двоякое впечатление. С первого взгляда похож на конструктивный вопрос о выборе технологий, но по своему тону и форме выражение больше на попытку обесценить работу автора и завязать спор на эмоциях.
"Тут технология X, а почему не Y?". Краткий мой ответ на вопросы такого типа - это личные предпочтения, основанные на опыте разработки прототипов систем. Бывает что код со временем прототипы превращаются в систему, где важнее читаемость и простота расширения, а не отсутствие фреймворков и внешних зависимостей.
Эта статья иллюстрирует подход, который можно адаптировать под конкретные задачи. Почти любой проект можно реализовать на разных технологиях в зависимости от целей, а в данном случае баланс между образовательной ценностью и "написанием с минимумом фреймворков" казался приоритетным в первом. ИИ для кодинга это вообще отдельная тема про агенты и RAG и совсем не gemma3.
Для минимального примера можно обойтись без Spring и Lombok. Однако цель этой публикации — демонстрация практической реализации с легкой повторяемостью и фокусе на сути идеи, а не на написании кода без использования фреймворков. Spring Boot уменьшает усилия на подключение Ollama в Spring AI и в логику индексации данных. Lombok сокращает boilerplate с сеттерами и try/catch, что важно в статье, где фокус на логике, а не на многословном синтаксисе языка программирования. В образовательных целей такой подход позволяет читателю сосредоточиться на главном.
Выбор TestContainers здесь для быстрого старта примера, без описаний инструкций как запустить и настроить PostgreSQL. Опять же фокус на сути, а не командах развертывания СУБД. Мне был нужен именно PostgreSQL c pgvector для долгосрочного хранения данных и написаний произвольных по сложности запросов, а не Sqlite/H2database итп
Спасибо, про семантический поиск ваш комментарий справедлив хоть и забежал в мою будущую публикацию по этой теме. В этой статье показана базовая реализация индексации текстов, вычисление эмбеддингов, но без интерфейса для пользовательского поиска. Добавление интерфейса — логичный следующий этап, который можно реализовать на основе предложенной архитектуры. Например, можно было бы расширить приложение методом вроде searchByQuery() с использованием этих же эмбеддингов. Дополнил эту статью примером получения вектора SELECT get_embedding('SQL final state machine') для ее логической завершенности.
Проект действительно начался как эксперимент и превратился в прототип, демонстрирующий потенциал локальных LLM для структурирования данных. Я показал, как интегрировать PostgreSQL, Ollama и Java для решения задачи, которая обычно требует облачных сервисов или отдельных pipeline с DS/DevOPS экспертизой. Для меня это комплимент, что сложный функционал удалось реализовать по виду как лабораторную работу, что говорит об умении делать сложное проще для понимания читателями без ущерба для цели проекта.
Spacy это библиотека NLP для Python?
Конечно, я использую и другие модели в разных задачах, с учётом в том числе и лицензий. Но конкретно в этом сценарии gemma3 лучше всего показала себя, с учётом размера ее контекстного окна / числа параметров.
Да, это так. Но верно если только генерировать эмбеддинги только для ключевых слов. В этом примере я подмешиваю ключевые слова к описанию темы.
Из плюсов отдельной LLM и эмбеддинг нейросети - высокая специализация каждой и производительность. А значит можно например убрать "подмешивание" ключевых слов и заменить на подмешивание краткого описания всей статьи в отдельную тему и быстро пересчитать.
Ваше предложение действительно рабочее для генерации эмбеддингов для исходных кодов программ, там также важно и большее контекстное окно, так как в отличии от обычного текста - без ущерба не разделить большой метод на независимые фрагменты.
leisure=pitch + surface объективные факты, которые любой может перепроверить.
Отзывы, как и комментарии, же штука иногда не соответствующая действительности. При этом автор отзыва всегда может возразить "это мое личное мнение".
А проще было бы проставить в OpenStreetMap типы покрытия в городе спортивным площадкам и доставать потом запросом leisure=pitch AND surface=acrylic или же (tartan, clay) чем полагаться на отзывы.