Зміст
Коротко
Автор платформи вакансій розповів, що змінюється, коли RAG перестає бути демонстрацією та починає обробляти понад 10 тисяч оголошень на день. RAG — це підхід, за якого велика мовна модель отримує знайдені за змістом фрагменти даних перед формуванням відповіді або оцінки.
Основні труднощі виявилися не в самій моделі. На точність і витрати впливають поділ документів, якість вхідних даних, зберігання векторів і можливість помітити тихі збої в ланцюжку обробки.
Що сталося
Платформа зіставляє вакансії з профілями кандидатів. Спершу опис оголошення очищають і приводять до єдиної форми, потім ділять на фрагменти, створюють для них векторні подання та шукають найближчі за змістом. Після цього LLM оцінює відповідність вакансії.
Фрагменти фіксованого розміру виявилися невдалими: вони розривали пов’язані вимоги та умови. Краще спрацював рекурсивний поділ — спочатку за абзацами, потім за рядками й реченнями — з невеликим перекриттям сусідніх фрагментів. Так важливе речення на межі не зникає з пошуку.
Не менш корисною була попередня нормалізація. Різні системи найму повертають описи в різних форматах, іноді з HTML. Якщо не очистити й не уніфікувати вхідні дані до поділу, порожні або спотворені фрагменти непомітно потрапляють до пошуку.
Чому це важливо
Поділ тексту — не другорядне налаштування. Він визначає, який контекст знайде система, скільки векторних подань доведеться побудувати та скільки кандидатів буде передано до дорожчого етапу оцінювання моделлю.
Автор порівняв хмарну модель OpenAI для векторних подань із локальною моделлю на тій самій машині. Локальний варіант був дешевший, але гірше розрізняв специфічні вимоги у вакансіях. Економія під час побудови векторів обернулася шумнішими результатами пошуку та зайвими зверненнями до LLM.
Зберігання векторів у pgvector поруч з даними PostgreSQL також спростило експлуатацію. Окреме векторне сховище зручне для швидкого прототипу, але потребує синхронізації. В одній базі вакансію та її вектори можна записати однією транзакцією, не звіряючи два джерела даних після збою.
На практиці
Починайте з будови власних документів, а не з універсального розміру фрагмента. Вакансія, договір і картка товару мають різну внутрішню структуру, тому правила поділу мають зберігати різні межі змісту.
За великого потоку варто відокремити швидкий пошук від дорогої оцінки моделлю. Автор зменшив витрати завдяки пакетному надсиланню запитів, кешуванню результатів для схожих профілів і вибору доступнішої моделі для типових ролей.
- Нормалізуйте текст до поділу: видаляйте HTML, уніфікуйте переноси рядків і перевіряйте обов’язкові поля.
- Вимірюйте якість знайдених фрагментів на реальних запитах, а не лише на зручних прикладах під час розробки.
- Зберігайте вектори разом з основними даними, якщо це спрощує транзакції та резервне копіювання; окремо перевірте налаштування індексу й час пошуку.
- Обмежуйте дорогі виклики LLM: об’єднуйте завдання в пакети, кешуйте результати та застосовуйте потужнішу модель лише там, де це виправдано.
- Додайте ідентифікатор проходження для кожного документа й записуйте кількість фрагментів, час побудови векторів, помилки та підсумкову оцінку.
Нагляд має з’явитися до зростання навантаження. У описаному випадку лише пов’язане журналювання показало, що деякі джерела створювали порожні фрагменти: процес не завершувався аварійно, але вакансії зникали з результатів пошуку.
Підсумок
Досвід автора показує, що надійний RAG передусім будується навколо даних та експлуатації. Вибір моделі чи векторного індексу важливий, але не компенсує неочищене введення, хибні межі фрагментів і відсутність вимірювань.
Практичний порядок роботи — спочатку зробити дані однорідними, потім перевірити якість пошуку, контролювати дорогі звернення до моделі й спостерігати за всім шляхом документа. Тоді масштабування не перетворить робочу демонстрацію на непрозоре джерело помилок і витрат.