единица 1 / 11

Какво е RAG и защо е необходимо?

Печалби:

  • Обяснявайки, че RAG инжектира контекст, без да променя теглата на модела и работи с логиката на „отворен изпит“
  • Сравняване на RAG с подходи за фина настройка и дълъг контекст според цена, навременност и сценарий на използване
  • Изброяване на стъпките на типичен RAG тръбопровод, състоящ се от фази на индексиране и заявка

Колкото и мощен да е езиковият модел (изкуствен интелект, който разбира и създава текст; отсега нататък ще го наричаме модел за по-кратко), той не знае договора, който вашата компания е подписала вчера, вашата вътрешна wiki страница (вътрешна база от знания) или бележката за изданието, публикувана тази сутрин. Моделът е ограничен до общи познания до датата, на която е бил обучен; Това се нарича „крайна дата за образование“. RAG (Retrieval-Augmented Generation) запълва точно тази празнина: той намира документите на компанията, свързани с въпроса, дава го на модела като контекст (т.е. допълнителния текст, който ще прочете, докато създава отговора) и произвежда отговора въз основа на този контекст.

В този раздел ясно ще видим какво е RAG, кога се предпочита пред кои алтернативи и стъпките на типичен RAG тръбопровод. Всички следващи единици ще задълбочават частите на тази карта една по една.

Основната идея на RAG: Open Book Exam

Нека обясним RAG с едно изречение: „Първо намерете съответния документ, след това накарайте модела да прочете този документ и съответно да отпечата отговора.“

Най-полезната аналогия е следната: RAG премества модела от „изпит със затворена книга“ към „изпит с отворена книга“. При изпита по затворена книга студентът отговаря само по памет; Има голям риск да измислите това, което не помните. При изпита по отворена книга студентът отговаря, като гледа източника, поставен пред него. В RAG моделът вече не отговаря от собствената си памет, а от текущия и специфичен текст, който му давате.

Критична точка: RAG не променя теглата на модела, тоест милиардите числени параметри, които моделът е научил. Вие не преквалифицирате модела. За всеки въпрос вмъквате парчета текст, свързани с този въпрос, в подканата (текст с инструкции, изпратен до модела). Така че не е нужно да преобучавате модела, когато документът се актуализира; просто опреснявате съответния запис в базата данни за търсене.

Съвет: Два въпроса определят качеството на RAG: (1) Намерихте ли правилния документ? (2) Моделът разчете ли го правилно? Първото е „качество на извличане“, второто е „качество на генериране“. Двете се измерват и подобряват отделно.

RAG, фина настройка или дълъг контекст?

Три пътя често се бъркат, когато се търси решение на организационен проблем. Нека изясним различията им. Фината настройка е актуализиране на теглата на модела с вашите данни и обучението му на ново поведение/стил. Дълъг контекст означава попълване на всички документи директно в подканата без никакъв избор.

подход

Какво прави

Кога е подходящо?

Цена / риск

ПАРЦАЛ

Вмъква съответния документ като контекст

Често променяща се, обширна, специфична информация

Ниска; лесно се актуализира, източникът може да бъде цитиран

Фина настройка

Актуализира теглата с нови данни

Фиксиран стил/формат/преподаване на език

Висока; Изисква се преквалификация при всяка актуализация

Само дълъг контекст

Попълва всички документи в подканата

Малък стационарен комплект документи

Цената на токена и рискът от „загуба на средната част“ се увеличава

Като правило: фината настройка учи модела как да говори; RAG казва на модела какво да знае. В повечето корпоративни сценарии първо се изпробва RAG, защото е евтин, може да се актуализира и може да покаже източника на отговора. Дългият контекст е разумен, ако комплектът документи е наистина малък и фиксиран (напр. едно ръководство от 20 страници); Но с хиляди страници е скъпо и моделът може да пропусне информация в средата на дълъг текст.

Типичен RAG тръбопровод

RAG се състои от две основни фази: индексиране (подготовка, извършва се еднократно или периодично) и заявка (работи по всеки потребителски въпрос).

Индексиране стъпка по стъпка (офлайн, без чакане от страна на потребителя):

  1. Събиране: Изтеглете документи от източници (PDF, wiki, тикет система, база данни, имейл).
  2. Разкъсване: Разбийте дълъг текст на по-малки управляеми части.
  3. Вграждане: Преобразувайте всяка част във вграждане (числовия вектор, който носи значението на текста).
  4. Запазване: Запишете векторите заедно с текста и метаданните (източник, дата, информация за разрешение) във векторната база данни.

Заявка стъпка по стъпка (онлайн, докато потребителят чака):

  1. Преобразувайте въпроса на потребителя във вграждане.
  2. Извлечете най-сходните части от векторната база данни.
  3. Поставете тези части + въпрос в подканващ шаблон.
  4. Вземете контекстуалния отговор и неговите източници от модела.

# Концептуално описание на фазата на запитване (не зависи от езика)question = "Колко дни годишен отпуск?"question_vektor = embed(question)parts = vektor_db.search(question_vektor, top_k=4) # most similar partsprompt = f"""Отговорете на ВЪПРОСа, като използвате КОНТЕКСТА по-долу. Ако отговорът не е в контекста, кажете "Нямам информация за това." Fitting.CONTEXT:{parts}QUESTION: {question}"""answer = model.uret(prompt) # напр. модел: claude-opus-4-8

Този поток е карта на всеки етап, която ще разопаковаме една по една в следващите части.

Слаба подкана / Силна подкана

Дори при същия RAG контекст, качеството на подканата променя отговора.

Слаба подкана (отворена за моделиране, не изисква ресурси):

Използвайте тази информация и кажете годишен отпуск: {parts}. Въпрос: {въпрос}

Мощна подкана (заземяване + разрешение „Не знам“ + заявка за ресурс):

Отговорете само въз основа на КОНТЕКСТА по-долу. Ако няма ясен отговор в контекста, напишете „Не можах да намеря информация за това в документацията“; Не гадайте. Добавете тага [Източник: име на файл] на частта, на която разчитате, в края на отговора си. КОНТЕКСТ: {pieces} ВЪПРОС: {question}

Три мини калъфа

Случай 1 — Асистент Човешки ресурси (Човешки ресурси). Една компания има наръчник по човешки ресурси от 340 страници и служителите задават средно по 90 въпроса на ден. Опитана е фина настройка, но тъй като ръководството се актуализира всеки месец, всеки път се налага преквалификация; Цената достига хиляди долари на месец. След преминаване към RAG актуализацията беше намалена до стъпката „повторно индексиране на документа“ (минути) и процентът на верните отговори се увеличи от 71% на 93% при ръчно измерване.

Случай 2 — Поддръжка на клиенти. Екипът за поддръжка има 12 000 решени билета и 800 помощни статии. Отнема средно 4 минути на представител, за да намери ръчно отговор. Когато асистентът на RAG донесе 5-те най-подходящи записа и изготви чернова на отговор, времето беше намалено до 40 секунди; Но екипът осъзна риска от „изглеждане несигурен, като представи грешна статия“ и направи цитирането на източника задължително.

Казус 3 — Закон. Екип по договори попита "в кои договори клаузата за поверителност продължава 5 години?" задава въпроса той. В дългото контекстно изпитание 60 договора бяха попълнени в една подкана; моделът пропусна средните два договора. Когато само съответните елементи бяха въведени с RAG, цената на токена намаля с 80% и липсващото пропускане беше нулирано.

Защо е необходим RAG?

  • Актуалност: Имате достъп до информация след крайната дата на обучението.
  • Специална информация: Вашите вътрешни документи не са включени в обучението на нито един модел; Само ти можеш да дадеш.
  • Проверяемост: Можете да цитирате източника на отговора (цитиране) — от съществено значение за одита и доверието.
  • Контрол на халюцинациите: разчита на текста, поставен пред него, вместо да измисля модел.
  • Цена: Пускането в експлоатация е много по-евтино и по-бързо от фината настройка.
Внимание: RAG не е магия. Ако въведете грешно парче, моделът стига до грешен отговор, изглеждайки „уверен“. Имайте предвид фразата "Качество на извличане = RAG качество".

Често срещани грешки

  • Грешка за фина настройка на RAG: RAG не променя теглата; Просто добавя контекст. Объркването на тези две ще доведе до избор на грешна архитектура.
  • Не позволява „Не знам“: Ако подканата остави модела свободен да попълни празното място, той ще компенсира.
  • Без цитиране на източници: Отговор без източник не може да бъде проверен; Потребителят не може да забележи грешката.
  • Натъпкване на всичко в една подкана: Дългият контекст изглежда евтин, но е скъп и пропуска средната информация.
  • Засядане в генерирането без измерване на извличането: Ако отговорът е лош, първо попитайте „Пристигна ли правилната част?“ трябва да се попита.

В обобщение

  • RAG е подход, който инжектира документи, свързани с въпроса, в модела като контекст; не променя тежестите ("изпит по отворена книга").
  • Фината настройка учи стил/формат, RAG дава текуща и специфична информация; дългият контекст работи добре за малки фиксирани набори. В повечето сценарии първо се изпробва RAG.
  • Конвейерът има две фази: офлайн индексиране (парче + вграждане + запазване) и онлайн заявка (извличане + подкана + генериране).
  • RAG осигурява навременност, специфична информация, възможност за проверка, контрол на халюцинациите и ниска цена.
  • Качеството на системата зависи пряко от качеството на извличане: грешно парче означава грешен отговор.

Задача за приложение

Изберете истински източник на информация от собствения си екип (напр. документ за процедурата или страница с често задавани въпроси). (1) Напишете 5 фактически въпроса за този източник. (2) Отбележете коя част от документа съдържа правилния отговор за всеки въпрос — това става вашият списък със „златни отговори“. (3) Използвайки шаблона „силна подкана“ по-горе, поставете ръчно съответния раздел като контекст и попитайте модел. (4) Сравнете отговора, даден от модела, със златния отговор и маркирайте като вярно/невярно. Това е първата ръчна версия на оценката, която ще автоматизирате в бъдещи модули.

контролен списък

  • [ ] Мога да обясня с едно изречение, че RAG не променя теглата, а просто добавя контекст.
  • [ ] Мога да правя разлика между RAG, фина настройка и дълъг контекст и кога е подходящо.
  • [ ] Мога да преброя фазите на индексиране (collect-shred-embed-save) и заявка (embed-fetch-prompt-generate) по ред.
  • [ ] Знам защо добавих инструкциите „ако не е в контекста, кажете, че не знам“ и „цитирай източника“ към подканата.
  • [ ] Мога да адаптирам принципа „Качество на извличане = RAG качество“ към моя собствен случай.