У нас нет, но сейчас работаю с компанией у которой все документы в docx, pdf, и большинство отсканированые пиксельные. Тут довльно хорошо работает OCR для распознования в текст:
Можно дату, но зачем усложнять если просто берем отрезаем все что старше чем X. Какое приложение должно вызывать MCP сервер? У нас адаптер в виде slack бота, он коннектится к MCP которые уже роутит вопрос куда надо. Можно использовать и облачную и локальную LLM, есть локальные 1 битные, которые даже на CPU более менее работают
Из беспатных LLM? ну собственно даже chatGPT сейчас имеет бесплатный тариф, правда ограниченный по токенам. Либо любую локальную LLM отсюда https://huggingface.co/models. Либо вот эту для CPU https://t.me/aigentto/19.
Интересная задача по поиску противоречий. Но это не совсем RAG, это скорее стадия подготовки к RAG. Стадия чистки данных. RAG выбирает топ X документов на запрос пользователя. На запрос типа «Какие ВНД противоречат друг другу и в чем?», он не выберет ничего.
Здесь вам просто нужно загнать все документы в LLM с промтом «Какие ВНД противоречат друг другу и в чем?». Если документов очень много, то нужно будет делать пошагово, то есть сказать: «Я буду сейчас давать тебе документы, твоя задача - выяснить, какие ВНД противоречат друг другу и в чем?». Можно это автоматизировать, чтобы оно, например, раз в какой-то период прогоняло этот сценарий и выявляло дубликаты.
Про локальный запуск. Примерные скорости при использовании GPU vs CPU локально (первый параметр - это сложность нейросети, чем больше, тем в среднем качественней результат):
Локальные модели, помещённые на GPU/VRAM:
7–13B: 20 токенов в секунду
14–40B: 15 токенов в секунду
70–700B: 10 токенов в секунду
Локальные модели, запущенные на CPU/RAM:
7B: 8 токенов в секунду
14–40B: 3 токена в секунду
70–700B: 1,5 токена в секунду
В среднем один токен состоит из 3–5 символов, включая пробелы, знаки препинания и специальные символы. На однобитных LLM будет в несколько раз быстрее, но качество может пострадать немного.
Таким образом, если у вас, например, 100 документов средним размером 2 листа A4 (~4000 символов), то есть весь объем в 4 тысяч символов, то обработка всех документов будет занимать в среднем ~1,5 часа на GPU и 8 часов на CPU, либо ~2-3 часа на 1-битной сети на CPU. Это очень примерно.
Если у вас объем документов больше, то вы уже рискуете не попасть в контекстное окно нейросети, и нужно будет сравнивать наборы документов, что приведет к вынужденным повторным сравнениям и удлинит этот процесс.
GPU, про который мы здесь говорим, это что-то типа ~RTX 4090 ценой ~250 тыс. рублей
Ну, тут нужно посчитать. Ведь если использовать OpenAI VectorStore, то загрузка данных туда бесплатная. А за использование этих данных (а именно выборку топ 5-50 векторов) нужно будет платить в два раза меньше, чем если передавать эти данные каждый раз при использовании локальной векторной базы. Есть еще косты за хранение данных там, но они совсем копеечные. Поэтому у нас в итоге должно получиться дешевле, чем например с Gemini.
Я пока заливал только wiki + один канал slack. Это за 7-8 лет истории, но получилось на удивление немного - несколько тысяч документов. По времени 5 минут на MacBook M3.
Я попробовал с локальными моделями на MacBook M3, очень низкое качество ответа и очень медленно работает, поэтому перешел полностью на cloud модели. Конечно можно тюнить, но оставил эту задачу на потом, сейчас охота поднять что-то полезное и сразу работающее.
Да тоже чувствую что нужно больше потратить времени на prompt engineering. Единственное что меня отпугивает - это по идее после каждого изменения промта - мне нужно оценить изменение по качестве RAG ответов, то есть прогнать например набор из 25 вопросов, которые я использовал изначально. И если что-то станет хуже, то опять менять и тюнить. Не могу пока придумать как этот процесс оптимизировать.
Есть похожая проблема, когда он берет данные из таблицы, то часто смещает столбцы на одну строку. Например у нас есть таблица будущих отпусков напротив имен, и там выдает все неправильно со смещением на одну строку данных из второго стоблца. Пока не разбирался как это починить.
Случайно, просто первое что нашел было ChromaDB. Сейчас тестируем как раз релевантность ответов, будет еще массовое тестирование (вся компания будет тестить), как будет результат - отпишусь.
Ждем вашей статьи по теме - с удовольствием почитаем/разберем.
Библиотеки pytesseract, pdf2image, PIL. Если нужно дайте знать я скину пример кода.
У нас нет, но сейчас работаю с компанией у которой все документы в docx, pdf, и большинство отсканированые пиксельные. Тут довльно хорошо работает OCR для распознования в текст:
Можно дату, но зачем усложнять если просто берем отрезаем все что старше чем X. Какое приложение должно вызывать MCP сервер? У нас адаптер в виде slack бота, он коннектится к MCP которые уже роутит вопрос куда надо. Можно использовать и облачную и локальную LLM, есть локальные 1 битные, которые даже на CPU более менее работают
Из беспатных LLM? ну собственно даже chatGPT сейчас имеет бесплатный тариф, правда ограниченный по токенам. Либо любую локальную LLM отсюда https://huggingface.co/models. Либо вот эту для CPU https://t.me/aigentto/19.
Интересная задача по поиску противоречий. Но это не совсем RAG, это скорее стадия подготовки к RAG. Стадия чистки данных. RAG выбирает топ X документов на запрос пользователя. На запрос типа «Какие ВНД противоречат друг другу и в чем?», он не выберет ничего.
Здесь вам просто нужно загнать все документы в LLM с промтом «Какие ВНД противоречат друг другу и в чем?». Если документов очень много, то нужно будет делать пошагово, то есть сказать: «Я буду сейчас давать тебе документы, твоя задача - выяснить, какие ВНД противоречат друг другу и в чем?». Можно это автоматизировать, чтобы оно, например, раз в какой-то период прогоняло этот сценарий и выявляло дубликаты.
Про локальный запуск. Примерные скорости при использовании GPU vs CPU локально (первый параметр - это сложность нейросети, чем больше, тем в среднем качественней результат):
Локальные модели, помещённые на GPU/VRAM:
7–13B: 20 токенов в секунду
14–40B: 15 токенов в секунду
70–700B: 10 токенов в секунду
Локальные модели, запущенные на CPU/RAM:
7B: 8 токенов в секунду
14–40B: 3 токена в секунду
70–700B: 1,5 токена в секунду
В среднем один токен состоит из 3–5 символов, включая пробелы, знаки препинания и специальные символы. На однобитных LLM будет в несколько раз быстрее, но качество может пострадать немного.
Таким образом, если у вас, например, 100 документов средним размером 2 листа A4 (~4000 символов), то есть весь объем в 4 тысяч символов, то обработка всех документов будет занимать в среднем ~1,5 часа на GPU и 8 часов на CPU, либо ~2-3 часа на 1-битной сети на CPU. Это очень примерно.
Если у вас объем документов больше, то вы уже рискуете не попасть в контекстное окно нейросети, и нужно будет сравнивать наборы документов, что приведет к вынужденным повторным сравнениям и удлинит этот процесс.
GPU, про который мы здесь говорим, это что-то типа ~RTX 4090 ценой ~250 тыс. рублей
Если нужен код, читайте предыдущие статьи.
Ничего не понял ) Английский у меня native. В чем вопрос то к статье? )
Как раз таки следовал, но может не всем. Спасибо за bolt.new, выглядит интересно.
Ну, тут нужно посчитать. Ведь если использовать OpenAI VectorStore, то загрузка данных туда бесплатная. А за использование этих данных (а именно выборку топ 5-50 векторов) нужно будет платить в два раза меньше, чем если передавать эти данные каждый раз при использовании локальной векторной базы. Есть еще косты за хранение данных там, но они совсем копеечные. Поэтому у нас в итоге должно получиться дешевле, чем например с Gemini.
Надо почистить repo и все описать, сейчас там набор random скриптов ) Но я сделаю чуть позже.
Да добавить NER + GraphDB для Wiki. Для Slack оставить ChromaDB + NER. Для JIRA сделать только GraphDB + NER.
Не понял на что заменили chromaDB? Это же просто векторная БД, при чем тут модели и huggingface?
Записал попробовать GraphRAG + NER. Очень интересно на сколько лучше оно будет работать. Сейчас кстати уже неплохо на твердую 4 работает.
ElasticSearch тоже хочу попробовать, когда буду уже заливать весь slack + весь gitlab. Там наверное будут сотни тысяч или миллионы векторов.
Я пока заливал только wiki + один канал slack. Это за 7-8 лет истории, но получилось на удивление немного - несколько тысяч документов. По времени 5 минут на MacBook M3.
Я попробовал с локальными моделями на MacBook M3, очень низкое качество ответа и очень медленно работает, поэтому перешел полностью на cloud модели. Конечно можно тюнить, но оставил эту задачу на потом, сейчас охота поднять что-то полезное и сразу работающее.
Да тоже чувствую что нужно больше потратить времени на prompt engineering. Единственное что меня отпугивает - это по идее после каждого изменения промта - мне нужно оценить изменение по качестве RAG ответов, то есть прогнать например набор из 25 вопросов, которые я использовал изначально. И если что-то станет хуже, то опять менять и тюнить. Не могу пока придумать как этот процесс оптимизировать.
Есть похожая проблема, когда он берет данные из таблицы, то часто смещает столбцы на одну строку. Например у нас есть таблица будущих отпусков напротив имен, и там выдает все неправильно со смещением на одну строку данных из второго стоблца. Пока не разбирался как это починить.
Случайно, просто первое что нашел было ChromaDB. Сейчас тестируем как раз релевантность ответов, будет еще массовое тестирование (вся компания будет тестить), как будет результат - отпишусь.