Как показывать ответ LlamaIndex по мере генерации через streaming

1. Убедитесь, что выбранная модель и её интеграция действительно поддерживают потоковую выдачу.
2. Постройте индекс на проверенном источнике и создайте query engine с streaming=True.
3. Вызовите query с вопросом и последовательно выводите части из response_gen.
4. Соберите полную строку и сравните её фактический смысл с исходным документом.
5. Добавьте в своё приложение обработку отключения клиента и прекращения работы по правилам выбранной интеграции.

Готовый шаблон Python

from llama_index.core import Document, VectorStoreIndex

index = VectorStoreIndex.from_documents([
    Document(text="Правило R7: возврат возможен 14 дней.")])
# Настройте LLM с подтверждённой поддержкой streaming и embedding-модель.
engine = index.as_query_engine(streaming=True, similarity_top_k=1)
response = engine.query("Каков срок возврата по R7?")
parts = []
for piece in response.response_gen:
    print(piece, end="", flush=True)
    parts.append(piece)
print("\nИтог:", "".join(parts))

Код ниже в статье предназначен для тестовых источников без персональных сведений. Вызовы SDK не выполнялись в данном окружении с реальной моделью; синтаксис Python проверен отдельно. Не переносите вывод демонстрационного эксперимента на любой корпус и любого провайдера без повторной проверки.

Пример входа и ожидаемого результата

Вход: документ R7 с фразой «14 дней» и вопрос о сроке. Ожидается появление частей текста до завершения всей генерации и полный ответ со сроком 14 дней после объединения. Момент появления первого фрагмента и точная формулировка зависят от модели и сети; streaming не гарантирует меньшего общего времени.

Сохраните входные файлы, идентификаторы документов и ожидаемое утверждение в отдельном проверочном наборе. При неуспехе выделяйте слой ошибки: чтение источника, преобразование в nodes, получение embedding, поиск, синтез ответа или UI. Правильная форма ответа ещё не гарантирует правильного происхождения сведений.

Диагностика и границы решения

Потоковая выдача улучшает ощущение отклика, но не исправляет ошибку извлечения. Если релевантный документ отсутствует в top_k, быстрые токены просто быстрее покажут неправильный ответ. Клиент может закрыть вкладку до получения конца; приложение должно отличать частичный вывод от законченного и не сохранять его как финальный подтверждённый факт. Держите состояние запроса отдельно от UI-анимации: ошибка после первых токенов всё ещё означает неуспешное выполнение. Для источников и цитат осторожнее: список source_nodes и итоговую проверку надо отображать только по завершении соответствующего этапа, не придумывая ссылки в середине текста. Документация говорит, что при многошаговом query engine стримится лишь последний вызов LLM, поэтому не обещайте токены немедленно после нажатия кнопки. Если интеграция не поддерживает поток, ловите NotImplementedError и выбирайте честный непотоковый режим, а не имитацию по символам.

Дополнительный проверочный сценарий

Протестируйте три сценария: обычное завершение, разрыв соединения после первых слов и исключение до старта LLM. В первом результат полностью собирается и сверяется с R7; во втором пользователь видит маркировку «ответ прерван», а аналитика не учитывает его как успешный; в третьем выводится понятная ошибка подключения. Если query возвращает несколько независимых ответов модели, измерьте время до первого видимого токена и время полного ответа отдельно. Не используйте частично показанную фразу как основание автоматической отправки письма или записи в CRM: действия выполняют только после проверки полного результата. Храните только допустимые пользователю источники в trace и логах.

Критерии проверки