БЯМ это все таки по генерацию, а не вычисление. Поэтому вызвать tools с математической функцией или на худой конец написать код и исполнить его для вычисления - видимости мне более рациональное решение.
Какой смысл мучить чистый БЯМ, пусть делает свою работу.
Вопрос на уточнение. С помощью классификации Вы определяете тему запроса (и соответственно передаёте все инструкции), либо конкретную инструкцию (которых может быть сотни).
В целом после набора датасета задачу можно свести к обучению локальной модели. В качестве ембединга использовать е5, он хорош даже если сравнивать с large.
Локальная модель будет быстрее, если актуально конечно скорость, но самое главное будет работать в закрытом контуре, если важна конфиденциальность.
Возможно, но я тут больше как практик, поэтому на сегодняшний день наиболее практичным мне кажется исходить из домено-ориентированного подхода.
Т.е. делать файнтюн эмбединга под конкретную область знаний. Но это не решит вопрос (увы) задач поиска ответа на вопросы. К сожалению "традиционный" подход: нарезать на куски, сделать вектор и потом по ним искать имеет ограничения методологические. Более 80-85% точных ответов сложно получить.
Между поделкой на коленке на Ардуинкой (считай Proof of Concept) и промышленным решением - огромная пропасть.
Это сложно объяснить, если нет личного опыта доведения прототипа до серии. Сложно потому что , есть множество аспектов (от поставок и сборки, до сертификации и поддержки), которые в момент прототипирования вообще не имеют значения, но это не значит, что их нет.
Построить на коленке ардуинку не равно запустить в серию десятки тысяч датчиков.
Соглашусь и в целом Я бы разделил задачи. Фокусировка на кусках и подготовка ответа. Подготовка - это llm модель. Тут пока без вариантов. И в целом даже локальная работать.
А вот как обеспечить RAG - дело исследовательское. Я делал почти в лоб. Получилось средне. Через косиносное сравнение.
Можно попробовать и нужно через эластик или через локальный поисковик или онтологии и т.д.. Или ручная разметка.
Поэтому некорректно сравнивать "вектор" как инструмент с типом поиска, как методологию. Разные сущности. В конечном итоге поисковик использует тоже вектора в т.ч.
Вывод абсолютно верный и он подтвердился экспериментом.
Но я бы не стал списывать этот подход:
1) графовые данные, классический поиск и прочее могут помочь с лучшим фокусом
2) ручная или получручная разбивка может помочь.
3) правильная встройка в бизнес процесс - ключевой навык. Но это путь. На первом этапе запрещаем например любые ответы, кроме определений. Потом даем предварительный ответ с пометкой "не точно. И т.д.
98% нет и у человека. В ходе обсуждения проекта мы иногда спорили, что является правильным ответом, а один из ответов был неожиданным для одного из коллег. Он не знал.
Поэтому более правильно сейчас кажется научить определять сложные и простые вопросы и в случае сложных делать пометку "данные не точные, хотите запросить консультацию?". А простые довести до уровня 100%.
Да, это агентская система. В Cursor Sonnet4 прекрасно работает. Процентов 90% кода к тесту было написано так
Надо добавить в тест.
Согласен. Недописал.Там где нужна абсолютная точность - LLM неправильно.
А не считаете ли этот подход тупиковым?
БЯМ это все таки по генерацию, а не вычисление. Поэтому вызвать tools с математической функцией или на худой конец написать код и исполнить его для вычисления - видимости мне более рациональное решение.
Какой смысл мучить чистый БЯМ, пусть делает свою работу.
Вопрос на уточнение. С помощью классификации Вы определяете тему запроса (и соответственно передаёте все инструкции), либо конкретную инструкцию (которых может быть сотни).
Ну как бы окно контекста даже у 3.5 turbo - 32 k токенов, не говоря уже о 4 модели.
Пишешь в content все что нужно. При этом 1 токен>1 символ
Отличная статья.
В целом после набора датасета задачу можно свести к обучению локальной модели. В качестве ембединга использовать е5, он хорош даже если сравнивать с large.
Локальная модель будет быстрее, если актуально конечно скорость, но самое главное будет работать в закрытом контуре, если важна конфиденциальность.
Возможно, но я тут больше как практик, поэтому на сегодняшний день наиболее практичным мне кажется исходить из домено-ориентированного подхода.
Т.е. делать файнтюн эмбединга под конкретную область знаний. Но это не решит вопрос (увы) задач поиска ответа на вопросы. К сожалению "традиционный" подход: нарезать на куски, сделать вектор и потом по ним искать имеет ограничения методологические. Более 80-85% точных ответов сложно получить.
Вы имеете ввиду длинные тексты?
С этим проблема. Локальные модели очень ограниченные в размере текста, который они могут превратить в вектор.
text-large-03 может относительно много. Если не ошибаюсь 4096.
Bert 712 символов. intfloat/multilingual-e5-large - вообще 512.
Поэтому тут очень специфическое применение.
Между поделкой на коленке на Ардуинкой (считай Proof of Concept) и промышленным решением - огромная пропасть.
Это сложно объяснить, если нет личного опыта доведения прототипа до серии. Сложно потому что , есть множество аспектов (от поставок и сборки, до сертификации и поддержки), которые в момент прототипирования вообще не имеют значения, но это не значит, что их нет.
Построить на коленке ардуинку не равно запустить в серию десятки тысяч датчиков.
Да, это тоже уже есть в планах.
А в чем новизна? Вроде у Voyah Free уже такой есть.
1) сейчас делаем. Возможно сделаю часть. 3
2-3) уже есть. Большой датасет для обучения, но не взлетает пока. Ищем причину.
Соглашусь и в целом Я бы разделил задачи. Фокусировка на кусках и подготовка ответа. Подготовка - это llm модель. Тут пока без вариантов. И в целом даже локальная работать.
А вот как обеспечить RAG - дело исследовательское. Я делал почти в лоб. Получилось средне. Через косиносное сравнение.
Можно попробовать и нужно через эластик или через локальный поисковик или онтологии и т.д.. Или ручная разметка.
Поэтому некорректно сравнивать "вектор" как инструмент с типом поиска, как методологию. Разные сущности. В конечном итоге поисковик использует тоже вектора в т.ч.
Вывод абсолютно верный и он подтвердился экспериментом.
Но я бы не стал списывать этот подход:
1) графовые данные, классический поиск и прочее могут помочь с лучшим фокусом
2) ручная или получручная разбивка может помочь.
3) правильная встройка в бизнес процесс - ключевой навык. Но это путь. На первом этапе запрещаем например любые ответы, кроме определений. Потом даем предварительный ответ с пометкой "не точно. И т.д.
Сложности начинаются, когда Вы захотите перенести все в закрытый контур.
Если в лоб, то:
1) руками разбить на куски, каждый из которых был законченный. Если список чего-то, то тогда весь список - один кусок.
2) Подключить gpt4 turbo с контекстом 128к
3) все что не вошло в п. 1 запретить использовать на уровне админ правил и может быть промтпом, если нельзя никак сократить.
При таком подходе думаю можно добиться 90+ процентов.
В целом да. Если конечно не считать, что Сайга это тоже дообученная Llama
Дообучение в работе, но пока без результатов. Есть сложности с промтом обучения и галлюцинациями. Но сделаем.
Как оказалось в большей степени узкое горлышко- это токенайзер и чанки , а не модель.
98% нет и у человека. В ходе обсуждения проекта мы иногда спорили, что является правильным ответом, а один из ответов был неожиданным для одного из коллег. Он не знал.
Поэтому более правильно сейчас кажется научить определять сложные и простые вопросы и в случае сложных делать пометку "данные не точные, хотите запросить консультацию?". А простые довести до уровня 100%.
А вектор по какой части делали?