AI / LLM
Сборка LLM-приложений: тест на воспроизведение
Воспроизведение бьёт перечитывание. На каждый промпт восстанови полный ответ по памяти — поперёк всего трека, а не одного слоя — прежде чем открыть модельный. Усилие воспоминания и закрепляет рассуждение на уровне швов.
Восстанови хребет трека: как caching, RAG, streaming, tool calls, agent loop и evals собираются вместе — и где каждая пара корректных слоёв ломается на шве.
- 01Почему у RAG-ассистента с длинным статическим system-промптом cache hit rate в проде может быть почти нулевым и как это починить?
- 02Почему стримящийся ход — это конечный автомат, а не труба токенов, и что будет, если это игнорировать?
- 03Почему token-бюджетные алерты — не то же, что enforcement бюджета для агента, и как выглядит enforcement?
- 04Почему зелёный офлайн eval-набор всё равно пропускает регрессию retrieval и как закрыть пробел?
- 05Сформулируй тезис «баг живёт в шве» и как он меняет дебаг собранного LLM-приложения.
- 06Пройди порядок, в котором ты дебажил бы собранный ассистент, у которого после выката утроилась стоимость и ответы кажутся медленнее.
Если смог восстановить каждый ответ по памяти, ты держишь хребет трека: caching — это байт-в-байт prefix match, поэтому динамический RAG-контекст — за брейкпойнтом; стрим — конечный автомат, где tool_use это переход, а каждый id должен быть спарен; agent loop’ам нужны enforced step/dollar-капы, а не алерты; evals обязаны гонять живой retrieval-путь, иначе регрессии retrieval уезжают зелёными. И мета-урок над всем: баг живёт в шве — трассируй один реальный запрос насквозь и моделируй весь поток.