Прибуток:
- Проектування компонентів і потоку даних наскрізного корпоративного асистента RAG
- Об’єднання даних із багатьох джерел (wiki, квиток, PDF, база даних) в одному помічнику
- Приймайте архітектурні рішення щодо масштабованості, кешування та затримки
У попередніх розділах ми вивчали частини одну за одною: вбудовування, векторну базу даних, фрагментацію, пошук. Тепер давайте об’єднаємо їх і створимо наскрізну архітектуру помічника, який спілкується з даними вашої компанії. Мета полягає в тому, щоб запитати співробітника: «Яка наша політика щодо відпусток?» Система, де люди можуть задавати запитання, відповіді базуються на справжніх внутрішніх документах, цитатах і поєднують кілька джерел даних. Цей підрозділ обробляє всю архітектуру, потік даних і рішення на рівні виробництва.
Наскрізні компоненти
Корпоративний помічник RAG складається з двох окремих ліній. Лінія індексації (офлайн) готує дані; Рядок запиту (онлайн) відповідає на запитання.
Компоненти лінії індексації:
- З’єднувачі: з’єднувачі, які отримують дані з джерел — вікі, системи квитків, сховища файлів, бази даних, електронної пошти.
- Нормалізація: Перетворення різних форматів (PDF, HTML, DOCX) в чистий текст; очищення верхнього/нижнього колонтитула.
- Розбиття на фрагменти + метадані: Розбивання на фрагменти та тегування (джерело, дата, авторитет).
- Вбудовування + завантаження: запис векторів і метаданих у векторну базу даних.
Компоненти конвеєра запитів:
- Попередня обробка запитів: переписування, децентралізація.
- Отримання: гібридний пошук + фільтр метаданих + переранжування.
- Створення підказки: розміщення контексту + питання + інструкції в шаблоні.
- Генерація: обґрунтована (контекстуальна) відповідь з моделі + джерела.
- Постобробка: форматування цитат, перевірка безпеки, журналювання.
Порада: фізично відокремте рядок індексування від рядка запиту. Індексація повільна та періодична (виконується партіями протягом ночі); Лінія запиту має бути легкою та негайною. Змішування двох рядків змушує інтенсивну обробку, поки користувач чекає.
Візуалізація потоку даних
[ІНДЕКСУВАННЯ - офлайн]Ресурси → Нормалізація → Фрагмент+Метадані → Вставити → Векторна БД (wiki, квиток, PDF, БД)[QUERY - онлайн]Запитання користувача → Попередня обробка → Отримання (гібридний+фільтр+переранжування) → Підказка (контекст+питання+інструкція) → Модель → Відповідь+Джерело → Користувач
Об’єднання даних із кількох джерел
У реальних компаніях відповідь не зупиняється на одному місці. «Як повернути гроші клієнту?» Відповідь на запитання можна знайти як у довідковій статті (процедура), так і в історії тикетів (реальні приклади), а також у полісі PDF (правила). Асистент повинен шукати їх усіх в одному пулі.
Критичний момент: під час об’єднання ресурсів в одне векторне сховище кожен шард повинен містити метадані `source_tour`. Таким чином, ви можете шукати їх усіх і фільтрувати їх, якщо необхідно, наприклад «доставляти лише офіційні поліси». Крім того, різні джерела мають різний рівень надійності: офіційна політика > довідкова стаття > записка працівника. Ви можете вказати цей пріоритет у переранжуванні або підказці.
Джерело
Тип вмісту
довіра
Частота оновлення
Політика PDF
офіційне правило
висока
щомісяця
Довідкова стаття
Процедура
середньо-високий
щотижня
Історія квитків
реальний зразок
середній
Безперервний
вікі
Змішана/поточна примітка
змінна
Безперервний
Масштабованість, кеш і затримка
У виробництві виділяються три проблеми. Затримка: якість роботи погіршується, якщо користувач чекає більше 2 секунд. Рішення: відобразити відповідь у потоковій формі — вона виливається на екран, коли модель пише. Кеш: для поширених запитань і повторюваних контекстів кеш підвищує швидкість і зменшує вартість. Масштаб: зі збільшенням кількості користувачів необхідно мати можливість горизонтально масштабувати виклики пошуку та моделювання.
Емпіричне правило щодо вартості: найдорожчим кроком зазвичай є кількість жетонів, що надходять до більшої моделі. Таким чином, скорочення контексту до 4 хороших частин шляхом переранжування покращує як якість, так і вартість. Загальною моделлю є використання меншої/швидшої моделі для простої класифікації або маршрутизації та більш потужної моделі для остаточної відповіді (наприклад, claude-opus-4-8).
Застереження: не встановлюйте індексацію як «зроби це один раз і забудь». Документи змінюються, видаляються, додаються. Встановіть стратегію повторного індексування: виявляйте змінені документи та повторно обробляйте лише їх. Застарілий індекс дає відповідь, яка виглядає актуальною, але є неправильною.
Слабка архітектура / Сильна архітектура
Слабкий (один сценарій, все змішано):
Коли користувач запитує: прочитайте документи в цей момент, подрібніть їх, вставте, здійсніть пошук, дайте відповідь. # Проблема: все індексування повторюється для кожного запитання; секунди затримки, # без відокремлення джерела, без фільтра, без оновлення.
Потужний (розділені канали + метадані + кеш + потокове передавання):
Індексування: пакетна робота вночі, оновлення змінених документів. Запит: легкий рядок — попередня обробка → гібридний пошук+фільтр → переранжування → підказка → модель (потокове передавання) → цитування → журнал. Часті запитання та джерело зберігаються в кеші.
Три міні-чохли
Випадок 1 — Плутана лінія, велика затримка. Стартап написав сценарій, який повторно обробляє PDF-файли з кожним запитанням; Кожна відповідь займала в середньому 11 секунд. Коли рядок індексації був розділений і дані були попередньо передані у векторне сховище, час запиту скоротився до 1,3 секунди, а при потоковій передачі «перше слово» з’явилося через 400 мс.
Випадок 2 — Забагато ресурсів, неправильний пріоритет. Помічник служби підтримки приділяв однакову увагу PDF полісу та старим білетам; Інколи в якості офіційного правила модель представляла неправильний рейтинг співробітника дворічної давності. Коли до підказки було додано метадані source_tour та вказівку «врахувати офіційну політику в разі конфлікту», кількість помилок із помилковим пріоритетом зменшилася на 89%.
Випадок 3 — Застарілий індекс. Кадровик працював з індексом, який не оновлювався 3 місяці; Політика відпусток змінилася, але помічник говорив про старі часи. Коли було встановлено щоденне оновлення, яке виявляє змінені файли, частота поточних відповідей зросла з 70% до 99%.
Поширені помилки
- Змішування рядків індексування та запиту: важка обробка виконується, поки користувач чекає; затримка вибухає.
- Не вказує тип джерела в метаданих: немає пріоритезації та фільтрації; Ненадійне джерело здається офіційним.
- Не встановлюється стратегія оновлення: індекс стає застарілим; Виробляються неправильні відповіді, які здаються актуальними.
- Пропустити потокове передавання: користувач дивиться на порожній екран; Уявна затримка стає високою.
- Використання найбільшої моделі на кожному кроці: вартість зростає без потреби; Залиште керування меншій моделі.
Підсумовуючи
- Корпоративний помічник RAG складається з двох окремих ліній: офлайн-індексування та онлайн-запит; розділити їх фізично.
- Індексація = конектор + нормалізація + фрагмент/метадані + вбудовування/завантаження; запит = попередня обробка + пошук + підказка + генерація + постобробка.
- Дані з кількох джерел об’єднуються в одне сховище, але метадані source_type і пріоритет довіри зберігаються.
- Потокове передавання та кеш-пам’ять для затримки, обмеження контексту та вибір моделі з точки зору вартості є критично важливими.
- Без повторної індексації індекс стає застарілим; Регулярно переробляйте документи, що змінюються.
Аплікаційне завдання
Намалюйте архітектурну схему помічника для власної команди. (1) Визначте принаймні три реальні джерела даних і запишіть потребу в конекторі, частоту оновлення та рівень довіри для кожного. (2) Намалюйте лінії індексування та рядки запиту окремо за допомогою прямокутної стрілкової діаграми. (3) «Де я можу зменшити затримку та витрати в цьому помічнику?» Напишіть не менше двох конкретних рішень до питання. (4) Опишіть свою стратегію оновлення одним реченням: який ресурс буде переіндексовано та як часто?
контрольний список
- [ ] Я можу намалювати рядки індексування та запиту окремо та з правильними компонентами.
- [ ] Я можу поєднувати дані з кількох джерел із джерелом_типу та пріоритетом довіри.
- [ ] Я можу приймати рішення щодо потоку/кешу щодо затримки та вибору моделі щодо вартості.
- [ ] Я знаю, чому стратегія повторного індексування є важливою.
- [ ] Я пам’ятаю, що найдорожчим кроком у моїй архітектурі зазвичай є маркер, який переходить до більшої моделі.