1. Промпт-инжиниринг: как разговаривать с LLM
Промпт (prompt) — это текст, который вы отправляете модели. Это может быть вопрос, инструкция, фрагмент кода или описание задачи. Качество ответа модели напрямую зависит от качества промпта.
Промпт-инжиниринг — это не просто «красиво написать». Это методология. Хороший промпт содержит: контекст, роль, задачу, формат ответа и ограничения.
Промпт-инжиниринг (Prompt Engineering)
Практика проектирования входных текстов (промптов) для LLM таким образом, чтобы получать максимально точные, полезные и предсказуемые результаты.
Структура хорошего промпта
| Элемент | Назначение | Пример |
| Роль |
Кто модель в этом разговоре |
«Ты — опытный финансовый консультант» |
| Контекст |
Что модель должна знать |
«Клиент — молодая семья с доходом 150 000 рублей в месяц» |
| Задача |
Что конкретно нужно сделать |
«Составь бюджет на месяц с учётом ипотеки и одного ребёнка» |
| Формат |
Как оформить ответ |
«Ответ оформи в виде таблицы с колонками: категория, сумма, процент от дохода» |
| Ограничения |
Чего делать нельзя |
«Не используй профессиональный жаргон. Не предлагай инвестиции с высоким риском.» |
Основные техники
Zero-shot. Прямой запрос без примеров: «Переведи этот текст на английский». Подходит, когда модель уже хорошо знает формат задачи из предобучения — современные LLM справляются в zero-shot даже со сложными задачами вроде написания кода или анализа текста.
Few-shot. Вы даёте 2-3 примера того, какой ответ ожидаете. Модель копирует стиль и формат. Особенно полезно для форматирования и редких форматов.
Chain-of-Thought (CoT). Вы просите модель «рассуждать по шагам». Например:
- Без CoT: «Сколько будет 15% от 340?» — модель сразу пишет ответ (и может ошибиться).
- С CoT: «Реши задачу: сколько будет 15% от 340. Объясни каждый шаг.» — модель расписывает: 10% от 340 = 34, 5% от 340 = 17, сумма = 51.
Это резко улучшает точность на логических и математических задачах по сравнению с прямым ответом.
Правило: Потратьте 5 минут на хороший промпт — сэкономьте 30 минут на исправлении плохого ответа.
2. Эмбеддинги: как машина «понимает» смысл текста
Компьютеры не понимают слов. Они понимают числа. Эмбеддинг (embedding) — это способ превратить текст в список чисел так, чтобы похожие по смыслу тексты получали близкие числа.
Эмбеддинг (Embedding)
Векторное представление текста — массив из N чисел (обычно от 384 до 3072, иногда больше), который кодирует семантическое значение фрагмента текста. Тексты, близкие по смыслу, имеют близкие эмбеддинги в векторном пространстве.
Как это работает на практике
Представьте, что у каждого слова или предложения есть координаты в многомерном пространстве. «Кошка» и «котёнок» находятся рядом. «Кошка» и «автомобиль» — далеко друг от друга. Это и есть эмбеддинг: числовой «отпечаток» смысла. Важно: эмбеддинг зависит от контекста. Слово «ключ» в значении «от двери» и в значении «родник» будут иметь разные эмбеддинги, хотя слово одно и то же.
Сравнение эмбеддингов: косинусное сходство
Чтобы понять, насколько два текста похожи, вычисляют косинусное сходство (cosine similarity) — угол между их векторами. Значение 1 означает полную идентичность, 0 — никакой связи, -1 — полную противоположность. На практике с эмбеддингами значения редко опускаются ниже 0 — модели обучаются так, что даже несвязанные тексты обычно имеют небольшое положительное сходство.
Зачем нужны эмбеддинги
- Семантический поиск — найти документы не по точным словам, а по смыслу
- Построение RAG-систем — быстрое нахождение релевантных фрагментов
- Кластеризация — автоматическая группировка похожих документов
- Рекомендации — найти похожий контент
Конкретный пример: Вы ищете «как лечить простуду». Полнотекстовый поиск найдёт только документы с этими словами. Эмбеддинговый поиск найдёт документы со словами «ОРВИ лечение», «противовирусные препараты», «температура что делать» — потому что их векторы близки.
3. RAG: Retrieval-Augmented Generation
RAG расшифровывается как Retrieval-Augmented Generation. На русский — «генерация, дополненная поиском». Это техника, которая решает главную проблему LLM: модель знает только то, на чём её обучили, и не имеет доступа к вашим данным.
RAG (Retrieval-Augmented Generation)
Архитектурный подход, при котором LLM перед генерацией ответа сначала ищет релевантную информацию в предоставленной базе знаний, а затем отвечает, опираясь на найденные документы.
Проблемы LLM без RAG
- Галлюцинации. Модель может уверенно сообщить факт, которого не существует.
- Устаревшие знания. Модель знает только то, что было на момент обучения.
- Нет доступа к приватным данным. Модель не читала ваши внутренние документы.
- Ограничение контекстного окна. Нельзя просто скормить модели 1000-страничный документ.
Как RAG решает эти проблемы
Вместо того чтобы надеяться на память модели, RAG добавляет шаг поиска перед ответом:
- Пользователь задаёт вопрос
- Система превращает вопрос в эмбеддинг
- Ищет в базе знаний самые похожие по смыслу фрагменты
- Добавляет эти фрагменты в промпт вместе с вопросом
- Модель отвечает, опираясь на найденные документы
Метафора: Представьте, что у вас экзамен. LLM без RAG — это студент, который пришёл без конспектов и отвечает по памяти. LLM с RAG — это студент с открытой книгой: он может найти нужную страницу и ответить точно по тексту.
4. Архитектура RAG-системы шаг за шагом
Давайте разберём, из чего состоит реальная RAG-система.
Шаг 1: Индексация (разово или периодически)
- Сбор документов. Загружаете ваши документы — PDF, Markdown, HTML, записи из базы данных.
- Разбивка на чанки (chunking). Документы нарезаются на небольшие фрагменты — обычно от 200 до 1000 токенов с перекрытием. Это критически важный этап — от размера чанка зависит качество поиска:
Почему chunking так важен? Если чанки слишком маленькие (100 токенов) — теряется контекст, модель получает обрывки мыслей. Если слишком большие (3000 токенов) — в один чанк попадает много разной информации, и поиск становится нечётким: «вроде похоже, а вроде и нет». Идеальный размер зависит от типа документов:
• Техническая документация, FAQ: 200-500 токенов — короткие, конкретные фрагменты.
• Статьи, отчёты: 500-1000 токенов — чтобы сохранить абзац с контекстом.
• Перекрытие (overlap): 10-20% от размера чанка. Например, чанк в 500 токенов с перекрытием 50 токенов. Это нужно, чтобы мысль не обрывалась на границе чанков — следующий чанк начинается с тех же 50 токенов, на которых закончился предыдущий.
- Векторизация. Каждый чанк превращается в эмбеддинг через embedding-модель.
- Сохранение в векторную базу. Эмбеддинги сохраняются в специальную базу данных (векторное хранилище), которая умеет быстро искать ближайшие векторы.
Шаг 2: Поиск и генерация (на каждый запрос)
- Векторизация запроса. Вопрос пользователя превращается в эмбеддинг той же моделью.
- Поиск ближайших чанков. Векторная база возвращает top-K самых похожих фрагментов (обычно 3-10).
- Сборка промпта. Найденные чанки добавляются в промпт: «Ответь на вопрос, используя ТОЛЬКО следующие документы: [чанк 1] [чанк 2] ... Вопрос: [вопрос]»
- Генерация ответа. LLM получает промпт с документами и генерирует ответ.
Популярные векторные базы данных
| Решение | Когда использовать | Особенности |
| ChromaDB | Прототипы, маленькие проекты | Локальная, простая, Python-first |
| Pinecone | Продакшен, когда нужен managed-сервис | Облачная, масштабируется автоматически |
| Qdrant | Высокая производительность | Написана на Rust, self-hosted или облако |
| Weaviate | Гибридный поиск | Умеет искать и по векторам, и по ключевым словам одновременно |
| pgvector | Когда уже есть PostgreSQL | Расширение для PostgreSQL, не нужно разворачивать отдельную БД |
5. Best practices: когда что использовать
Когда достаточно одного LLM (без RAG)
- Творческие задачи: написать текст, придумать идею, перефразировать
- Ответы на общие вопросы (известные факты, определения)
- Задачи, где нет риска от галлюцинаций (генерация идей, черновики)
- Короткие диалоги в пределах контекстного окна
Когда нужен RAG
- Ответы на вопросы по вашим внутренним документам
- Чат-бот поддержки, который должен отвечать строго по инструкциям
- Поиск по большой базе знаний
- Ситуации, где фактическая точность критична
Продуктовые комбинации
| Сценарий | Инструментарий |
| Чат-бот техподдержки | LLM + RAG (ChromaDB/Pinecone + документы FAQ) |
| Поиск по документам компании | RAG + векторная БД + reranking (повторная сортировка результатов поиска для повышения точности) |
| Редактор с AI-ассистентом | LLM с тщательно проработанным промптом (без RAG) |
| Анализ контрактов | RAG + OCR (распознавание текста из сканов/PDF) + специализированная LLM |
Частая ошибка новичков: Пытаться решить всё одним RAG. Начните с простого: сначала попробуйте решить задачу одним промптом. Если не хватает — добавьте RAG. Если и этого мало — смотрите в сторону fine-tuning (об этом в Модуле 4).
6. Итоги модуля 2
- Промпт-инжиниринг — это не магия, а структурированный подход к общению с моделью
- Хороший промпт содержит: роль, контекст, задачу, формат и ограничения
- Эмбеддинги превращают текст в числа, сохраняя смысловую близость
- RAG позволяет LLM работать с вашими документами, а не только со своей памятью
- RAG — это поиск + генерация: сначала найти, потом ответить
- Начинайте с простого и усложняйте только когда это действительно нужно
Что дальше? В следующем модуле разберём инструменты, функции и MCP — механизмы, которые позволяют LLM взаимодействовать с внешним миром: вызывать API, работать с файлами, отправлять письма и многое другое.