왜 중요한가
규제 문서에 근거한 실행 가능한 테스트 시나리오를 대규모로 자동 생성하는 문제는 자율주행 시스템 검증에서 비용과 시간의 병목이 된다. Chat2Scenic은 검색 기반 지식과 코드 예시를 LLM 프롬프트에 반복적으로 주입해 DSL 컴포넌트의 문법적·의미적 호환성을 확보함으로써 시뮬레이터에서 실행 가능한 스크립트 생산을 개선했다. 이 접근은 규제 준수 검증을 자동화해 오프라인 시나리오 생성의 신뢰성과 재현성을 높이는 실무적 의미를 가진다.
핵심 기여
반복적 컴포넌트 생성과 RAG 통합 프레임워크
Chat2Scenic은 사용자 질의에서 논리 구조를 추출한 뒤 공간관계, 에고 동작, 객체, 제약 조건을 의존 순서대로 반복 생성해 최종 Scenic 스크립트를 조립한다. 이 파이프라인은 코드 스니펫 데이터베이스와 규정 문서 데이터베이스를 병렬로 검색하는 듀얼 리트리버를 사용해 도메인 지식과 코드 패턴을 동시에 주입한다. 그 결과 컴포넌트 간 상호호환성 문제를 줄여 컴파일 성공률을 크게 향상시켰다.
동적 CodeICL과 문서 병렬 검색을 통한 프롬프트 설계
프롬프트 설계에서는 Contextual Prompting, Chain-of-Thought, In-Context Learning과 동적 검색 기반 CodeICL/DocICL을 조합했다. 특히 코드 예시(CodeICL)를 프롬프트에 동적으로 삽입하면 모델이 문법적 패턴에 더 빠르게 수렴해 응답 시간과 오류율이 개선되는 효과가 관찰되었다. 반면 문서 기반 DocICL은 토큰과 시간 비용이 커지는 단점이 있어 실험에서 한계가 확인되었다.
규제 기반 벤치마크와 공개 리포지토리
규제 문서를 포함한 123개 시나리오로 구성된 규제 기반 벤치마크를 수집·정의하고, 컴파일 성공률(CSR), 시나리오 품질(SQ), 프레임워크 정확도(FA)를 포함한 평가 지표를 제안했다. 이를 통해 기존 Retrieval Assemble 및 Full-Program Generation 기법과 비교 가능한 정량적 근거를 마련했다. 구현 코드와 데이터는 GitHub에 공개되어 재현성과 후속 연구 기반을 제공한다.
핵심 아이디어 이해하기
자연어에서 실행 가능한 DSL 스크립트를 직접 생성하려면 문법, API, 규제 요구사항이라는 세 가지 지식층이 모두 필요하다. 단일 LLM이 이러한 정보를 한 번에 정확히 생성하기 어렵고, 완전 프로그램 생성은 컴파일 실패 가능성이 높으며 기존 스니펫 조립은 새로운 시나리오 일반화에 한계가 있다. 따라서 문제를 컴포넌트 수준으로 분해해 각 컴포넌트에 대해 도메인 지식과 코드 패턴을 검색·주입하면 개별 컴포넌트의 문법적 정확성을 확보하면서 전체 프로그램의 호환성을 높일 수 있다.
방법론
시스템은 세 모듈로 구성된다. 인터랙티브 모듈은 사용자 질의를 받아 Interpreter로 논리적 구조(S = {G,R,E,O,T})를 추출하고 사용자의 피드백을 반영해 컴포넌트 설명을 반복 갱신한다. RAG 모듈은 코드 스니펫 데이터베이스와 문서 데이터베이스를 별도로 구축해 임베딩 기반 유사도 검색과 BM25 키워드 검색을 수행한 뒤 Reciprocal Rank Fusion으로 병합해 코드 패턴과 API 정의를 동시에 반환한다. 생성 모듈은 Global Configuration Generator로 헤더를 만들고 Generator_R/E/O/T를 순차 실행해 누적된 코드 컨텍스트를 입력으로 각 컴포넌트를 생성한 다음 단순 연결로 최종 Scenic 프로그램을 조립한다. 프롬프트 설계는 Contextual Prompting, Chain-of-Thought, In-Context Learning, 그리고 동적 CodeICL/DocICL을 계층적으로 결합해 모델의 문법·논리적 일관성 확보를 목표로 한다.
관련 Figure

해당 그림은 기존 Retrieval-assemble, Retrieval-generation 방식과 Chat2Scenic의 반복적 생성 흐름을 비교하며 Chat2Scenic이 데이터베이스와의 반복 상호작용을 통해 컴포넌트별 호환성을 확보하는 구조임을 시각적으로 드러낸다. 또한 상단과 하단 패널로 나뉜 비교를 통해 본 기법이 코드 검색과 동적 생성을 병행하는 점을 강조해 방법론의 핵심 구조적 차이를 보강한다.
프레임워크 전체 개요 다이어그램으로 사용자 질의, LLM, RAG 기반 검색, DSL 컴포넌트 생성의 반복적 흐름을 나타낸다.

이 그림은 인터랙티브 모듈, Generation Module, RAG Module을 분리해 각 구성요소의 입력·출력과 데이터베이스 연동 방식을 구조적으로 보여준다. 특히 코드 DB와 문서 DB의 분리 및 각기 다른 검색 전략(임베딩·BM25)을 적용하고 이를 병합하는 흐름이 시각적으로 정리되어 있어 듀얼 리트리버 설계 의도를 명확히 보강한다.
시스템 내부 모듈 구성도와 RAG 듀얼 리트리버, Generation Module의 흐름을 상세히 나타낸 다이어그램이다.

이 스크린샷은 사용자가 자연어로 요구를 입력하고 모델이 구조화된 Scenario Component Structure를 반환해 사용자가 'ok'로 확인하는 인터랙션 루프를 보여준다. 해당 이미지는 인터랙티브 모듈이 어떻게 사용자의 피드백을 받아 Interpreter의 출력을 갱신하고 이후 생성 단계로 전달하는지를 실무적 관점에서 보강한다.
챗봇 GUI 예시로 사용자 질의와 모델-사용자 상호작용을 통한 컴포넌트 검증 과정을 캡처한 스크린샷이다.
주요 결과
주요 실험은 CARLA 0.9.15와 Scenic 3.1.0 환경에서 123개 규제 기반 시나리오로 수행되었다. Gemini-3-Flash 기반의 최종 구성(C11: CP + CoT + ICL + CodeICL)에서 컴파일 성공률(CSR) 76.42%와 시나리오 품질(SQ) 76.12%를 기록해 기존 Retrieval Assemble(30.08% CSR) 및 Retrieval Generation(16.26% CSR) 방식보다 큰 개선을 보였다. 추가로 구성 요소별 어블레이션에서는 Contextual Prompting과 CodeICL의 결합이 CSR과 FA(FRamework Accuracy)를 상당히 끌어올렸고 DocICL은 토큰과 시간 비용 증가로 실험상 성능 이득을 보이지 못했다.
관련 Figure

이 이미지 집합은 생성된 Scenic 스크립트가 실제 시뮬레이션에서 어떻게 동작하는지를 시각적으로 확인시켜 주며 논문이 제안한 자동 생성 파이프라인이 시뮬레이터와 호환되어 실행 가능한 시나리오를 산출함을 보완한다. 각 타임스텝 프레임은 시나리오의 행동 전개와 객체 배치가 의도한 규제 기반 요구와 일치하는지 평가하는 근거로 활용될 수 있다.
CARLA에서 렌더링한 몇 가지 수행 예시 프레임으로 교차로·차선변경·보행자 충돌 시나리오 결과를 보여준다.
기술 상세
전체 아키텍처는 인터랙티브 모듈, RAG 모듈, 생성 모듈, 시뮬레이션 인터페이스로 구성된다. 인터랙티브 모듈에서는 LLM 기반 Interpreter가 사용자 질의를 받아 전역 설정 G와 내부 컴포넌트 집합 S_int={R,E,O,T}을 추출하고 LangGraph의 체크포인트 및 MemorySaver로 대화 상태를 유지한다. RAG 모듈은 코드 스니펫 DB를 임베딩(all-MiniLM-L6-v2)으로 인덱싱해 컴포넌트 설명과의 코사인 유사도로 상위 3개를 반환하고, 문서 DB는 BM25와 임베딩 하이브리드 검색 후 RRF로 병합해 API 정의와 넓은 문맥을 함께 제공한다.
관련 Figure

이 프롬프트 템플릿 그림은 User Requirements, Previously Generated Components, Implementation Plan, Scenıc Documentation, Example Components, Reference Code Snippets를 프롬프트 입력으로 명시해 Contextual Prompting과 CodeICL/DocICL의 결합 방식을 직관적으로 보여준다. 그림은 프롬프트 내 각 요소가 생성 제약(output_format)을 어떻게 강제하는지와 동적 검색이 어디에 삽입되는지를 보강한다.
컴포넌트 생성을 위한 구조화된 프롬프트 템플릿을 도식화한 이미지로 입력·지식·출력 제약을 구분해 제시하고 있다.
한계점
논문에서 명시된 한계로는 반복적 생성 과정이 응답 시간(RT)을 증가시켜 실시간 대화형 사용보다는 오프라인 배치 생성에 더 적합하다는 점이 있다. 또한 실험 결과에서 오픈소스 모델은 규모와 사전학습 데이터 차이로 인해 CSR이 거의 0% 수준으로 나타나 상용급 모델에 대한 의존성이 존재한다. DocICL 방식은 문서 기반 검색을 통해 일부 보강이 가능했으나 토큰과 시간 비용 증가로 실험상 전반적 성능 향상으로 연결되지 않는 제약이 보고되었다.
실무 활용
Chat2Scenic은 규제 문서를 기반으로 실행 가능한 Scenic 스크립트를 자동 생성할 수 있어 시뮬레이션 기반 ADS 검증 워크플로의 초기 시나리오 제작 비용을 낮출 수 있다. 공개된 코드 저장소를 통해 연구자와 엔지니어가 프레임워크를 실제 시뮬레이터 파이프라인에 통합해 오프라인 대규모 시나리오 생성에 활용할 수 있다. 다만 응답 시간과 토큰 비용이 상대적으로 크므로 오프라인 배치 생성과 자동화된 시나리오 컬렉션에 적합하다.
- 대규모 규제 기반 테스트셋 자동 생성은 개발 초기 단계에서 다양한 규정 케이스를 빠르게 코드화하고 시뮬레이터로 배치 실행해 시스템의 규제 준수 커버리지를 측정하는 데 활용될 수 있다. 이 과정에서 반복적 컴포넌트 생성은 새로운 규정 항목을 추가할 때 기존 코드베이스와의 호환성을 자동으로 반영해 수작업을 줄인다. 또한 생성 결과는 휴먼 리뷰를 거쳐 테스트 케이스 라이브러리로 편입되어 검증 파이프라인의 지속적 업데이트에 기여한다.
- 시나리오 변형 탐색에는 사용자 대화형 인터페이스를 통해 요구를 정제하고 즉시 코드화된 변형을 확보하는 용도로 사용될 수 있다. 운영자나 검증 담당자가 자연어로 조건을 수정하면 Interpreter가 논리 구조를 갱신하고 RAG가 관련 코드 예시를 제공해 즉시 실행 가능한 변형 시나리오를 생성한다. 이 방식은 규제 해석이 불명확한 케이스에서 반복적 인간-기계 상호작용을 통해 요구를 구체화하는 데 유리하다.
- 교육 및 자료 제작 측면에서는 규제 문서와 Scenic 코드 패턴을 연계해 학습용 사례를 대량 생산하는 데 유용하다. 연구 그룹이나 교육 기관은 벤치마크 시나리오를 자동 생성해 학생·연구자에게 다양한 에지케이스를 제공하고 시뮬레이션 기반 실험을 표준화할 수 있다. 공개 리포지토리를 통해 재현 가능한 실습자료를 배포하면 커뮤니티 기반 개선도 촉진된다.
코드 공개 여부: 공개
코드 저장소 보기키워드
용어 해설
- 검색 증강 생성(RAG)
- — 검색 증강 생성은 외부 지식 소스에서 관련 문서나 코드 조각을 검색하여 생성 모델의 입력으로 제공하는 방식이다. 본문맥에서는 규제 문서와 DSL 코드 스니펫을 검색해 LLM의 출력이 실제 Scenic 문법과 규제 요구사항에 부합하도록 문맥을 보강하는 데 사용된다. 이렇게 하면 모델의 망상(hallucination) 위험을 낮추고 컴파일 성공률을 높일 수 있다.
- 문맥 내 학습(In-Context Learning)
- — 문맥 내 학습은 모델 프롬프트에 정답 예시를 함께 제공하여 별도 파인튜닝 없이 모델이 예시 패턴을 따라 출력하도록 유도하는 기법이다. 이 연구에서는 코드·문서 예시를 동적으로 검색해 프롬프트에 포함하는 CodeICL/DocICL 방식으로 적용되어 특정 DSL 패턴 수렴을 돕는다. 동적 검색을 통해 고정된 소수 예시보다 도메인 적합도를 향상시키는 역할을 한다.
- 추론 단계화(Chain-of-Thought)(Chain-of-Thought)
- — Chain-of-Thought는 복잡한 생성 작업을 여러 추론 단계로 분해하여 모델이 단계별로 사고하도록 유도하는 프롬프트 기법이다. 본 논문에서는 컴포넌트별 생성 절차(요구 이해→컨텍스트 검사→타입 선택→파라미터 정의→행동 인스턴스화→검증)를 명시해 모델이 문법적·논리적 일관성을 유지하도록 사용된다. 단계화된 추론은 특히 상호 의존적 컴포넌트를 순차 생성할 때 호환성 오류를 줄이는 데 기여한다.
- 상호 랭크 융합(Reciprocal Rank Fusion)
- — 상호 랭크 융합은 서로 다른 검색 결과 순위를 결합해 최종 순위를 생성하는 방법이다. 본문에서는 BM25 기반 문서 검색 결과와 임베딩 기반 유사도 결과를 RRF로 병합해 API 정의와 넓은 의미의 설명을 동시에 포함하는 문서 청크를 반환하도록 구성했다. 이렇게 하면 정확한 API 참조와 일반적 규제 문맥을 동시에 확보할 수 있다.
- 코드 기반 문맥내 학습(CodeICL)
- — CodeICL은 프롬프트에 코드 예시(정답 패턴)를 포함시켜 모델이 코드 스타일과 API 사용을 모방하도록 하는 기법이다. 이 논문에서는 컴포넌트별로 유사한 Scenic 코드 스니펫 상위 3개를 동적으로 검색해 프롬프트에 넣음으로써 문법적 정확성과 컴파일 성공률을 대폭 향상시켰다. 추가 코드 예시가 모델의 수렴 속도를 높이고 오류 수정 단계를 줄이는 근거가 실험으로 확인되었다.
코드 예제
Algorithm 1 Generation Pipeline
1: Input: user_query (Scenario description)
2: Output: \mathcal{S}_{code} (Scenic program)
3: — Step 1: Logical Structure Extraction —
4: \mathcal{S}_{int} \leftarrow Interpreter(user_query) ⊳ extract {R,E,O,T}
5: — Step 2: Global Configuration —
6: (detected,confidence) \leftarrow SettingsDetector(user_query)
7: for p \in {map,weather,models} do
8: if confidence[p] \geq 0.6 and detected[p]
eq null then
9: G_settings[p] \leftarrow detected[p] ⊳ use detected value
10: else
11: G_settings[p] \leftarrow default[p] ⊳ fall back to default
12: end if
13: end for
14: G_code \leftarrow HeaderGenerator(G_settings) ⊳ Scenic header
15: — Step 3: Iterative Component Generation —
16: R_code \leftarrow Generator_R(R, G_code)
17: E_code \leftarrow Generator_E(E, G_code, R_code)
18: for i = 1 to N do
19: O_{i,code} \leftarrow Generator_O(O_i, G_code, R_code, E_code, O_{1:i-1,code})
20: end for
21: T_code \leftarrow Generator_T(T, G_code, R_code, E_code, O_{1:N,code})
22: \mathcal{S}_{code} \leftarrow {G_code, R_code, E_code, O_{1:N,code}, T_code}
23: return \mathcal{S}_{code}이 의사코드는 사용자 자연어 설명에서 논리 구조를 추출하고 전역 설정을 결정한 뒤, 공간관계·에고·객체·제약 조건을 순차적으로 생성해 최종 Scenic 스크립트를 구성하는 파이프라인을 요약한 것이다.
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.