Hybrid RAG knowledge base за 15 минут — почему пришлось собрать свою lite версию RAG и в чем опасность RAG фреймворков

Архитектура Hybrid RAG систем заняла нишу корпоративных баз знаний, став стандартом для построения сервисов генерации контента на основе внутренних корпоративных данных. Уже пару лет у этого подхода практически нет альтернатив, когда речь заходит о сочетании возможностей генеративного ИИ с требованиями корпоративной безопасности и доверия к полученным результатам. Ключевое преимущество RAG перед обычным взаимодействием с нейросетями заключается в прозрачности: мы четко видим, на основе каких документов был сформирован ответ, и можем проверить каждый шаг пайплайна

Почти в каждом проекте, которые мне удалось наблюдать, происходило одно и то же - сначала команда стартует с LangChain или LlamaIndex, через пару месяцев пайплайн становится неуправляемым, далее половина фреймворка выкидывается и пишется свой костомный retrieval. В итоге архитектура почти всегда выглядит одинаково - Frontend + Python backend + vector search + LLM API

В этой статье я покажу почему это происходит, поделюсь сложностями с которыми можно столкнуться при реализации корпоративных баз знаний основанных на RAG технологиях, расскажу почему готовые фреймворки иногда могут быть опасны для проекта и как я пришел к созданию универсальной сборки RAG системы разворачиваемой за 15 минут

Ранее в своих статьях Методы построения RAG систем, Hybrid RAG: методы реализации. я разбирал теоретические и практические аспекты и делился своим опытом реализации подходов и практик в области простых и гибридных RAG систем. Вопросы всегда можно задать здесь

Почему свой RAG

За последние два года вокруг RAG систем сформировалась огромная инфраструктура. Появились специализированные фреймворки и облачные сервисы. Однако, если присмотреться к реальным запросам бизнеса, вырисовывается устойчивый паттерн. Компании хотят быстрый запуск без глубокого погружения в разработку продукта, в пару кликов загрузить корпоративные документы и получать ответы на запросы по своим внутренним документам. Компаниям не нужен очередной конструктор с бесконечными настройками. а востребована легкая, быстро разворачиваемая корпоративная RAG база знаний.

Основной актив, с которым должны работать такие системы это регламенты, техническая документация, договоры, инструкции и неструктурированные базы знаний. И здесь RAG действительно незаменим. Но существует и обратная сторона медали:

В чем опасность фреймворков

Многие на стартовом этапе погружаются в корпоративную RAG разработку используя популярные высокоуровневые Фреймворки вроде LangChain или LlamaIndex

Но через некоторое время часть команд переходит на чистую реализацию RAG или уходит в кастомизацию компонентов фреймворка. Причина в том, что из коробки у таких фреймворков есть ряд ограничений в продакт системах, в чем же скрывается опасность их применения?

Сложность и избыточная абстракция

Фреймворки пытаются решить сразу целую серию задач и их архитектура как правило состоит из модулей:

• Chaining (Цепочки) в виде последовательность действий. Сначала сделай А, потом Б

• Agents (Агенты или ассистенты) определяет сценарии взаимодействия и обработки данных

• Tools (Инструменты) Сервисные вспомогательные функции обработки данных

• Memory (Память) контекст. Способность ИИ помнить, что вы обсуждали три сообщения назад

• Retrieval (Поиск/RAG) Поиск нужной информации в источниках данных

• Prompt orchestration Шаблоны, сборка и отправка запроса модели

Но в реальном корпоративном проекте чаще всего нужен очень простой пайплайн.

В простых задачах это всего несколько шагов query - embedding - vector search - top-k chunks - LLM prompt - answer которые можно реализовать буквально несколькими десятками строк кода.

Когда используется крупный фреймворк, появляется дополнительный слой абстракций, в итоге архитектура становится сложнее, чем сама задача

Потеря контроля над основным процессом подготовки и извлечения данных

Для RAG самое важное — это пайплайн извлечения данных

Нужно контролировать и определять:

• размер фрагмента и его перекрытие

• надежный пайплайн определения границ фрагмента

• легкая и эффективная эмбединг модель

• гибридные способы извлечения фрагментов

• переранжирование и управление весом источников поиска

• инструменты мультилингвальности

• использование метаданных

В фреймворках эти вещи часто ограничены для кастомизации или абстрагированы архитектурой фреймворка

Например, стандартный retriever может:

• не поддерживать нужный тип векторного индекса или пользовательскую логику

• не давать доступ к промежуточным данным

• плохо масштабироваться

Когда пайпалйн написан напрямую, через прямой доступ к стеку, от работы с моделями, процессами фрагментации, векторизации, хранения данных, методов извлечения, можно контролировать всё, ну или почти все, ограничения определяются только выбранным стеком

Проблемы производительности

Фреймворки добавляют дополнительные слои объекты, сериализацию, middleware, callbacks, не всегда позволяя изолировать только нужные модули. Так же могут ограничивать производительность тяжелый UI или лишние зависимости бэкенда
В небольших системах это не заметно. Но при больших нагрузках появляется дополнительная латентность, лишние операции, overhead Python объектов. Поэтому команды разработки зачастую предпочитают собственный retrieval слой.

Ограничения поставщика фреймворка

Когда архитектура сильно завязана на фреймворк, появляется зависимость от его API. Если фреймворк терпит изменения код проекта тянет за собой обновления

Например в LangChain несколько раз радикально менялся API и в результате старые проекты переставали собираться, требовался рефакторинг. При прямой реализации RAG код остаётся стабильным в широком диапазоне версий зависимостей.

Отладка становится сложнее и дороже

Когда система работает через несколько слоёв абстракции, сложно понять и разложить весь пайплайн обработки данных: какие фрагменты были выбраны, какой retriever сработал, какой конечный запрос сформировался, не всегда с этой проблемой помогают справиться имеющиеся системы мониторинга и трассировки, зачастую они становятся дополнительным балластом системы, не позволяя погрузится в глубокий мониторинг пайплайна

В корпоративным системах это критично, пайплайн не должен превращаться в чёрный ящик, а вся цепочка обработки данных должна быть доступна для анализа, особенно когда нужно разбирать галлюцинации модели.

При прямой реализации пайплайн выглядит прозрачно, буквально вся цепочка от запроса до API LLM и возврата ответа в чат:
Каждый шаг легко логировать. Также важно иметь возможность легко увидеть каждый извлечённый фрагмент и его метаданные. Или собрать отдельный дебаг инструмент для участников команды внедрения, например промпт инженера или специалиста по данным,

Реальная практика индустрии

Интересно, что многие production системы используют гибридный подход в разработке. Фреймворки применяются для прототипирования, экспериментов и быстрых MVP. Но конечный пайпплайн часто выглядит как Frontend + Python backend + vector DB + embedding model + LLM API. Это минимальная и прозрачная архитектура

Интересная тенденция, cейчас на рынке появляется интересный архитектурный тренд, где RAG системы начинают делиться на два типа.

1. AI-платформы например Dify, Flowise предназначенные для построения сложных пайплайнов, экспериментов, low-code AI разработки

2. AI-серверы основные задачи которого локальный RAG, поиск по документам, вроде Glean AI knowledge base Это ближе к инфраструктурному сервису, чем к платформе. И именно сюда сейчас постепенно смещается корпоративный рынок.

Высокоуровневые AI-фреймворки очень полезны для обучения для прототипирования для исследований, но для RAG построенные на базовом стеке во многих случаях оказывается проще и надёжнее для управления пайпалном напрямую. Поэтому низкоуровневая архитектура часто оказывается более устойчивой и управляемой, чем сложная система на фреймворке.

Управление доступом к контенту

Permission-aware search механизм, который гарантирует, что пользователь видит только те документы, на которые у него есть права. В корпоративном контексте почти все документы имеют ограничения

Фреймворки зачастую имеют довольно простые сценарии ограничения прав и распределения ролей пользователей, либо изолируют задачи доступа на внешнем уровне

Собственные решения могут полноценно реализовать требуемую архитектуру доступа без ограничения инструментами фильтрации по метаданным, используя динамическое управление, как на уровне отдельных пользователей, документов и баз, так и на уровне определенных групповых политик доступа

Важно, что чем тяжелее становится система и чем выше требования к результатам качества ответа, тем более весомыми становятся архитектурные отличия, например при 10-50 документах в базе разница в скорости обработки не будет так ощутима, как при тысячах или десятках тысяч документов. Или для простого ТЗ где по сути метод извлечения сводится к векторному сходству запроса и фрагментов, обе системы будут показывать схожую эффективность, но когда к требованиям добавляются сложные условия и сценарии поиска, динамические промпты для каждого типа запросов, жесткие условия по формату ответа и границе извлечения из различных источников, предобработка и динамические пайплайны, здесь прямая работа с стеком раскрывает свои возможности

Для высокопроизводительных корпоративных систем частым вариантом является стек
Базовый ML - PyTorch, Transformers, Архитектура извлечения - Hybrid RAG, Фрагментация - NLP , LLM - OpenAI API, Embedding векторизация и Векторный поиск - SentenceTransformers, Векторное хранилище - Faiss

Какие технологии Hybrid RAG обеспечивает этот стек

Извлечение данных и фрагментация

• Fixed-size chunks

• Sliding window

• Paragraph-based

• Sentence-based

• Hybrid / semantic chunks

• Recursive / hierarchical splitting

• Adaptive / semantic similarity split

Типы векторного индекса (FAISS / GPU / гибридные)

• Flat IndexFlatL2 IndexFlatIP GpuIndexFlatL2 GpuIndexFlatIP

• HNSW (графовые индексы) IndexHNSWFlat IndexHNSWPQ IndexHNSWSQ

• IVF (inverted file) IndexIVFFlat IndexIVFPQ IndexIVFSQ IndexIVFScalarQuantizer IndexIVFPQFastScan IndexIVFPQR

• PQ / SQ (квантизация) IndexPQ IndexSQ8 IndexSQ4 GpuIndexPQ GpuIndexIVFPQ

• Модификаторы IndexRefineFlat IndexPreTransform IndexShards IndexReplicas IndexIDMap / IndexIDMap2

Типы поиска

• Vector search: IVF, PQ, HNSW, Flat

• Keyword search: BM25, TF-IDF

• Hybrid search: key search + vector search + metadata search

Методы ранжирования

• Классические: TF-IDF, BM25, Okapi BM25, Vector Space Ranking

• Векторные метрики: Cosine similarity, Dot product (inner product), Euclidean distance (L2)

• ANN-графы: HNSW / ANN-based ranking

• Гибридные: Vector + Keyword, Reciprocal Rank Fusion (RRF), Borda Count, Rank aggregation, cross-encoder reranking, ColBERT, SPLADE, dense + sparse hybrid search, query rewriting, query routing, retrieval augmentation via agents

Агрегация и фильтрация

• Методы: RRF (Reciprocal Rank Fusion) Borda Count Weighted sum Max/Min scoring

• Фильтрация: Metadata filtering Faceted search Deduplication

Методы векторизации

• По уровням текста: sentence embeddings / document embeddings / paragraph embeddings

Типы RAG / Retrieval стратегии

• Single-stage RAG

• Two-stage RAG (retrieval + re-ranking / Refine RAG)

• Hierarchical RAG

• Hybrid RAG

Технологии обработки запроса

• Multi-query RAG (short vs. long query)

• Query reformulation / dual-query

• Semantic query expansion

• Prompt augmentation

Избыточный функционал типичного RAG

Часто в готовых решениях можно увидеть архитектуру, перегруженную разнообразием поддерживаемых форматов, интеграциями с облачными хранилищами и мессенджерами. Все это тянет за собой горы зависимостей и усложняет поддержку.

Парадокс в том, что при таком обилии функций сам пайплайн обработки данных, являющийся основой системы, часто остается примитивным.
Если отбросить маркетинг, останется лишь несколько действительно минимально востребованных сценариев:

• Управление контентом: Создание баз и загрузка документов

• Управление пользователями: Учетные записи с правами доступа к отдельным базам

• Поиск и извлечение данных: Интерфейсы поиска, навигации по источникам

За время работы с такими системами я вынес одно важное наблюдение - главная проблема RAG решений кроется не в качестве моделей, а в сложности инфраструктуры. Именно это часто не дает AI проектам в компаниях выйти за рамки экспериментов.

Подходы к разработке

Существует известная трилемма: дешево, быстро, качественно. Для подходов к разработке корпоративных баз знаний она выглядит так

На рынке существуют AI продукты, где функционал поиска и извлечения данных создавался как дополнение к основному AI функционалу с довольно низким уровнем реализации ретривера, и где отсутствуют механизмы его улучшения.
Существуют и гибкие фреймворки для создания RAG систем, но они требуют наличия команды внедрения, разбирающейся в тонкостях специфических ML пайплайнов.

Отдельно стоят облачные решения, где на первый план выходит конфиденциальность. Многие компании в силу внутренних политик и ограничений не могут передавать данные вовне. Для них вариант локального RAG, при котором документы хранятся внутри периметра компании, а генерация может производиться как локальными, так и облачными LLM, является единственно возможным сценарием.

Для компаний без сильной собственной разработки основным барьером становится именно сложность инфраструктуры. Требуется понимание DevOps, настройка пайплайнов фрагментации, векторизации, индексации, выбор и конфигурация векторных баз данных и оркестрация сервисов. Поэтому решения, работающие по принципу "развернул - загрузил документы - работает", дает колоссальное преимущество, снимая необходимость содержать отдельную команду ML-специалистов

От теории к практике

С учетом периодических задач по разработке и интеграции RAG систем в корпоративном секторе и отсутствию либо существенным ограничениям готовых решений, в первую очередь необходимо сформировать основные требования к разрабатываемой системе, мои клиентские кейсы для RAG систем ограничиваются следующими прикладными задачами:

• Корпоративные базы знаний - 50-60%

• Клиентские агенты поддержки -10-15%

• Справочно информационные системы -10-15%

• AI ассистенты для взаимодействия с библиотекой документов

Поэтому разрабатываемая RAG система будет ориентирована в первую очередь под эти задачи

Так же немаловажно что часть клиентов имеет ограничения по доступу и возможности использования внешних сервисов генерации (около 20%), а значит для них необходим закрытый информационный контур с локальной генерацией.

Основные узлы RAG

Основные используемые узлы системы абсолютно стандартны и унифицированы с учетом особенностей конфигурации
Вместо тяжелых RAG фреймворков используются типовые решения на проверенных библиотеках:

Извлечение текста из PDF: pdfplumber - дает доступ не только к тексту, но и к координатам слов

Обработка естественного языка: spaCy с моделями для русского и английского

Эмбеддинги: sentence-transformers - берем multilingual-e5-base как хороший баланс качества и размера

Векторная БД: FAISS - быстрый и легкий индекс

Ключевой поиск: TF-IDF - быстрый и легкий метод

Генерация: OpenAI API или локальная Ollama

Извлечение текста из PDF с координатами

Для качественной работы с документами нужно не просто получить текст, но и понимать, где именно на странице находится каждый фрагмент. Это позволит потом подсвечивать источники прямо в PDF.

import pdfplumber with pdfplumber.open("document.pdf") as pdf: first_page = pdf.pages[0] # Извлекаем слова с их позициями на странице words = first_page.extract_words( x_tolerance=3, # допуск по горизонтали y_tolerance=3, # допуск по вертикали keep_blank_chars=False ) for word in words: print(f"Слово: {word['text']}") print(f"Координаты: x0={word['x0']}, top={word['top']}, " f"x1={word['x1']}, bottom={word['bottom']}") print(f"Страница: {word.get('page_number', 1)}")

Сегментация текста на смысловые блоки

Классический подход с нарезкой по фиксированному числу токенов часто режет предложения посередине. В технической документации это критично — теряется смысл. Мы используем сегментацию по предложениям:

import spacy # Загружаем модель для нужного языка nlp = spacy.load("ru_core_news_sm") text = "ГОСТ 1234-56 устанавливает требования безопасности. " "Испытания проводятся при температуре 20°C. " "Результаты фиксируются в протоколе." # Обрабатываем текст doc = nlp(text) # Получаем предложения sentences = [sent.text.strip() for sent in doc.sents] # Результат: [ # "ГОСТ 1234-56 устанавливает требования безопасности.", # "Испытания проводятся при температуре 20°C.", # "Результаты фиксируются в протоколе." # ] # Группируем по нескольку предложений chunks = [] chunk_size = 3 # предложений в чанке for i in range(0, len(sentences), chunk_size): chunk = " ".join(sentences[i:i + chunk_size]) chunks.append(chunk)

Такой подход сохраняет смысловую целостность и улучшает качество поиска.

Гибридный поиск: комбинируем семантику и ключевые слова

Чисто семантический поиск хорош, но для технической документации с точными терминами (номера ГОСТов, коды) ключевой поиск часто работает лучше. Комбинируем оба подхода.

Семантическая часть с sentence-transformers:

from sentence_transformers import SentenceTransformer # Загружаем модель model = SentenceTransformer('intfloat/multilingual-e5-base') # Для поиска используем префикс "query:", для документов — "passage:" query_embedding = model.encode("query: температура хранения литиевых батарей") doc_embedding = model.encode("passage: Литиевые батареи хранятся при 5-25°C") # Считаем косинусное сходство from sklearn.metrics.pairwise import cosine_similarity similarity = cosine_similarity([query_embedding], [doc_embedding])

Ключевая часть с TF-IDF:

from sklearn.feature_extraction.text import TfidfVectorizer # Создаем индекс по всем документам vectorizer = TfidfVectorizer(max_features=50000, stop_words=['и', 'в', 'на']) tfidf_matrix = vectorizer.fit_transform(all_document_chunks) # Преобразуем запрос query_tfidf = vectorizer.transform([user_query]) # Считаем релевантность from sklearn.metrics.pairwise import linear_kernel scores = linear_kernel(query_tfidf, tfidf_matrix).flatten() top_indices = scores.argsort()[-10:][::-1]

Объединение результатов - отдельная задача. Мы используем взвешенную сумму с нормализацией, но можно применять и более сложные алгоритмы ранжирования.

Улучшение пользовательских запросов

Пользователи редко формулируют запросы так, как нужно для эффективного поиска. Типичный запрос: "А не подскажете, какие там требования к хранению в последней версии стандарта?"

Для поиска лучше: "требования хранению последняя версия стандарта"

from openai import OpenAI def compress_query(original_query): """Превращает разговорный запрос в компактный поисковый""" prompt = f"""Преобразуй запрос для поиска по технической документации. Удали вводные фразы, оставь только ключевые термины. Ответ дай одной строкой, 3-8 слов. Запрос: {original_query} Поисковый запрос:""" client = OpenAI() response = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}], temperature=0 ) return response.choices[0].message.content

Это добавляет ~300ms к времени ответа, но повышает точность поиска на 15-20%.

Работа с метаданными

Корпоративные документы редко существуют сами по себе — у них есть авторы, даты, версии, типы. Добавление фильтрации по метаданным сильно улучшает качество:

# Концепт — загрузка метаданных из CSV import pandas as pd # Загружаем CSV с описанием документов metadata_df = pd.read_csv('documents_metadata.csv') # Колонки: filename, title, author, year, document_type, department # При индексации обогащаем чанки метаданными for chunk in chunks: doc_metadata = metadata_df[metadata_df['filename'] == current_file].iloc[0] chunk_entry = { 'text': chunk, 'file': current_file, 'title': doc_metadata['title'], 'author': doc_metadata['author'], 'year': doc_metadata['year'], 'type': doc_metadata['document_type'] }

Потом можно фильтровать: "покажи только регламенты за 2023 год" или "найди в документах отдела разработки".

Векторный индекс с FAISS

Для быстрого поиска по тысячам фрагментов нужен эффективный индекс. FAISS — стандарт индустрии:

import faiss import numpy as np # Допустим, у нас есть 1000 эмбеддингов размерностью 768 embeddings = np.random.random((1000, 768)).astype('float32') # Создаем плоский индекс L2 index = faiss.IndexFlatL2(768) # размерность эмбеддингов # Добавляем векторы в индекс index.add(embeddings) # на входе numpy array float32 # Поиск query = np.random.random((1, 768)).astype('float32') distances, indices = index.search(query, k=10) # ищем 10 ближайших print(f"Индексы ближайших: {indices[0]}") print(f"Расстояния: {distances[0]}")

Для продакшена можно использовать IVF-индексы, которые быстрее на больших коллекциях.

Подходы к архитектуре

Основной клиентский запрос предельно прост: внутренняя корпоративная база знаний, AI-ассистент по документам компании (инструкции, регламенты, техническая документация, wiki, договоры, база знаний поддержки). В основе лежит не желание экспериментировать с ИИ, а прикладная задача быстро находить информацию в корпоративном пуле документов.

Важно и то, что большинство RAG-интерфейсов сегодня реализованы как обычный чат. Пользователь задаёт вопрос и получает ответ. Но при работе с документами это не укладывается в логику взаимодействия и не до конца раскрывает авторитетность ответа. Пользователю важно видеть, на основании каких именно документов был сгенерирован ответ, и где именно там находится информация. Поэтому зачастую в RAG гораздо эффективнее работает двухстадийная модель поиска.

Исходя из анализа реальных внедрений, можно сформулировать архитектурные требования к минимальному корпоративному RAG.

Локальная архитектура RAG

Прежде всего, это локальное хранение документов с возможностью использования внешних AI-моделей через API, что снимает риски безопасности, но сохраняет гибкость.

Двухстадийный поиск

Сначала пользователь получает ответ по всему пулу документов и видит список релевантных источников, а после может выбрать конкретный документ и вести диалог уже в его контексте. Такой подход оказывается гораздо удобнее для навигации по базе знаний.

Простой UI с админкой

Чат с подсветкой источников, просмотр документов, загрузка, управление пользователями и доступом к коллекциям, логи запросов.

Быстрое развертывание

Возможность развернуть систему за 10-15 минут, без настроек RAG, кардинально упрощает стартовое взаимодействие с системой.

Технологический стек

Под капотом такого решения не используется готовых RAG-фреймворков, а применяется собственный пайплайн на базовом ML стеке

ML стек

• PyTorch

• Transformers

Векторный поиск

• Для семантического поиска используется sentence-transformers

• Для векторного индекса — FAISS

Генерация

• Для локальной генерации используется Ollama

• Облачная генерация поставщиками с поддержкой OpenAI API

Модели

• NLP - spaCy

• Embedding - e5

LLM (рекомендуемые)

• Облачные gpt-4o-mini

• Локальные llama3.1:8B, gpt-oss:20B

Минимальная архитектура, после нескольких внедрений

Пайпалайн импорта документов

Формирование списка источников

Сначала формируется список источников данных, которые будут интегрированы в систему RAG. Это могут быть документы, базы знаний, веб-ресурсы или другие хранилища информации.

Извлечение текста

Из выбранных источников извлекается текстовое содержимое. На этом этапе происходит загрузка данных из Source DB (базы источников) или других систем хранения.

Очистка и нормализация текста

Полученный текст очищается от лишних символов, служебных знаков и артефактов форматирования. Также выполняется нормализация структуры текста (верстки), чтобы привести данные к единому и удобному для обработки виду.

Разбиение текста на фрагменты

Подготовленный текст разбивается на отдельные фрагменты (chunks). Это необходимо для более точного поиска и обработки информации в дальнейшем.

Формирование эмбеддингов

Каждый текстовый фрагмент передается в модель эмбеддингов, которая преобразует его в векторное представление — числовой вектор, отражающий смысл текста.

Индексация в векторной базе данных

Полученные векторы сохраняются в Vector DB. При этом формируется индекс, который позволяет быстро находить семантически похожие фрагменты текста при поисковых запросах.

Извлечение метаданных

Для каждого текстового фрагмента извлекаются все доступные метаданные:

• Источник документа

• Автор

• Дата

• Раздел или глава

• Другие контекстные параметры

Сохранение метаданных

Метаданные сохраняются в отдельной базе Metadata DB, которая хранит структурированную информацию о фрагментах и их источниках.

Пайплайн ретривера

Ввод и предварительная обработка запроса

Пользователь формулирует текстовый запрос в интерфейсе системы. После получения запроса система выполняет его предварительную обработку: удаляются лишние символы, текст приводится к единому регистру, могут удаляться стоп-слова. Также выделяются ключевые слова и основные смысловые элементы запроса, которые будут использоваться на следующих этапах обработки.

Векторизация запроса

Нормализованный текст запроса преобразуется в числовой вектор с использованием модели эмбеддингов. Такое представление позволяет зафиксировать семантический смысл запроса, а не только его буквальное содержание. Вектор используется для поиска текстовых фрагментов, близких по смыслу к пользовательскому запросу.

Семантический поиск по векторной базе

Полученный вектор запроса сравнивается с векторами документов или фрагментов документов, хранящихся в векторной базе данных. Система вычисляет степень сходства между векторами и отбирает наиболее релевантные фрагменты. Такой подход позволяет находить информацию даже при отсутствии точных совпадений слов в запросе и документах.

Поиск по ключевым словам

Параллельно выполняется традиционный поиск по ключевым словам, выделенным на этапе нормализации запроса. Система ищет текстовые фрагменты, содержащие совпадения с этими словами или их формами. Этот метод позволяет быстро находить документы, содержащие точные или близкие текстовые совпадения.

Поиск по метаданным

Кроме текстового поиска осуществляется поиск по метаданным документов. К метаданным могут относиться такие атрибуты, как название документа, автор, категория, дата публикации или тематические теги. Это позволяет находить релевантные источники даже в тех случаях, когда ключевая информация отражена не в тексте, а в описательных характеристиках документа.

Ранжирование результатов поиска

Результаты каждого типа поиска проходят процедуру ранжирования. Система оценивает степень релевантности найденных фрагментов относительно исходного запроса пользователя. В результате формируется упорядоченный список документов или фрагментов, начиная с наиболее подходящих.

Объединение результатов и формирование контекста

После ранжирования результаты различных типов поиска объединяются в общий набор данных. Выполняется дополнительное реранжирование, позволяющее определить наиболее информативные и релевантные фрагменты. На основе этих данных формируется итоговый контекст, который будет передан языковой модели.

Формирование запроса для языковой модели

На основе пользовательского запроса и собранного контекста формируется структурированный запрос для языковой модели. В него включаются наиболее релевантные фрагменты документов и сопутствующая информация. Такой подход позволяет направить модель на генерацию ответа, опирающегося на найденные источники.

Генерация ответа языковой моделью

Языковая модель анализирует переданный контекст и формирует связный текстовый ответ на пользовательский запрос. Модель использует предоставленные фрагменты документов как источник фактической информации. Это позволяет повысить точность ответа и снизить вероятность генерации недостоверных данных.

Извлечение источников и возврат результата

После генерации ответа система извлекает метаданные источников, которые были использованы при формировании контекста. Эти данные позволяют отобразить пользователю ссылки на документы или фрагменты, на которых основан ответ. В результате пользователь получает не только текстовый ответ, но и перечень источников для проверки и дополнительного изучения информации.

Архитектура сервисов

Пользовательский уровень

Клиент

Пользователь взаимодействует с системой через клиентское приложение.
От клиента идут запросы в несколько основных модулей системы:

• Основной интерфейс системы (Main UI)

• Модуль администратора

• Модуль RAG

• Дополнительные сервисы

Основные сервисы системы Main UI (Основной интерфейс и логика)

Центральный модуль приложения, который:

• Обрабатывает пользовательские запросы

• Управляет логикой интерфейса

• Направляет запросы к другим модулям системы

Main UI взаимодействует с:

• Базой знаний

• Модулем RAG

• Административным модулем

• Дополнительными сервисами

Модуль администрирования системы. Функции:

• Управление базой знаний

• Управление контентом

• Управление пользователями

RAG (Retrieval-Augmented Generation)

Основной интеллектуальный модуль системы.Функции:

• Поиск релевантной информации

• Обработка пользовательских запросов

• Генерация ответов на основе базы знаний

RAG работает с несколькими хранилищами данных.

1. Хранилище данных База знаний - Основное хранилище информации системы. Содержит:

• документы,

• статьи

• инструкции

• структурированные знания

Source DB База источников. Хранит:

• оригинальные документы

• файлы

• источники информации

Используется для загрузки данных в систему.

Vector DB Векторная база данных. Используется для:

• хранения эмбеддингов

• семантического поиска

• поиска релевантных фрагментов текста

Работает совместно с модулем RAG.

Metadata DB База метаданных. Содержит:

• информацию о документах

• индексы

• связи между источниками

• параметры поиска

Дополнительные сервисы

В системе присутствует блок вспомогательных сервисов, включающий:

• Debug — инструменты отладки

• Launcher — запуск компонентов системы

• Авторизация — система аутентификации пользователей

Также ведётся система логирования, которая сохраняет события работы системы.

Расширения системы

Система поддерживает модули расширения и дополнительные инструменты. Они позволяют подключать новые функции, добавлять новые типы обработки данных, интегрироваться с внешними сервисами

Функционал решения

Основной функционал построен на обновлённом UI виджете, данная версия стала продолжением версии построенной на концепте вышедшем еще в начале июля 2025 года подробнее про него можно прочитать здесь он реализует основные элементы UI взаимодействия

В стартовую конфигурацию RAG как базовый стандарт включает современные, интуитивно понятные решения для работы с документами и работы в режиме AI ассистента.

Ключевые решения

Ключевые особенности и требования закладываемые в состав системы сборки определялись по совокупным требованиям предъявляемыми со стороны конечных потребителей к базовому основному функционалу, а также вспомогательным инструментам.

Подсветка источника в PDF с координатной привязкой

Система не просто показывает, откуда взят ответ, а открывает документ на нужной странице и подсвечивает конкретный фрагмент. Это стало возможным благодаря использованию pdfplumber, который сохраняет координаты слов при парсинге. Для пользователя это создает эффект полного доверия: он видит ответ и точно знает, где в оригинале искать подтверждение.

Двухстадийная модель поиска

Вместо классического чата, вопрос - ответ, реализована навигационная логика:

Сначала пользователь получает ответ по всему пулу документов и видит список релевантных источников

Затем может выбрать конкретный документ и вести диалог уже строго в его контексте
Это кардинально меняет сценарий использования с "просто спросить" на "исследовать документацию".

Гибридный поиск с предобработкой запроса

Комбинация семантического (sentence-transformers) и ключевого (TF-IDF) поиска дополняется автоматическим улучшением пользовательских запросов. Система переформулирует разговорный вопрос в поисковый запрос: из фразы «Нужно определить абсолютно точно и ответить на вопрос, какие требования к хранению?» формирует «требования хранению», что повышает точность на 15-20% ценой дополнительных 300 мс задержки.

Полная локальность и изоляция

Система может работать полностью в закрытом контуре: документы хранятся внутри периметра, векторный индекс на FAISS - локально, генерация - через Ollama с локальными моделями. Это снимает главный страх корпоративных заказчиков - утечку данных через облачные API.

Семантическая сегментация вместо нарезки по токенам

Вместо примитивной резки текста фиксированным блоком (которая рубит предложения пополам) используется сегментация по предложениям через spaCy. Для инструкций, договоров, технической документации с ГОСТами и кодами это критично - смысловые блоки не разрушаются, качество поиска растет.

Технические требования

Полный список требований

Не смотря на то что выше приведен далеко не полный список, не весь функционал удалось вместить в стартовую версию, часть из отдельных функций, неоправданно раздувает конечную реализацию сборки и выходит за рамки концепта универсального решения для корпоративных задач, поэтому эти решения реализуются за пределами основной сборки и формируются в виде отдельных модулей

Итоговая версия и ограничения

Итоговая версия включила основной функционал RAG системы с ограничениями для внешних поставок, для этого в состав были включены механизмы защиты функционала связанные с политикой распространения и доступа

Подготовка процесса развертывания сборки

Процесс развертывания системы был максимально упрощен и направлен на неподготовленного пользователя. Собран пакет установки для Windows и Linux Ubuntu поддерживающий как автоматический, так и ручной режимы. Ниже приведен процесс развертывания на Windows

Требования к ОС

Текущая версия сборки доступна и тестировалась для установки на Windows 10/11 или Ubuntu 22 24. без дополнительной виртуализации зависимостей

Аппаратные требования

Сборка тестировалась на серверных и десктопных аппаратных решениях оснащённых GPU с 8+ Gb VRAM с поддержкой CUDA, система может быть запущена без GPU (для этого требуется особая конфигурация зависимостей), но возможности локальной генерации будут значительно ограничены

Зависимости

Среда выполнения (~1 минута)

Для ручной установки потребуется Python версии 3.10, который нужно скачать с официального сайта, не забыв при установке добавить его в PATH.

Внешние зависимости (~4 минуты)

Для локальных моделей устанавливается сервер LLM Ollama, после чего необходимо загрузить одну из моделей, например, llama3.1.

После завершения установки в консоли выполните

ollama pull llama3.1:latest

Установка сборки

Запустится процесс загрузки модели для локальной генерации

Скачайте пакет установки и распакуйте в рабочие папки, для чего в консоли с правами администратора выполните

cd C:\ curl -L https://18f.ru/server/rag_pack_latest.zip -o rag_pack_latest.zip tar -xf rag_pack_latest.zip del rag_pack_latest.zip

Установка библиотек (ручная установка) (~10 минут)

Для автоматической установки зависимостей перейдите в следующий раздел описывающий запуск автоматической установки

Обновляем менеджер пакетов

python.exe -m pip install --upgrade pip

Устанавливаем основные зависимости стека PyTorch и CUDA

pip install torch==2.1.2+cu118 torchvision==0.16.2+cu118 torchaudio==2.1.2+cu118 --index-url https://download.pytorch.org/whl/cu118

и основные библиотеки

pip install transformers==4.50.3 faiss-cpu==1.9.0.post1

Базовые библиотеки сервера

pip install flask==3.1.0 flask-cors==5.0.0 werkzeug==3.1.3

Работа с БД

pip install psycopg2-binary==2.9.11

Обработка PDF и изображений

pip install pdfplumber==0.11.7 pdfminer.six==20250506 Pillow==11.1.0

Обработка текста и NLP

pip install spacy==3.8.4 sentence-transformers==3.4.0 scikit-learn==1.6.1 pymorphy2==0.9.1

Работа с данными

pip install pandas==1.5.3

AI API

pip install openai==1.76.2 ollama==0.4.7

Дополнительные зависимости

pip install requests==2.32.3 argparse==1.4.0 flask-jwt-extended==4.7.1 bcrypt==4.2.1 markdown==3.7 PyPDF2==3.0.1 pip install numpy==1.26.4

Установка моделей spaCy

python -m spacy download ru_core_news_sm python -m spacy download en_core_web_sm

Установка библиотек (автоматическая установка) (~9 минут)

Для автоматической установки запускаем скрипт win_install.bat от имени администратора

cd c:\rag win_install.bat

Запуск

Для запуска всех сервисов выполняем в командной строке скрипт запуска

python launch.py

После запуска всех сервисов по адресу 127.0.0.1:3003 становится доступен базовый UI системы

Можно протестировать работу на тестовой мини базе спросив что то про RAG, или создать учетную запись и сформировать новую базу знаний

В следующей части - работа с RAG системой: управление контентом, пользователями и функционалом поиска. Как адаптировать системные промпт и какие модели наиболее эффективны для облачной и локальной генерации. Как правильно формировать базы знаний и готовить исходные данные. Как определять политику доступа пользователей и формировать команду поддержки функционала RAG системы