Nythrex

Послуга · Retrieval-augmented generation

LLM, що відповідає з ваших даних — і показує, де це знайшов.

Retrieval-augmented generation (RAG) під'єднує мовну модель до ваших документів, вікі, тікетів і баз даних, тож відповіді беруться з ваших знань, а не з «пам'яті» моделі. Ми будуємо RAG-системи, що точні, враховують права доступу й піддаються вимірюванню — а не чат-бот, який упевнено помиляється в кожній п'ятій відповіді.

Документи ·вікі · тікетиРозбір і поділЕмбедингиПошуковий індексПитаннякористувачаГібридний пошук+ rerankLLM зконтекстомОбґрунтована відповідь[1] [2] джерела
Два конвеєри: індексація підтримує актуальність даних, а конвеєр питань знаходить потрібні фрагменти й відповідає на їх основі.

Коли RAG — правильний інструмент

RAG найкраще працює там, де люди витрачають час на пошук і перечитування інформації, що вже десь є у компанії. Типові сигнали: оператори підтримки шукають у базі знань під час дзвінка, інженери ставлять одні й ті самі питання про внутрішні системи, продажники копаються в документації продукту, комплаєнс звіряє політики. Якщо проблема в поведінці чи форматі, а не в браку знань, RAG не допоможе — різницю пояснюємо в гайді RAG vs fine-tuning.

Копілот підтримки

Чернетки відповідей на тікети зі статей довідки, минулих рішень і документації — з посиланнями, які оператор може перевірити.

Внутрішній асистент знань

Одне місце для питань про політики, процеси й системи з Confluence, SharePoint, Notion чи Google Drive.

Допомога для клієнтів

Відповіді на сайті чи в застосунку лише з публічної документації та з коректною передачею людині.

Продажі й пресейл

Відповіді на анкети безпеки й тендерні запити з погодженого контенту — з рецензентом у циклі.

Асистент для інженерів

Питання про кодову базу, runbook-и, інциденти й архітектурні рішення.

Пошук у договорах і політиках

Знаходить пункти й зобов'язання в сотнях документів — з точними цитатами.

Звідки насправді береться якість RAG

Коли RAG-система відповідає погано, винна рідко модель. Більшість збоїв стається раніше: таблицю з PDF розібрано в кашу, потрібний абзац розрізано між двома фрагментами, пошук повернув схожий, але застарілий документ, або відповідь лежала в таблиці, яку ніхто не проіндексував. Тому найбільше зусиль ми вкладаємо в конвеєр, а не в промпт.

Типові точки збою і як ми з ними працюємо
ЕтапЩо йде не такЩо робимо ми
РозбірТаблиці, скани й багатоколонкові PDF перетворюються на шумРозбір з урахуванням макета, OCR за потреби, перевірка таблиць на реальних файлах
Поділ на фрагментиВідповідь розірвана між фрагментами або тоне в зайвому текстіФрагменти за структурою (заголовки, розділи) з перекриттям, налаштованим на вашому контенті
ПошукЧисто векторний пошук пропускає точні терміни: артикули, імена, коди помилокГібридний пошук (ключові слова + вектори) і reranker для фінального порядку
АктуальністьСтара версія політики виграє в чинноїІнкрементальна переіндексація, метадані версій і ранжування з урахуванням дати
Права доступуАсистент цитує документи, які користувачу бачити не можнаФільтри доступу в самому пошуковому запиті, а не після нього
ВідповідьМодель заповнює прогалини правдоподібною вигадкоюІнструкції відповідати лише з контексту, сценарій «не знаю» і обов'язкові посилання

Як ми вимірюємо RAG-систему

Ще до розробки ми збираємо набір реальних питань із відомими правильними відповідями — зазвичай від 50 до 200, разом з людьми, які користуватимуться системою. Кожна зміна розбору, поділу, пошуку, промптів чи моделей проганяється на цьому наборі. Ви бачите цифри, а не кілька вибраних демо-питань. Детальніше — в гайді Оцінювання LLM для не-ML команд.

  • Повнота пошуку: чи потрапив потрібний фрагмент у контекст узагалі?
  • Правильність відповіді: чи відповідь правильна порівняно з еталоном?
  • Достовірність: чи кожне твердження підтверджене наведеними джерелами?
  • Якість відмов: чи каже система «не знаю», коли відповіді в даних немає?
  • Затримка й вартість питання — поруч із якістю, щоб компроміси було видно.

Референсна архітектура

Інтерфейси

  • Веб-чат
  • Бот у Slack / Teams
  • Панель у helpdesk
  • API

Оркестрація

  • Переформулювання запиту
  • Гібридний пошук
  • Reranking
  • Збирання промпту
  • Посилання на джерела

Безпека й якість

  • Фільтри доступу
  • Захист від prompt injection
  • Оцінювання в CI
  • Збір відгуків

Індексація

  • Конектори
  • Розбір і OCR
  • Поділ на фрагменти
  • Ембединги
  • Інкрементальна синхронізація

Сховище (ваша хмара)

  • Векторний / пошуковий індекс
  • БД метаданих
  • Об'єктне сховище
  • Журнали аудиту
Кожен шар замінний: моделі, векторні сховища й конектори можна змінити без переписування.

Сховище обираємо під ваш стек: PostgreSQL з pgvector, якщо у вас уже є Postgres, Azure AI Search на Azure, OpenSearch чи Elasticsearch, якщо вони вже працюють, або окрему векторну БД для дуже великих колекцій. Компроміси — у нашому порівнянні векторних баз даних.

Як проходить RAG-проєкт з Nythrex

  1. 1

    Аудит джерел (дні, а не тижні)

    Дивимося на ваші реальні документи й системи: формати, обсяги, права доступу, як часто вони змінюються і хто за них відповідає.

  2. 2

    Тестовий набір

    Разом з майбутніми користувачами пишемо питання й еталонні відповіді, які система має давати правильно.

  3. 3

    Proof of concept

    Тонкий наскрізний конвеєр на репрезентативній частині даних. Результат: точність, аналіз помилок, затримка й вартість питання — і рішення go / no-go.

  4. 4

    Продакшн-розробка

    Конектори до всіх джерел, права доступу, інтерфейс там, де люди вже працюють, моніторинг, зворотний зв'язок, оцінювання в CI і розгортання у вашій хмарі.

  5. 5

    Супровід і покращення

    Щотижневий розбір питань без відповіді й з негативними оцінками — вони стають новими тест-кейсами й правками контенту.

Що ви отримуєте у власність

0/5

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

Читайте також

ГайдRAG vs fine-tuning vs промптингRAG додає знання, fine-tuning змінює поведінку, промптинг — точка старту. Практичний гайд із вибору: дерево рішень, вартість, пастки й реальні приклади.Безкоштовний інструментВибір: RAG чи fine-tuningДайте відповідь на чотири питання «так/ні» й отримайте рекомендацію — RAG, fine-tuning, довгий контекст чи промпт-інжиніринг — з наступним кроком для перевірки.Приклад проєктуКопілот підтримки для B2B SaaSІлюстративний RAG-проєкт: копілот у Zendesk готує чернетки відповідей з посиланнями на статті й тікети — discovery, PoC, архітектура, висновки.ПорівнянняПорівняння векторних БДВекторні сховища для RAG: pgvector, Pinecone, Qdrant, Azure AI Search і OpenSearch — експлуатація, гібридний пошук, фільтри, масштаб, вартість.ГайдОцінювання LLM для не-ML командЯк оцінювати LLM-функцію без команди data science: тестовий набір, метрики, обережне використання LLM-суддя, оцінювання в CI та читання результатів.ГайдAI-чатбот підтримки, за який не соромноAI-чатбот підтримки, якому довіряють: відповіді з джерел, чіткі межі, передача людині, безпечні дії, захист від зловживань і чесні метрики.

Потрібен другий погляд на ваш проєкт?

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

Обговорити проєкт