Облачные ИИ не справляются, MiniLM-L6 ломается на философии: строим локальный RAG для сложных семантических текстов
Этот проект долго вынашивался и, в конце концов, начался как очередная попытка разобраться в философских текстах, написанных Джейн Робертс во второй половине двадцатого века.
Естественно, с появлением мощных облачных ИИ не оставлялись попытки найти в них “качественных собеседников” по предложенной теме. Но, как показала практика, они справились с этой задачей далеко не блестяще! То галлюцинировали факты из общих знаний, то упираясь в границы своих датасетов.
Ну что, остаётся последнее: пилить RAG на строго структурированной базе. А т.к. готовых корпусов в открытом доступе не нашлось, пришлось брать сырые сканы, вычищать артефакты распознавания и переводить их в XML, пригодный для эмбеддинга.
На сегодняшний день проделана часть работы. Создан репозиторий в статусе исследовательского лога, куда выкладываются сырые скрипты обработки, предсобранный индекс ChromaDB и пайплайн на базе Qwen2.5 + LM Studio.
Зачем я это пишу? Мне нужен технический аудит от тех, кто глубже работает с векторными базами и архитектурой чат-ботов. В процессе сборки возникли несколько вопросов, по которым у меня пока нет однозначного ответа:
Архитектура индекса: как грамотнее организовать хранение в Chroma?
Сохранение контекста диалога: как правильно реализовать память о предыдущих вопросах пользователя без раздувания токен-бюджета?
Ранжирование выдачи: может ли reranker (например, cross-encoder) улучшить точность на философских текстах? И с какого объёма стоит начинать эту оптимизацию?
А теперь немного более развёрнуто обо всех этапах по порядку.
Подготовка данных
Первая из разряда самых трудоёмких и затратных по времени задач — подготовка текста для трансформации txt -> xml.
Проблема в том, что имеющийся в наличии вариант сканов иной раз больше похож на кашу из артефактов. Облачные модели неплохо подсвечивают опечатки, но финальная правка всегда делается вручную, ибо эти товарищи (опять же, как показала практика) могут либо что-нибудь “подзабыть”, либо “напридумать” если попросить их сделать всю работу.
Разметка
Собственно, вторая из самых трудоёмких и затратных по времени задач.
Идея была такова: досконально разметить имеющиеся тексты на спикеров чтобы не дать будущей модели и шанса на ошибку при обучении. Тут очень важно чтобы модель чётко понимала чей текст, т.к. важна философия первоисточника, а не описание окружающего пространства, собственные ощущения или догадки окружающих людей. Только первоисточник.
Аннотация, при помощи вымученного промпта (если кому будет интересно могу запостить), была поручена локальному qwen2.5-coder-14b. Но (как показала практика) с расстановкой тегов опираясь на смысл текста, он ошибается больше чем хотелось бы. Поэтому “результат его работы” проверялся облачной моделью и затем все правки делались вручную с “диагональной читкой” всего получившегося xml.
Пример итоговой структуры:
Скрытый текст
Чанкинг, индексация и векторное пространство
Из-за того что вся смысловая нагрузка конкретно этой книги лежит исключительно на монологах автора, чанкинг простейший — отдельными параграфами по спикеру.
Для эмбеддинга выбран multilingual-e5-large.
Классический all-MiniLM-L6-v2 не справился с абстрактной терминологией Сета, демонстрируя высокий семантический дрейф (OOD), тогда как E5 продемонстрировал отличное удержание контекста предложенных понятий.
Пайплайн индексации:
Retrieval и управление «голосом» модели
Найти фрагменты недостаточно — нужно заставить модель отвечать как Сет, строго придерживаться цитат и общаться на языке пользователя:
Вопросы к сообществу
На данный момент пайплайн работает стабильно для одиночных запросов, но упирается в несколько архитектурных вопросов:
Архитектура индекса Chroma: сейчас всё лежит в одной коллекции. При росте базы до 10+ томов не станет ли поиск слишком шумным? Стоит ли дробить базу по книгам/сессиям, или один монолитный индекс при правильной сегментации всегда будет работать быстрее за счёт внутреннего кэширования?
Управление состоянием диалога: каждая итерация сейчас начинается «в вакууме». Простое добавление истории чата в конец переменной prompt быстро сожрёт контекстное окно Qwen2.5-32B. Есть ли смысл выносить историю во внешнее хранилище и делать Retrieval уже по предыдущим вопросам?
Ранжирование выдачи: сейчас мы просто берём top-7 из Chroma. Может ли reranker (например, cross-encoder) улучшить точность выдачи на философских текстах, или для 911 чанков это преждевременная оптимизация?
Если у вас есть опыт масштабирования векторных баз или архитектурой памяти агентов — welcome!
Внутри репозитория прямо сейчас в корневом ридми есть мануал на квикстарт. Желающие могут прямо сейчас ознакомиться и запустить проект в текущем варианте. [https://github.com/Joseph-m-l/seth_material_rag]
Проект остаётся исследовательским логом. Но если мы вместе решим вопросы архитектуры индекса и памяти, из этого набора скриптов получится самый глубокий собеседник по текстам Джейн Робертс, который можно запустить локально.
Следующий шаг — индексация всех 22 глав первой книги и эксперименты с памятью диалога.
Оцените материал:
