Агент, который делает презентацию из текста
Нужно спроектировать продукт: пользователь дает текстовую задачу, система делает презентацию со слайдами, таблицами и картинками. Как построить pipeline?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Показать разбор
Короткий ответ
Разделить задачу на planning, structured slide spec, asset/table generation, render, validation и edit loop.
Подробный разбор
Нельзя сразу просить LLM "сделай pptx" и надеяться на качество. Лучше разбить pipeline. Сначала planner извлекает цель, аудиторию, структуру и ограничения. Затем LLM генерирует typed slide spec: title, bullets, charts, tables, image prompts, speaker notes. Этот spec валидируется схемой.
Дальше отдельные tools делают assets: таблицы из данных, charts, изображения, layout/render в PPTX/PDF. После render нужен checker: нет ли пустых слайдов, переполненного текста, битых картинок, несогласованных чисел. Пользователь должен иметь edit loop: поменять стиль, убрать слайд, перегенерировать chart.
В production важны версии шаблонов, reproducibility, хранение artifacts и ограничения по приватным данным.
Типичные ошибки
- Делать один giant prompt без structured spec.
- Не валидировать слайды до render.
- Не предусмотреть редактирование пользователем.
Как сказать на собеседовании
- Скажи typed intermediate representation.
- Раздели LLM planning и deterministic rendering.
Как версионировать артефакты LLM-агента
Агент генерирует презентации/таблицы/документы. Как хранить версии артефактов и поддерживать откат/редактирование?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Показать разбор
Короткий ответ
Хранить immutable versions: input, prompt/model/tool versions, structured spec, rendered artifact, diff и user edits.
Подробный разбор
У LLM-артефакта важно хранить не только финальный файл. Минимальный version record: user request, normalized structured spec, model/prompt/tool versions, generated assets, rendered output, validation status и user edits. Каждая новая генерация или ручная правка создает новую версию.
Откат становится простым: показываем список версий и восстанавливаем structured spec или rendered file. Diff лучше считать на уровне structured spec, а не бинарного PPTX. Для collaborative editing нужны ownership, timestamps и conflict handling.
Такой подход также помогает debugging: можно понять, какой prompt/model сломал качество и воспроизвести генерацию.
Типичные ошибки
- Хранить только последний PPTX.
- Не сохранять prompt/model version.
- Сравнивать только бинарные файлы вместо structured spec.
Как сказать на собеседовании
- Скажи immutable versions and reproducibility.
- Упомяни diff at structured representation level.
Когда нужен векторный поиск, а когда full-text
В продукте есть поиск по документам/артефактам. Когда использовать full-text, когда векторный поиск, и зачем может понадобиться hybrid retrieval?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Показать разбор
Короткий ответ
Full-text хорош для точных терминов и фильтров; vector search - для семантической близости; hybrid объединяет lexical precision и semantic recall.
Подробный разбор
Full-text поиск вроде BM25 хорошо работает, когда запрос содержит важные ключевые слова, имена, коды, названия полей. Он прозрачен, быстрый и удобно комбинируется с фильтрами.
Vector search нужен, когда пользователь формулирует смысл другими словами или ищет похожие документы без точного совпадения терминов. Но embeddings могут ошибаться на числах, редких именах и точных constraints.
Поэтому часто используют hybrid: retrieve кандидатов BM25 и vector search, затем merge/rerank. В RAG это повышает recall, а reranker или business rules помогают вернуть точный порядок.
Типичные ошибки
- Считать vector search полной заменой BM25.
- Не учитывать exact identifiers и фильтры.
- Не иметь eval по Recall@K/NDCG.
Как сказать на собеседовании
- Приведи пример: артикул ищем full-text, смысловой вопрос - vector.
- Назови hybrid retrieval and reranking.
Backend-контур для LLM-продукта
Какие backend-компоненты нужны для LLM-продукта с tools, cache и долгими задачами?
Сначала проговорите ответ вслух или тезисами.
Формулы, план решения, риски и примеры.
Откройте разбор только после своей попытки.
Показать разбор
Короткий ответ
Нужны API/orchestrator, job queue, tool execution layer, cache, artifact storage, streaming updates, auth и observability.
Подробный разбор
LLM-задачи часто долгие и stateful, поэтому backend должен быть не только HTTP wrapper над model API. Обычно есть API gateway, orchestrator, очередь задач, workers для tool execution, storage для intermediate artifacts и канал обновлений статуса через streaming/websocket/polling.
Cache нужен на нескольких уровнях: retrieval results, expensive tool outputs, rendered artifacts, иногда model responses для deterministic prompts. Но cache должен учитывать user permissions, version prompts/models и invalidation.
Для production важны timeouts, idempotency, retries, cancellation, rate limits, tracing, cost accounting и audit log. Если агент вызывает внешние системы, tool layer должен валидировать аргументы и права доступа.
Типичные ошибки
- Делать все синхронным request-response.
- Кешировать ответы без учета прав пользователя.
- Не предусмотреть cancel/retry/idempotency.
Как сказать на собеседовании
- Скажи queue + workers for long tasks.
- Упомяни streaming status and artifact storage.