SimpleMultiModalQueryEngine 지원 중단. 이렇게 바꾸세요.

LlamaIndex가 2026년 6월 24일 llama-index-core v0.14.23을 배포했습니다. 이번 포인트 릴리스는 조용히 쿼리 엔진 하나를 은퇴시키고, 장시간 실행되는 서비스를 괴롭혀 온 상태 오염 버그를 닫았습니다. 다음 배포에 올릴 만한지 살펴보겠습니다.

LlamaIndex 0.14.23, 건너뛸까 배포할까?

배포하세요. 업그레이드 위험은 낮습니다. LlamaIndex 0.14.23은 0.14.x 라인의 점진적인 포인트 릴리스이며, core에서 발표된 breaking change가 없습니다. 따라서 pip install --upgrade llama-index는 마이그레이션이라기보다 작고 추가적인 업데이트에 가깝습니다 . core changelog에는 새 멀티모달 기능과 버그 수정이 섞인 17개 항목이 올라와 있으며, 설계 의도를 따로 설명하는 별도 릴리스 노트는 없습니다. CHANGELOG와 릴리스 커밋이 주요 기록입니다 .

Quick Answer: LlamaIndex 0.14.23(2026년 6월 24일)은 core API breaking change가 없는 저위험 포인트 릴리스입니다. 업그레이드하세요. 일급 멀티모달 RAG와 요청 간 workflow 상태 누수를 막는 수정이 들어 있습니다. 바로 조치할 한 가지는 SimpleMultiModalQueryEngine이 이제 deprecated 상태라는 점입니다.

배포 전에 두 가지를 확인해야 합니다. 첫째, 조치해야 할 deprecation은 정확히 하나입니다. SimpleMultiModalQueryEngine은 이제 오류가 아니라 deprecation warning을 내며 표준 엔진으로 이동하라고 안내하고, 0.15.x 라인에서 제거될 예정입니다 . 기존 코드는 0.14.23에서도 계속 실행되므로 원하는 일정에 맞춰 마이그레이션할 수 있지만, 시계는 이미 움직이기 시작했다고 보는 편이 좋습니다.

둘째, 놓치기 쉽지만 중요합니다. PR #21780은 workflow의 initial_state를 deep copy하도록 바꿔, 상태 변경이 더 이상 별도 실행 사이로 새지 않게 했습니다 . 하나의 Workflow 인스턴스를 여러 요청에서 재사용하는 장시간 실행 서비스라면, 이 수정은 요청 간 상태 누수를 조용히 해결합니다. 동시성 상황에서 간헐적으로 재현하기 어려운 오답으로 드러나는 바로 그 유형의 버그입니다. 이 수정만으로도 프로덕션 workflow 서비스에서는 버전을 올릴 이유가 충분합니다.

버전 구조는 특별할 것이 없고, 바로 그 점이 중요합니다. 우산 패키지인 llama-index는 0.14.22에서 0.14.23으로 이동했고, core pin은 llama-index-core>=0.14.22,<0.15.0에서 >=0.14.23,<0.15.0으로 바뀌었습니다 . core는 여전히 MIT 라이선스 아래 Python >=3.10,<4.0을 선언하므로, 런타임 제약은 달라지지 않습니다 . 아래 섹션에서는 무엇을 교체해야 하는지, 무엇이 흡수됐는지, 무엇이 고쳐졌는지 차례로 살펴봅니다.

SimpleMultiModalQueryEngine 폐기: 대체 호출 방식

SimpleMultiModalQueryEngine은 llama-index-core 0.14.23부터 deprecated 처리되었고, deprecation 메시지에는 대체 방식도 함께 명시되어 있습니다. 이제 멀티모달 쿼리는 RetrieverQueryEngine.from_args(retriever=..., llm=..., multimodal=True)로 라우팅하면 됩니다 . 대부분의 호출부에서는 3~4줄만 바꾸면 됩니다. 눈에 잘 띄지 않는 작업은 템플릿 마이그레이션이며, 이 부분은 synthesizer 쪽으로 이동했습니다.

빠른 답변: llama-index-core 0.14.23에서는 SimpleMultiModalQueryEngine을 RetrieverQueryEngine.from_args(retriever=..., llm=..., multimodal=True)로 교체하세요. 멀티모달 모델은 multi_modal_llm=이 아니라 llm=으로 넘기고, 분리되어 있던 텍스트/이미지 QA 템플릿은 synthesizer의 chat-content 템플릿으로 변환해야 합니다.

호출 방식에서는 세 가지가 바뀌었습니다. 첫째, multi_modal_llm=은 더 이상 사용하지 않습니다. 이제 멀티모달 모델은 다른 모든 query engine이 이미 쓰는 표준 llm= 인자로 넘깁니다. 둘째, 별도의 text_qa_template= 및 refine_template= 인자는 chat_content_qa_template와 chat_content_refine_template로 바뀌며, 이들은 일반 텍스트 문자열이 아니라 풍부한 chat-content 블록을 담습니다 . 셋째, 이제 이 템플릿 파라미터들은 response synthesizer에 있습니다. RetrieverQueryEngine.from_args(...)는 chat_content_qa_template, chat_content_refine_template, multimodal: bool = False를 노출하고, 내부의 Refine synthesizer도 이에 맞는 초기화 경로를 갖게 되었습니다 .

두 번째 선택지도 있습니다. SimpleMultiModalQueryEngine이 깔끔하게 제공하지 못했던 citation 동작에 의존하고 있었다면, 대신 CitationQueryEngine.from_args(..., multimodal=True)를 사용하세요. 같은 호출 규칙으로 텍스트, 문서, 이미지가 섞인 콘텐츠에 대해 citation-aware retrieval을 제공합니다 . 단순한 synthesis 교체라면 RetrieverQueryEngine을, 답변에 출처 표기가 필요하다면 CitationQueryEngine을 고르면 됩니다.

이전 방식과 새 방식 비교

# 이전 방식(0.14.23에서 deprecated)
from llama_index.core.query_engine import SimpleMultiModalQueryEngine

engine = SimpleMultiModalQueryEngine(
    retriever=retriever,
    multi_modal_llm=mm_llm,
    text_qa_template=text_qa_tmpl,
    image_qa_template=image_qa_tmpl,
)

# 이후 방식(0.14.23)
from llama_index.core.query_engine import RetrieverQueryEngine

engine = RetrieverQueryEngine.from_args(
    retriever=retriever,
    llm=mm_llm,                 # 기존 multi_modal_llm=
    multimodal=True,
    chat_content_qa_template=chat_qa_tmpl,      # text/image QA 템플릿 대체
    chat_content_refine_template=chat_refine_tmpl,
)

engine import와 multimodal=True 플래그는 기계적으로 바꾸면 되는 부분입니다. 실제로 문제를 일으키는 마이그레이션은 템플릿입니다. 이제 텍스트 템플릿과 별도의 이미지 템플릿을 따로 설정하지 않습니다. 둘을 하나의 chat-content 템플릿으로 합치면, synthesizer가 검색된 node에서 가져온 멀티모달 블록을 그대로 넣어 사용합니다 . 기존 코드가 서로 다른 prompt 문자열 두 개를 만들고 있었다면, 교체 코드가 깔끔하게 컴파일되기 전에 이를 하나의 chat-content 구조로 다시 작성해야 합니다.

이 deprecation이 0.14.x에서 바로 코드를 깨뜨리지는 않습니다. 기존 engine은 경고를 내면서 계속 실행됩니다. 하지만 메시지가 이동할 대상을 명확히 알려주므로, 지원되는 경로를 추측할 필요는 없습니다 . deprecated engine이 제거 후보가 되기 쉬운 0.15 라인을 기다리지 말고 지금 마이그레이션하는 편이 낫습니다.

RetrieverQueryEngine가 리치 미디어 RAG를 흡수하다

이 목적지가 생긴 이유는 LlamaIndex 멀티모달 작업의 두 번째 installment에 있다. 이 작업은 0.14.23에 들어오면서 리치 미디어 검색을 표준 쿼리 스택 안으로 완전히 접어 넣었다. 실제 변경은 두 개의 풀 리퀘스트가 맡았다. feat(core): Multimodal synthesis part 2(PR #21561)와 Multimodal query engines(PR #21784)이며, 둘 다 2026-06-24에 core v0.14.23으로 배포됐다 . 이는 v0.14.22의 첫 "Multimodal synthesis" 변경에서 시작된 통합을 마무리한다. 실질적인 결과는 명확하다. 이제 retriever와 response synthesizer가 텍스트와 함께 이미지, 스캔 페이지, 비디오를 처리하므로, 멀티모달 RAG가 별도의 코드 경로로 남지 않는다.

동작 방식은 이렇다. RetrieverQueryEngine.from_args(retriever=..., llm=..., multimodal=True)를 호출하면, synthesizer는 검색된 노드에서 멀티모달 콘텐츠 블록을 직접 받아들이도록 설정된다 . 인터페이스 변화는 이 플래그 하나가 전부다. multimodal=False(기본값)에서는 익숙한 텍스트 동작을 얻고, 이를 True로 바꾸면 노드에 붙은 이미지나 비디오 블록이 버려지거나 캡션으로 미리 평탄화되지 않고 모델로 전달된다. 더 이상 별도의 이미지 인덱스를 유지할 필요도 없고, 검색된 그림을 synthesis 전에 문자열로 바꾸기 위한 텍스트 추출 glue 코드를 작성할 필요도 없다.

Refine response synthesizer도 그에 맞게 바뀐다. chat_content_qa_template와 chat_content_refine_template 초기화 경로가 추가되고, 자체 multimodal 플래그도 생긴다 . 이는 여러 검색 청크를 하나의 프롬프트에 모두 밀어 넣는 대신, 답변을 단계적으로 refine하는 파이프라인에서 특히 중요하다. 컨텍스트 창이 빠듯하거나 점진적인 grounding을 원할 때 흔히 쓰는 형태다. 새 템플릿을 쓰면 각 refinement 단계가 모든 청크를 먼저 일반 텍스트로 강제 변환하지 않고도 혼합 콘텐츠(여기에는 문단, 저기에는 차트)를 담을 수 있다.

범위도 구체적이다. PDF, 스캔 문서, 비디오 콘텐츠가 이제 일반 텍스트 청크와 같은 retriever-to-synthesizer 체인을 따라 흐른다 . 스캔한 계약서 디렉터리를 ingest하는 파이프라인이든, 프레임 참조가 붙은 비디오 transcript를 인덱싱하는 파이프라인이든, 이미 알고 있는 일반 엔진을 사용하면 된다. 달라지는 것은 multimodal=True 스위치뿐이다.

솔직히 말하면, 이는 새로운 primitive라기보다 기존 두 경로의 수렴이다. 동작은 예전 SimpleMultiModalQueryEngine이 하던 것과 대체로 같다. 여전히 이미지에 대해 검색하고 합성된 답변을 받을 수 있다. 달라진 것은 표면적이다. 일반 엔진과 특수한 멀티모달 sibling을 따로 두는 대신, 배워야 할 엔진 타입이 하나이고, 설정할 synthesizer 계열이 하나이며, maintainers가 올바르게 유지해야 할 코드 경로도 하나다. LlamaIndex는 이 통합을 좁은 RAG 정체성을 넘어 통합된 검색 및 synthesis core로 이동하는 흐름의 일부로 설명한다. 자체 글에서도 "LlamaIndex is more than a RAG framework"라고 주장하며, 혼합 미디어 검색은 옆문이 아니라 표준 스택 안에 있어야 한다고 말한다 — LlamaIndex team, LlamaIndex blog.

업그레이드를 검토하는 개발자에게 가치는 이전에는 도달할 수 없던 기능이 아니다. 더 작고 오래 버틸 API다. multimodal=True와 함께 RetrieverQueryEngine을 기준으로 작성한 코드는 프로젝트가 계속 지원하려는 경로 위에 놓인다. 앞선 섹션에서 0.15까지 기다리지 말고 지금 마이그레이션하라고 한 이유도 같다 .

0.14.23이 에이전트형 파이프라인에서 고친 문제

에이전트형 파이프라인 관점에서 0.14.23은 새로운 추상화를 추가한 버전이 아니라 정확성을 바로잡은 릴리스입니다. 중요한 네 가지 변경은 모두 멀티모달 콘텐츠나 공유 상태가 도구, 메모리, 재사용되는 워크플로 인스턴스를 거치는 동안 조용히 손상될 수 있던 지점을 고칩니다. 여기에는 새로운 최상위 에이전트 프리미티브가 없습니다. FunctionAgent, 함수 도구, AgentWorkflow(agents=[...]) 오케스트레이션은 기존 위치에 그대로 남아 있습니다 . 달라진 점은 기존 프리미티브가 더 이상 데이터를 떨어뜨리지 않는다는 것입니다.

프로덕션 서비스에 가장 큰 의미가 있는 수정은 PR #21780의 워크플로 initial_state 딥카피입니다. 이전에는 하나의 AgentWorkflow 인스턴스를 여러 요청에 재사용하면 N번째 실행에서 생긴 상태 변경이 N+1번째 실행으로 새어 들어갈 수 있었습니다. 이는 동시성 상황이나 긴 가동 시간처럼 디버깅이 가장 어려운 환경에서야 드러나는 조용한 요청 간 데이터 오염입니다. 이번 릴리스에서는 initial_state를 딥카피해 각 실행이 깨끗한 상태에서 시작하도록 했습니다 . 부팅 시 워크플로를 한 번 생성한 뒤 여러 요청을 처리하는 긴 수명의 서비스, 즉 일반적인 패턴으로 운영하고 있다면 변경 로그에서 꼭 읽어야 할 부분입니다.

나머지 세 가지는 에이전트 루프 전반에서 멀티모달 컨텍스트가 살아남도록 하는 수정입니다.

• 도구 경계(PR #21678): 이제 FunctionTool._parse_tool_output이 DocumentBlock과 VideoBlock을 처리합니다. 이전에는 도구가 반환한 리치 콘텐츠가 도구와 에이전트의 경계에서 텍스트로 납작하게 변환됐지만, 이제 문서와 비디오 블록이 그대로 전달됩니다 .
• 메모리(PR #21728): URL 기반 비디오와 문서 블록이 이제 턴을 넘어 보존됩니다. 검색 단계에서는 살아남았던 멀티모달 컨텍스트가 예전에는 메모리에서 버려졌지만, 이제는 지속되므로 후속 질문에서도 에이전트가 이전 답변의 근거로 삼았던 이미지나 PDF를 계속 볼 수 있습니다 .
• 테스트(PR #21732): 도구 호출을 지원하는 모의 LLM이 추가되어, 실제 모델 호출 없이도 에이전트형 도구 루프를 결정적으로 테스트할 수 있게 됐습니다 .

함께 보면 앞의 두 수정은 하나의 루프를 닫습니다. 리치 미디어 RAG가 이제 도구를 통과하고 메모리를 넘나드는 동안 어느 지점에서도 손실이 있는 텍스트 변환을 거치지 않고 콘텐츠를 전달할 수 있으며, 이는 에이전트 계층이 이미 기대하는 멀티모달 ChatMessage 블록과도 맞아떨어집니다 . 모의 LLM은 더 조용한 성과입니다. 에이전트 테스트 스위트는 오랫동안 HTTP 계층에서 모킹하거나 CI에서 실제 호출 비용을 지불하는 선택지 사이에 놓여 있었습니다. 일급 도구 호출 모의 객체가 있으면 에이전트가 어떤 도구를 선택했고 결과를 어떻게 파싱했는지 결정적으로 검증할 수 있습니다. LlamaIndex 에이전트 위에 무언가를 구축하고 있다면 이를 중심으로 테스트를 재구성할 가치가 있습니다.

이 변경들은 모두 헤드라인을 장식할 기능은 아니며, 생성된 변경 로그도 우선순위를 매기지 않습니다. 하지만 노트북이 아니라 프로덕션에서 에이전트를 운영하는 사람에게는 initial_state 수정 하나만으로도 이 버전 업그레이드를 앞당길 이유가 충분합니다.

수집 중복 제거와 NE/NIN 연산자: 조용하지만 영향은 큽니다

멀티모달이라는 큰 제목 아래에서, 0.14.23은 호출하는 API는 그대로 두면서 정확성과 처리량을 바꾸는 수집 및 검색 수정 사항들을 함께 담고 있습니다. 수집 파이프라인의 배치 내부 중복 제거는 이제 리스트 대신 세트를 사용합니다(PR #21755) . 이로써 멤버십 검사가 O(n²) 리스트 스캔에서 O(n) 세트 조회로 바뀝니다. 문서 몇 개 수준에서는 체감하기 어렵지만, 노드가 수만 개에 이르는 배치에서는 빠르게 끝나는 실행과 멈춘 듯한 실행을 가르는 차이가 됩니다.

Quick Answer: LlamaIndex 0.14.23(2026-06-24)은 리스트 기반 수집 중복 제거를 O(n) 조회가 가능한 세트로 교체하고(PR #21755), 비동기 서버 안에서 발생하던 pipeline.arun() RuntimeError를 수정하며(PR #21765), NE/NIN 메타데이터 필터와 TreeSelectLeafRetriever의 출처 attribution을 바로잡습니다. 모두 조용하지만 정확성에 중요한 개선이므로, 업그레이드 후에는 기존에 알고 있던 쿼리를 다시 실행해 확인할 필요가 있습니다.

비동기 수정은 이미 겪었을 가능성이 가장 큰 항목입니다. 이제 비동기 수집은 실행 중인 이벤트 루프를 감지합니다(PR #21765) . 따라서 이미 루프를 소유한 FastAPI 핸들러나 다른 async-native 서버 안에서 pipeline.arun()을 호출할 때 발생하던 RuntimeError 계열 문제가 해결됩니다. 이전에 이 오류를 피하려고 수집을 별도 스레드로 감쌌다면, 이제 그 우회 코드는 제거해도 됩니다.

검색 정확성과 관련된 두 가지 수정은 훑어보는 데서 그치지 말고 검증해 볼 만합니다. 이제 NE와 NIN 메타데이터 필터 연산자는 메타데이터가 누락된 경우에도 올바른 매치를 반환합니다(PR #21785) . 벡터 검색에서 필드 부등식으로 문서를 제외하고 있다면, 업그레이드 전후로 잘 아는 쿼리를 실행해 recall을 비교하세요. 결과가 실제로 달라질 수 있습니다. 별도로, TreeSelectLeafRetriever는 이제 source node를 보존합니다(PR #21787) . 계층형 검색에서 출처 attribution이 조용히 빠져 있었기 때문에, 트리 검색 위에 만든 cite-source나 grounding 기능은 추적 가능한 출처 없이 답변을 반환하고 있었습니다.

마지막 행은 날카로운 예외 상황 하나를 닫습니다. 이전에는 단일 유닛이 chunk_size를 초과하면 TokenTextSplitter와 SentenceSplitter가 RecursionError에 걸렸습니다(PR #21900) . 여기에 빈 입력에서 PromptHelper가 ZeroDivisionError를 내지 않도록 하는 보호 장치도 함께 들어갔습니다. 생성된 changelog의 평면적인 목록에서는 어느 것도 크게 드러나지 않지만, 각각은 그렇지 않았다면 프로덕션에서 직접 디버깅했을 실패 모드와 연결됩니다.

실무 체크리스트: 영향받는 경우와 조정할 것

0.14.23이 조용한 포인트 릴리스인지, 아니면 급히 올려야 할 업그레이드인지는 코드가 아래 다섯 가지 패턴 중 어디에 해당하는지에 달려 있습니다. LlamaIndex는 2026-06-24에 llama-index-core 0.14.23을 배포했지만 , 그 영향은 겉으로 드러나지 않습니다. 목록을 훑어보고, 여러분의 스택을 설명하는 항목을 찾아 변경이 프로덕션 장애로 커지기 전에 조치하세요.

• SimpleMultiModalQueryEngine을 사용한다면: 제거되는 날까지 기다리지 말고 지금 마이그레이션하세요. 이 엔진은 0.14.23에서 deprecated 처리되었고, 안내 메시지는 RetrieverQueryEngine.from_args(retriever=..., llm=..., multimodal=True) 또는 CitationQueryEngine.from_args(..., multimodal=True)로 이동하라고 안내합니다 . 교체는 세네 줄이면 됩니다. 멀티모달 모델을 multi_modal_llm= 대신 llm=으로 넘기고, 분리된 텍스트/이미지 QA 템플릿을 채팅 콘텐츠 템플릿으로 바꾸면 됩니다. 미루면 오늘 차분히 끝낼 수 있는 수정을 0.15.x 라인에서 심볼이 사라질 때 허겁지겁 처리하게 될 뿐입니다.
• 요청 간에 하나의 AgentWorkflow를 재사용하는 장기 실행 서비스를 운영한다면: initial_state 딥카피 수정(PR #21780)을 위해 업그레이드하세요. 이 수정은 한 실행에서 발생한 상태 변경이 다음 실행으로 새어 나가는 문제를 막습니다 . 이는 크래시가 아니라 요청별로 조용히 데이터가 오염되는 문제였습니다. 공유 워크플로 인스턴스 하나에 대해 두 번 실행하고, 두 번째 실행이 깨끗한 상태를 보는지 검증하는 테스트를 추가하세요.
• NE 또는 NIN으로 메타데이터 필터링 벡터 검색을 한다면: 해당 연산자에서 메타데이터가 없는 경우의 동작이 수정되었습니다(PR #21785) . 업그레이드 후 알고 있는 쿼리를 다시 실행해 recall을 확인하세요. 결과가 달라진다면 새 결과가 틀린 것이 아니라 이전 답이 틀렸던 것입니다. 다만 그 변화를 사용자에게서가 아니라 스테이징에서 먼저 봐야 합니다.
• 처리량이 큰 배치 ingestion을 운영한다면: 세트 기반 배치 내 중복 제거(PR #21755)와 실행 중인 이벤트 루프 감지(PR #21765)는 성능과 async 정확성을 공짜로 개선해 줍니다 . 버전만 올리면 되고 별도 코드 변경은 필요 없습니다.
• Converse를 통해 Bedrock을 호출한다면: llama-index-llms-bedrock-converse 0.14.14가 스트리밍된 tool_kwargs를 문자열에서 dict로 파싱하는 문제를 고치고, 도구 결과의 rich content block을 직렬화합니다 . 이전에는 스트리밍 호출에서 잘못된 도구 스키마가 조용히 실패했습니다. Bedrock에서 에이전트가 도구 호출을 스트리밍한다면, 이것만으로도 업그레이드할 이유가 됩니다.

핵심은 좁고 구체적입니다. 0.14.23은 0.14.x 라인에서 breaking core changes가 없는 저위험 업데이트입니다 . 하지만 두 가지 수정, 즉 워크플로 상태 격리와 NE/NIN 필터 수정은 조용히 틀린 답을 만들던 버그를 고친 것입니다. 둘 중 하나라도 해당된다면 포인트 릴리스라서 무시해도 된다고 넘기지 말고, 업그레이드한 뒤 의도적으로 검증하세요.

마지막 업데이트: 2026-06-25. 2026-06-24 날짜의 llama-index-core 0.14.23 changelog와 release commit을 기준으로 작성했습니다.

자주 묻는 질문

LlamaIndex 0.14.23에서는 SimpleMultiModalQueryEngine을 무엇으로 대체하나요?

새 multimodal 플래그와 함께 표준 쿼리 엔진을 사용하면 됩니다. RetrieverQueryEngine.from_args(retriever=..., llm=..., multimodal=True) 또는 CitationQueryEngine.from_args(..., multimodal=True)입니다. 이 교체에는 인자 변경 두 가지가 함께 따라옵니다. 멀티모달 모델은 기존 multi_modal_llm= 대신 llm=으로 전달하고, 별도로 쓰던 텍스트/이미지 QA 및 refine 템플릿은 통합된 chat_content_qa_template와 chat_content_refine_template로 바꾸면 됩니다. 이는 0.14.23의 deprecation 메시지에 출력되는 정확한 마이그레이션 경로입니다. LlamaIndex.

0.14.23으로 업그레이드하면 기존 멀티모달 코드가 바로 깨지나요?

아닙니다. SimpleMultiModalQueryEngine은 제거된 것이 아니라 deprecated 상태입니다. 인스턴스를 만들면 예외가 아니라 경고가 발생하며, 클래스는 이전처럼 계속 실행됩니다. 즉시 중단되는 변경이 아니라 마이그레이션할 시간이 있는 셈입니다. 제거는 다음 minor 라인(0.15.x)에서 예상되므로, 업그레이드 후 갑자기 놀라기 전에 RetrieverQueryEngine이나 CitationQueryEngine으로 교체할 계획을 세우는 것이 좋습니다. 0.14.23 릴리스는 0.14.x 라인의 point release이며, 발표된 core breaking change는 없습니다(CHANGELOG.md).

initial_state 워크플로 버그는 정확히 무엇이었고, 영향 여부는 어떻게 확인하나요?

서비스가 시작 시 AgentWorkflow 하나를 인스턴스화한 뒤 그 인스턴스를 여러 요청에 재사용하는 경우, 한 실행에서 워크플로의 initial_state에 생긴 변경이 이후 실행으로 새어 나갈 수 있었습니다. PR #21780의 수정은 실행마다 initial_state를 deep copy해 각 요청이 깨끗한 상태에서 시작하도록 합니다(release notes). 확인해야 할 증상은 오래 살아 있는 stateful 서비스에서 사용자 A의 컨텍스트가 사용자 B의 응답에 나타나는 경우입니다. 요청마다 새 워크플로를 만든다면 노출되지 않았고, 인스턴스 하나를 공유한다면 업그레이드한 뒤 검증해야 합니다.

LlamaIndex 0.14.23에 새 LLM provider가 추가되었나요?

새 provider를 추가했다기보다 기존 integration을 확장한 릴리스입니다. llama-index-llms-bedrock-converse (0.14.14)는 스트리밍 tool_kwargs를 문자열에서 dict로 파싱하는 문제를 고치고 tool result의 rich content block 직렬화를 추가했으며, llama-index-llms-openai (0.7.9)는 vLLM reasoning field 지원을 추가했습니다(release notes). changelog의 model allowlist에는 Claude Opus 4.8과 Claude Fable 5도 나열되어 있지만, 이는 LlamaIndex config entry입니다. vendor가 별도로 발표한 일반 공개 소식은 아니므로 신뢰도는 낮게 보는 것이 맞습니다.

오늘 production requirements 파일에 llama-index-core 0.14.23을 pin해도 괜찮나요?

네, 표준적인 사전 production 테스트를 거친다는 전제에서는 괜찮습니다. llama-index-core는 MIT 라이선스로 배포되고, Python >=3.10,<4.0을 대상으로 하며, 발표된 core breaking change가 없는 점진적인 point release입니다(PyPI). umbrella llama-index 패키지는 core pin을 >=0.14.22,<0.15.0 to >=0.14.23,<0.15.0로 이동했습니다(CHANGELOG.md). 이 버전에는 NE/NIN filter operator와 workflow state isolation 관련 정확성 수정이 포함되어 있으므로, 배포 전 자체 regression pass는 실행하세요.