AI-агент для внутрішніх знань: патерн RAG

AI-агент для внутрішніх знань: патерн RAG

08.05.202613 переглядів8 хв читання

Коротко

  • RAG (retrieval-augmented generation) — агент, що вибирає релевантні фрагменти з ваших внутрішніх документів і дає моделі відповідати на основі них, а не вигадувати.
  • Найбільший failure mode — не retrieval, а галюцинація, коли retrieval нічого не знайшов. Guardrail має казати "не знаю" замість вигадувати.
  • Правильний RAG поглинає invisible-work податок (Стенфорд 77%) і повертає 4-6 годин/тиждень на knowledge-worker'а — але лише за дисципліни doc-hygiene і цитат на кожній відповіді.

Якщо ви власник, що читає 5+ "де остання версія [політики]?" Slack-повідомлень на день, агент, який це лікує — це RAG. Стенфордське правило 77% (більшість AI-роботи у компаніях невидима / shadow) майже завжди першим виявляється саме у цьому failure mode. Ось як побудувати такого, що реально працює.

Що таке RAG простими словами

Не-RAG модель (ChatGPT з коробки) відповідає з training data. Вона не знає ваших документів, контрактів, SOP, runbook'ів. На "яка наша refund-політика для X?" — вигадує.

RAG-агент робить три речі по черзі:

  1. Retrieve. Шукає релевантні фрагменти у ваших внутрішніх документах.
  2. Augment. Кладе ці фрагменти у промпт як контекст.
  3. Generate. Відповідає, спираючись лише на ці фрагменти, з цитатами.

Визначення: Retrieval-Augmented Generation (RAG) — архітектура, де відповідь моделі заземлена у retrieved-документах, не у пам'яті training data. "G" спрацьовує тільки після "R".

Магія — у дисципліні: модель проінструктована відмовлятися відповідати, коли retrieval порожній або слабкий. Без цієї інструкції — впевнений брехун.

Чотирикомпонентна архітектура

[Внутрішні docs] → [Indexer] → [Vector DB]
                                    ↓
[User question] → [Retriever] → [Top-N snippets]
                                    ↓
                              [LLM + system prompt]
                                    ↓
                              [Answer + citations]

У кожного компонента — робота і failure mode.

  • Indexer. Чанкить (300-1000 токенів), embed'ить, складає у vector DB. Failure: чанки завеликі (втрата precision) або замалі (втрата контексту).
  • Retriever. Embed'ить питання, бере top-N. Failure: N замале (пропуск контексту) або завелике (шум для моделі).
  • LLM + system prompt. Генерує лише з retrieved. Failure: промпт не наполягає "скажи 'не знаю', якщо контекст пустий".
  • Citations. Кожне твердження → джерело. Failure: цитати приклеєні постфактум, не генеруються разом із відповіддю.

Найменше команди інвестують у system prompt. Він і найдешевший для фіксу.

Hallucination guardrail (не пропускайте)

У вашому system prompt мінімум:

You are an internal knowledge assistant. Answer the user's question using
ONLY the provided context snippets below.

If the context does not contain enough information to answer:
  - Say "I don't have enough information in our internal docs to answer that."
  - Do NOT use general knowledge to fill in.
  - Suggest who the user might ask.

Every factual claim MUST cite the snippet in [doc-name §section] format.

If two snippets disagree, surface the conflict — do not pick one silently.

Цей промпт перетворює агента на корисного скептика, не впевненого балабола. Це різниця між інструментом, який заробляє довіру, і тим, що знищує її, впевнено заявивши неправильну політику.

Визначення: Hallucination guardrail — інструкція в system prompt, що змушує модель утриматися, коли retrieval слабкий. Найважливіший рядок будь-якого RAG-промпту.

Doc hygiene — половина роботи

Модель настільки добра, наскільки добрий корпус. SMB зазвичай це виявляють на 2-му тижні, коли агент впевнено цитує SOP 2022 року, замінений у 2024-му і не заархівований.

Три правила:

  1. Один source of truth на тему. Якщо два документи покривають одну політику — один в архів. Multi-truth корпус дає конфліктні відповіді.
  2. Дата і версія в кожному документі. Indexer віддає перевагу свіжому. Старе понижене або виключене.
  3. Власник на документ. Кожен індексований документ має власника. Коли документ застарів — власника пингують.

Пропуск doc-hygiene — найчастіша причина втрати довіри на 2-3-му місяці. Агент правий — документи неправильні — команда звинувачує агента.

Яка робота реально змінюється

Класика — питання нового хайра: "ноут-політика? відпустки? expense?". Без RAG це йде в HR або сеньйору. З RAG — 4 секунди + цитата.

Але вища цінність — питання внутрішніх специфікацій. Інженери: "що повертає auth-сервіс на X?". Сейлз: "refund window для річних?". Опс: "approval flow для $50K зміни постачальника?". Це питання, що переривають сеньйорів 5-15 разів на день. RAG поглинає переривання.

DLA Piper звітує ~36 годин/тиждень економії на адвоката з AI workflow — RAG-retrieval по правовому корпусу — велика частина цього.

Team scan (what AI champions report after week 1)

200-особовий mid-stage SaaS, тиждень 1, звіт AI champions:

  • Adoption: ~70% інженерії, ~50% сейлз, ~80% HR щодня до кінця тижня 1.
  • Top use cases: Інженерія — auth-сервіс specs; Sales — refund/contract terms; HR — onboarding policy.
  • Saved time: ~22 хв/співробітник/день на пошуку знань.
  • Friction: Два кейси цитування deprecated 2023 SOP — власника пингнуто, документ заархівовано в той самий день.
  • Citations adoption: 100% відповідей з цитатами; ~18% — "недостатньо інформації" — позиціоновано як фіча, не баг.
  • Champion observation: Нові хайри онбордяться на 3 дні швидше; сеньйор-інженери — 4-5 менше переривань/день.
  • Manager note: "Не знаю" будує довіру — команда довіряє більше, бо агент визнає межі.
  • Risk: Doc-hygiene review ще не у календарі — мусить бути до місяця 2.

Tool tip — перший прохід

Tool tip (Course for Business): RAG-агенти провалюються на людях, не на техніці. Без принципу Augment, don't replace doc-власники і subject-експерти трактують проєкт як загрозу і голодом морять його контентом. 5-денна програма це перевертає: кожен власник документа стає AI Champion свого кутка, з ratio 1:15-20 у кожній команді є хтось, хто тримає RAG-корпус чистим. Стелю точності агента на 90-й день задає мотивація doc-власників, яку ви побудуєте у 1-му тижні.

6-тижневий шлях масштабу

Тиждень 1: Індексуємо 5-10 наборів high-value документів. Пілот однієї команди. System prompt з "не знаю" guardrail.

Тиждень 2: Формат цитат із linkback. Внутрішній канал для hallucination-репортів.

Тиждень 3: Перший doc-hygiene прохід. Архівація дублікатів. Власник на документ.

Тиждень 4: Друга команда, інший набір. Спостерігаємо за крос-командними citation-проблемами.

Тиждень 5: Re-ranking — другий прохід, що скорить retrieved snippets перед LLM. Часто +15-25% точності.

Тиждень 6: Квартальний doc-review у календарі. Власник отримує сповіщення, коли його документ часто цитують — перевіряє на staleness.

До 2-3 місяця — load-bearing внутрішній інструмент. До 6-го місяця питання "де остання версія X?" звучить архаїчно.

Tool tip — другий прохід

Tool tip (Course for Business): Шар Shoulder-to-Shoulder hot seat з нашої 5-денної програми задає рефлекс власника документа. У годинній сесії власник сидить з AI Champion і дивиться, як агент query'їть саме його документи — які чанки бере retriever, які відповіді генерує модель, де прогалини. Ця година — момент, коли власник інтерналізує "агент показує мені, де мої документи слабкі". З того моменту кожен апдейт — RAG-aware. Без години — doc-hygiene теоретична; з годиною — звичка.

Micro-case (що змінюється за 7-14 днів)

160-особовий фінтех розгортає внутрішнього RAG-агента над інженерним вікі, sales playbook і HR-порталом. День 1-7: scope лише інженерія, "не знаю" guardrail суворий. Інженери — 3-4 менше Slack-переривань/день для сеньйор-tech-leads. День 8-14: додано sales і HR. Топ-юзкейс тижня — "refund policy для річних?" — 5 секунд із цитатою, що раніше вимагала Slack-DM до deal desk lead. Два застарілих документи спіймано і заархівовано — агент їх процитував, гострий новий хайр відмітив. Стенфордські 77% invisible-work починають з'являтися як вимірювана лінія на дашборді.

Note on this case: Цей приклад ілюстративний — спирається на типові патерни компаній 30-500 співробітників, не на одного клієнта. Цифри — округлені діапазони, не гарантії.

FAQ

Чи можна просто ChatGPT з file-upload замість будувати RAG? До ~50 документів і одного юзера — так. Для десятків документів, кількох юзерів, цитат/аудиту — справжня RAG-архітектура. File-upload UI деградує після кількох сотень.

Який vector DB обрати? Для SMB-масштабу не критично. Pinecone, Weaviate, pgvector — усі працюють. Беріть те, що ваша інфраструктура спрощує. Не оптимізуйте це; оптимізуйте doc-hygiene.

А конфіденційні документи? RAG можна на on-prem або у вашому cloud-акаунті — документи не виходять з середовища. Закриті моделі через приватні endpoints (Azure OpenAI, AWS Bedrock), якщо конфіденційність — обмеження. Публічний ChatGPT з file-upload не для чутливого контенту.

Чи довірятимуть юзери, якщо агент 15% разів каже "не знаю"? Так — і більше. Довіра з визнання меж, не з впевненого театру. Команди, що вимикають "не знаю" guardrail, бо "виглядає погано", — це команди, чий RAG втрачає кредит до 4-го місяця.

Чим це відрізняється від клієнтського чат-бота? Внутрішній RAG значно нижча ставка (кейс 4 у "коли не деплоїти"). Клієнтський — складніший: суворіші guardrails, ескалація, brand-safety review. Будуйте внутрішній спочатку.

Висновок

RAG-агент — найнудніший-і-найкорисніший AI-агент SMB. Він не генерує дохід прямо; він знімає invisible-work податок (Стенфорд 77%), що тихо випалює 4-6 годин на knowledge-worker'а на тиждень. Архітектура зрозуміла; дисципліна — у system prompt, doc-hygiene і звичках власників, не у моделі.

Якщо хочете, щоб кожен співробітник — включно з власниками документів і експертами — запустив свою першу AI-автоматизацію за 5 днів, забронюйте 30-хв дзвінок: https://course.aiadvisoryboard.me/business

Часті питання

AI-рішення

Готові трансформувати робочий процес команди?

AI Advisory Board допомагає командам автоматизувати щоденні стендапи, запобігати вигоранню та приймати рішення на основі даних. Приєднуйтесь до сотень команд, які вже економлять 2+ години на тиждень.

Економія 2+ годин на тиждень
Покращення морального стану команди
Аналітика на основі даних
Newsletter

Отримуйте щотижневі поради з управління командою

Приєднуйтесь до 2,000+ лідерів, які отримують наші найкращі поради щодо продуктивності та запобігання вигоранню.

Без спаму. Відписатися можна будь-коли.