В этом эксперименте всё довольно просто: каждую статью НК резал отдельно на чанки до 4000 символов, по возможности по границе абзаца, без overlap. Специальной обработки исключений и примечаний не было, поэтому правило и исключение могли разъехаться. Здесь я проверял поиск, а не полноту юридического ответа. Сам чанкинг и потерю контекста подробнее разберу во второй части.
Тут, по-моему, уже надо сначала разложить или дооснастить вопрос пользователя в несколько: какие режимы подходят, какие у каждого ставки, ограничения, льготы и сроки. А потом искать по каждому и собирать сравнение. Если всё это отправить в поиск одним запросом, нужные куски могут потеряться. Поэтому в валидационный датасет стоит включать реальные вопросы, в том числе такие составные, и проверять, всё ли нужное для ответа нашлось.
Условно: уточнить данные об ИП, отобрать подходящие режимы, собрать условия в таблицу и уже потом считать, что выгоднее. Но да, сама декомпозиция ещё не гарантирует, что всё найдётся.
Поэтому предлагаю пробовать, смотреть на метрики и разбирать, где именно всё ломается. Статья как раз об этом. А про чанкинг будет отдельная часть, действительно, есть о чём говорить.
Благодарю, приятно слышать. Стараюсь увлечь и себя, и читателя. Есть куда расти. Кроме того, мне всегда можно предложить тему, в которой есть заинтересованность и приятно было бы почитать)
Привет, спасибо за приятные слова. Я рад что тебе нравится) К сожалению или к счастью, мой основной язык java, поэтому я стараюсь его затрагивать. Про памятку отлично подметил, нужно сделать в следующий раз)
Composite не требует неограниченной вложенности. Достаточно представить приложение доставки еды, где сотни ресторанов и их меню, где в каждом разное количество узлов, листьев и разная глубина дерева. Один интерфейс под произвольные деревья. Очередной академический пример со структурой папок и файлов специально не приводил.
Пример с драйвером устройства реально академически хороший, но только для разработчика на плюсах. Потому что процент людей, которые занимаются на Java подобным ничтожно мал. Гораздо ближе был бы JDBC-драйвер (адаптирует конкретную БД под единый java.sql апи) раз уж на то пошло, как пример из стандартных библиотек. При внимательном прочтении можно заметить близкий к нему пример прямо в этой статье — удалённый вызов процедур. Хоть его можно обозвать формально, ещё и Proxy.
У всех свои любимые примеры, ваши ничем не хуже. Спасибо за комментарий.
Вы правы, в Java многое можно свести к лямбдам и возвращать из фабрики просто функцию. В примере хотелось сформировать, так скажем, ментальную модель, более явную. Я пожалуй, добавлю в статью реальный пример с функциональными интерфейсами. Спасибо большое за комментарий
Большое спасибо за комментарий, могу вынести общее замечание к своему материалу: более ясно выразить глубину "копания" в обозначенном направлении. Действительно, указав в разделе "сети" DNS, подразумевается скорее понимание роли и применение протокола в области. Как и с connection pool, почему его раздувание — плохо, и какая роль у HikariCP — что и как он оптимизирует.
В целом, тем, согласен, много, но выше в комментариях, я описал что есть такое сеньор и нехватка хардов для специалиста — это не всегда главное узкое горлышко для повышения грейда. Да и рынок диктует свои правила, требования всегда росли и продолжают расти.
Полностью разделяю вашу позицию по поводу километровых книг, среднестатистическому разработчику читать их скорее вредно, чем полезно.
Хороший вопрос, сеньор — эксперт предметной области, он и в бизнесовое обсуждение может внести лепту, и организовать работу команды, и оценить нужно ли функционал реализовывать в целом, если подобное уже реализовано или есть подходящие для этого технологии. Junior и Middle — это про ответственность за задачи, а сеньор - про ответственность за разработку в проекте в целом.
Сеньор — это про опыт решения бизнес проблем, большую ответственность, и в меньшей мере про харды.
Чек-лист для движения от младшего специалиста к Миддлу. То есть Junior разработчик, который подтянет темы и навыки описанные в статье — смело может считаться средним специалистом Java-разработки.
Сами материалы и ресурсы, которые я собрал в формате дорожной карты, разместил по ссылке.
Статью можно интерпретировать как чек-лист с темами и обоснованием их изучения, понимание которых в наших реалиях неплохо бы сформировать. Знаю множество людей для которых подобный формат был бы полезен, я и сам сталкивался с проблемой нечёткости картины движения на этом пути.
LLM при написании статьи не использовалось в качестве источника информации. И отмечу, что цели ужать в одну статью в рассказ о каждой технологии не было, это получилась бы летопись.
Вместо этого, планируется выпускать небольшие статьи на каждую из тем, чтобы "магические" названия технологий, превратились в знакомые инструменты каждому. Большое спасибо за комментарий
Попробуй воспользоваться методами повышения качества приведёнными в статье, гибридный поиск - тоже хороший вариант, тот же самый elasticsearch можно использовать
В этом эксперименте всё довольно просто: каждую статью НК резал отдельно на чанки до 4000 символов, по возможности по границе абзаца, без overlap. Специальной обработки исключений и примечаний не было, поэтому правило и исключение могли разъехаться. Здесь я проверял поиск, а не полноту юридического ответа. Сам чанкинг и потерю контекста подробнее разберу во второй части.
Тут, по-моему, уже надо сначала разложить или дооснастить вопрос пользователя в несколько: какие режимы подходят, какие у каждого ставки, ограничения, льготы и сроки. А потом искать по каждому и собирать сравнение. Если всё это отправить в поиск одним запросом, нужные куски могут потеряться. Поэтому в валидационный датасет стоит включать реальные вопросы, в том числе такие составные, и проверять, всё ли нужное для ответа нашлось.
Условно: уточнить данные об ИП, отобрать подходящие режимы, собрать условия в таблицу и уже потом считать, что выгоднее. Но да, сама декомпозиция ещё не гарантирует, что всё найдётся.
Поэтому предлагаю пробовать, смотреть на метрики и разбирать, где именно всё ломается. Статья как раз об этом. А про чанкинг будет отдельная часть, действительно, есть о чём говорить.
Принято!)
Да, он тоже будет :) Разберём contextual retrieval от Anthropic, late chunking и работу с самим запросом - rewrite и HyDE.
Благодарю, приятно слышать. Стараюсь увлечь и себя, и читателя. Есть куда расти. Кроме того, мне всегда можно предложить тему, в которой есть заинтересованность и приятно было бы почитать)
Под каждым паттерном есть блок «Сценарии неприменимости» и вот небольшая вырезка про Посредник:
В целом, большое спасибо за комментарий, приятно слышать
Чуть не забыл.
Ссылка на репозиторий: https://github.com/br0mberg/GOF-patterns-java
Привет, спасибо за приятные слова. Я рад что тебе нравится) К сожалению или к счастью, мой основной язык java, поэтому я стараюсь его затрагивать. Про памятку отлично подметил, нужно сделать в следующий раз)
Composite не требует неограниченной вложенности. Достаточно представить приложение доставки еды, где сотни ресторанов и их меню, где в каждом разное количество узлов, листьев и разная глубина дерева. Один интерфейс под произвольные деревья.
Очередной академический пример со структурой папок и файлов специально не приводил.
Пример с драйвером устройства реально академически хороший, но только для разработчика на плюсах. Потому что процент людей, которые занимаются на Java подобным ничтожно мал. Гораздо ближе был бы JDBC-драйвер (адаптирует конкретную БД под единый
java.sqlапи) раз уж на то пошло, как пример из стандартных библиотек. При внимательном прочтении можно заметить близкий к нему пример прямо в этой статье — удалённый вызов процедур. Хоть его можно обозвать формально, ещё и Proxy.У всех свои любимые примеры, ваши ничем не хуже. Спасибо за комментарий.
Завтра выйдет)
Вы правы, в Java многое можно свести к лямбдам и возвращать из фабрики просто функцию. В примере хотелось сформировать, так скажем, ментальную модель, более явную. Я пожалуй, добавлю в статью реальный пример с функциональными интерфейсами. Спасибо большое за комментарий
Большое спасибо за комментарий, могу вынести общее замечание к своему материалу: более ясно выразить глубину "копания" в обозначенном направлении. Действительно, указав в разделе "сети" DNS, подразумевается скорее понимание роли и применение протокола в области. Как и с connection pool, почему его раздувание — плохо, и какая роль у HikariCP — что и как он оптимизирует.
В целом, тем, согласен, много, но выше в комментариях, я описал что есть такое сеньор и нехватка хардов для специалиста — это не всегда главное узкое горлышко для повышения грейда. Да и рынок диктует свои правила, требования всегда росли и продолжают расти.
Полностью разделяю вашу позицию по поводу километровых книг, среднестатистическому разработчику читать их скорее вредно, чем полезно.
Хороший вопрос, сеньор — эксперт предметной области, он и в бизнесовое обсуждение может внести лепту, и организовать работу команды, и оценить нужно ли функционал реализовывать в целом, если подобное уже реализовано или есть подходящие для этого технологии. Junior и Middle — это про ответственность за задачи, а сеньор - про ответственность за разработку в проекте в целом.
Сеньор — это про опыт решения бизнес проблем, большую ответственность, и в меньшей мере про харды.
Чек-лист для движения от младшего специалиста к Миддлу. То есть Junior разработчик, который подтянет темы и навыки описанные в статье — смело может считаться средним специалистом Java-разработки.
Сами материалы и ресурсы, которые я собрал в формате дорожной карты, разместил по ссылке.
Статью можно интерпретировать как чек-лист с темами и обоснованием их изучения, понимание которых в наших реалиях неплохо бы сформировать. Знаю множество людей для которых подобный формат был бы полезен, я и сам сталкивался с проблемой нечёткости картины движения на этом пути.
LLM при написании статьи не использовалось в качестве источника информации. И отмечу, что цели ужать в одну статью в рассказ о каждой технологии не было, это получилась бы летопись.
Вместо этого, планируется выпускать небольшие статьи на каждую из тем, чтобы "магические" названия технологий, превратились в знакомые инструменты каждому.
Большое спасибо за комментарий
Теперь выложил, время публикации сдвинулось — не уследил) Приятного прочтения!
Лишь бы у Unfrozen всё успелось и мы поиграли в Olden Era в этом году)
Попробуй воспользоваться методами повышения качества приведёнными в статье, гибридный поиск - тоже хороший вариант, тот же самый elasticsearch можно использовать
Обучить и дообучить сложновато и дорого, для меня пока эта задача покрыта мраком.
В целом, rag отличная вещь, за свою ресурсную стоимость must have.
Возможно, попробую когда-нибудь doctovec, а так - альтернатив море