Полноценный поиск пока не планировала, хотя сейчас вместе с постами в Google-таблицу сохраняются дополнительные теги от LLM - на какие роли и специальности влияет технология. Это не публикуется, копится для будущего анализа тенденций.
Что касается RAG - да, пока текущей схемы хватает. Новые посты сравниваются по смыслу со 100 последними публикациями, а не со всей базой, и явных повторов пока не замечено. Сейчас основное внимание хочу уделить двум узким местам системы - объёму информации, поступающей в LLM, и фильтрации по ключевым словам. Вижу здесь потенциал для повышения качества отбора.
Но если объём публикаций вырастет и потребуется работать уже со всей историей канала, то попробовать RAG будет интересно - выглядит логичным следующим шагом для развития.
Да, такой вариант тоже рассматривала. В моём случае повторная проверка выполняется через LLM и сравнивает смысл публикаций, поэтому модели нужен сам текст поста, а не только идентификатор.
Но если внедрить эмбеддинги или более специализированную дедупликацию, объём передаваемых данных действительно можно будет существенно сократить.
Канал сознательно не добавляла в статью, так как хотелось сфокусироваться на самой системе и опыте её создания. Отправлю название вам в лс :)
Да, пожалуйста, отправила в лс)
Кажется, я не до конца поняла, какой именно этап вы имеете в виду.
Сейчас LLM используется в 3-х местах:
Текст статьи --> LLM: оценка релевантности и написание коротких постов.
Короткие посты одного прохода --> LLM: смысловая дедупликация между собой.
Pending-посты из таблицы + ранее опубликованные посты --> LLM: проверка, не является ли новый пост смысловым дублем уже опубликованных.
Поэтому уточню: под "вернуть только Id новости" вы имеете в виду первый шаг, когда статья уже обработана моделью? Или один из этапов дедупликации?
Спасибо!
Полноценный поиск пока не планировала, хотя сейчас вместе с постами в Google-таблицу сохраняются дополнительные теги от LLM - на какие роли и специальности влияет технология. Это не публикуется, копится для будущего анализа тенденций.
Что касается RAG - да, пока текущей схемы хватает. Новые посты сравниваются по смыслу со 100 последними публикациями, а не со всей базой, и явных повторов пока не замечено.
Сейчас основное внимание хочу уделить двум узким местам системы - объёму информации, поступающей в LLM, и фильтрации по ключевым словам. Вижу здесь потенциал для повышения качества отбора.
Но если объём публикаций вырастет и потребуется работать уже со всей историей канала, то попробовать RAG будет интересно - выглядит логичным следующим шагом для развития.
Спасибо!
Да, такой вариант тоже рассматривала. В моём случае повторная проверка выполняется через LLM и сравнивает смысл публикаций, поэтому модели нужен сам текст поста, а не только идентификатор.
Но если внедрить эмбеддинги или более специализированную дедупликацию, объём передаваемых данных действительно можно будет существенно сократить.
Канал сознательно не добавляла в статью, так как хотелось сфокусироваться на самой системе и опыте её создания. Отправлю название вам в лс :)