컴백부터 K-뷰티까지 — K-컬쳐의 모든 것을 메일로 받아보세요메일로 받아보기

고객상담 AI 상담원이 규정을 '한 번의 행동'이 아니라 '전체 절차'로 지키게 만드는 방법

arXiv:2608.198612026-08-21

PolicyGuide: From Guarding One Action to Guiding the Whole Workflow for Policy-Compliant LLM Agents

고객상담 AI 상담원이 규정을 '한 번의 행동'이 아니라 '전체 절차'로 지키게 만드는 방법

고객서비스 LLM 에이전트는 위험한 행동 하나만 막는 게 아니라 신원확인, 순서, 확인 절차 같은 여러 단계를 빠짐없이 지켜야 한다. PolicyGuide는 회사 정책 문서를 그래프(순서도) 형태로 미리 변환해두고, 대화가 진행될 때마다 별도의 검증 AI가 지금까지의 대화를 그래프와 대조해 다음에 해야 할 일을 알려준다. GPT-5.4 에이전트 기준으로 항공, 소매, 통신 세 도메인에서 평균 성공률(4번 중 4번 다 통과하는 비율)을 0.42에서 0.62로 끌어올렸고, 절차가 가장 복잡한 통신 도메인에서는 0.19에서 0.61로 가장 크게 개선됐다.

METAL MEDIA 해설 도표

고객상담 AI 상담원이 규정을 '한 번의 행동'이 아니라 '전체 절차'로 지키게 만드는 방법

01문제 정의: 규정 위반은 '금지된 행동을 함'뿐 아니라 '신원확인이나 최종 확인 같은 절차를 빠뜨림'으로도 발생하는데, 기존 안전장치는 위험한 행동 하나가 발생하는 순간에만 개입해서 그 이전 단계의 누락은 잡아내지 못한다.
02방법: PolicyGuide는 각 도메인의 정책 문서를 미리 오프라인으로 분석해 '누가 무엇을 해야 하는지'를 노드와 화살표로 표현한 워크플로우 그래프로 만들어두고, 대화가 매 턴 넘어갈 때마다 검증 전용 LLM이 지금까지의 대화 기록과 그래프상의 진행 위치를 대조해 아직 만족되지 않은 첫 단계를 찾아 구체적인 개선 지시(remediation)를 에이전트에게 전달한다.
03이 위치 정보는 대화 시스템의 기억이 아니라 별도 코드가 계속 저장하고 있어서, 여러 개의 진행 중인 요청을 동시에 놓치지 않고 추적할 수 있다.
04결과: τ2-bench의 항공/소매/통신 벤치마크에서 GPT-5.4 기준 평균 Pass4(4번 시도 모두 성공하는 비율)를 0.42에서 0.62로 올렸고, 특히 절차가 가장 정교한 통신 도메인에서 0.19에서 0.61로 가장 크게 개선됐다. 같은 워크플로우를 Claude Sonnet 4.6, Gemini 2.5 Pro 에이전트에 그대로 적용해도 효과가 이어졌고, 사용자가 거짓 정보로 속이려는 적대적 상황에서도 공격 성공률이 가장 낮았다.

METAL MEDIA이 원문을 바탕으로 재구성한 해설 도표이며, 논문 저자의 원문 figure가 아닙니다.

무엇을 했나

문제 정의: 규정 위반은 '금지된 행동을 함'뿐 아니라 '신원확인이나 최종 확인 같은 절차를 빠뜨림'으로도 발생하는데, 기존 안전장치는 위험한 행동 하나가 발생하는 순간에만 개입해서 그 이전 단계의 누락은 잡아내지 못한다.
방법: PolicyGuide는 각 도메인의 정책 문서를 미리 오프라인으로 분석해 '누가 무엇을 해야 하는지'를 노드와 화살표로 표현한 워크플로우 그래프로 만들어두고, 대화가 매 턴 넘어갈 때마다 검증 전용 LLM이 지금까지의 대화 기록과 그래프상의 진행 위치를 대조해 아직 만족되지 않은 첫 단계를 찾아 구체적인 개선 지시(remediation)를 에이전트에게 전달한다.
이 위치 정보는 대화 시스템의 기억이 아니라 별도 코드가 계속 저장하고 있어서, 여러 개의 진행 중인 요청을 동시에 놓치지 않고 추적할 수 있다.
결과: τ2-bench의 항공/소매/통신 벤치마크에서 GPT-5.4 기준 평균 Pass4(4번 시도 모두 성공하는 비율)를 0.42에서 0.62로 올렸고, 특히 절차가 가장 정교한 통신 도메인에서 0.19에서 0.61로 가장 크게 개선됐다. 같은 워크플로우를 Claude Sonnet 4.6, Gemini 2.5 Pro 에이전트에 그대로 적용해도 효과가 이어졌고, 사용자가 거짓 정보로 속이려는 적대적 상황에서도 공격 성공률이 가장 낮았다.

Table 1: Main results on the base splits (GPT 5.4 agent, n=4; airline 50, retail/telecom 114 tasks). Cells report Pass1 and Pass4 overall and on the PV/Mut slices. The verifier is absent for ReAct, static code for ToolGuard, and GPT 5.4 for PolicyGuard and PolicyGuide.
			Airline (50)		Retail (114)		Telecom (114)
	System	Verifier	Overall	PV	Mut		Overall	PV	Mut		Overall	PV	Mut
Pass1	ReAct	—	0.640	0.865	0.433		0.800	0.900	0.791		0.384	0.721	0.180
ToolGuard	static code	0.575	0.969	0.212		—	—	—		—	—	—
PolicyGuard	GPT 5.4	0.710	1.000	0.442		0.645	0.975	0.613		0.406	0.733	0.208
PolicyGuide	GPT 5.4	0.775	0.979	0.587		0.809	0.975	0.793		0.866	0.895	0.849
Pass4	ReAct	—	0.460	0.750	0.192		0.596	0.700	0.587		0.193	0.442	0.042
ToolGuard	static code	0.520	0.875	0.192		—	—	—		—	—	—
PolicyGuard	GPT 5.4	0.580	1.000	0.192		0.360	0.900	0.308		0.202	0.488	0.028
PolicyGuide	GPT 5.4	0.620	0.917	0.346		0.614	0.900	0.587		0.614	0.721	0.549

Table 2: Workflow ablations (GPT 5.4 agent; Airline base split, Retail and Telecom benchmark test splits of 40 tasks). All cells report Pass4.
Domain	Metric	ReAct	PolicyGuide Self	PolicyGuide Raw	PolicyGuide
Airline	Overall	0.460	0.480	0.520	0.620
PV	0.750	0.833	0.875	0.917
Mut	0.192	0.154	0.192	0.346
Retail	Overall	0.575	0.350	0.575	0.725
PV	0.750	0.750	0.750	1.000
Mut	0.556	0.306	0.556	0.694
Telecom	Overall	0.250	0.325	0.350	0.675
PV	0.429	0.571	0.619	0.667
Mut	0.053	0.053	0.053	0.684

Table 3: Matched workflow-controller comparison on the 40-task Telecom benchmark test split. All values are Pass4.
System	Runtime control	Pass4
ReAct	actor only	0.250
PolicyGuard	action-local check	0.325
FlowAgent	PDL + API control	0.350
PolicyGuide	external graph verifier	0.675

Table 4: Agent-family generalization on Airline (50 tasks, n=4; verifier model paired to the agent). All metrics are Pass4. The GPT 5.4-authored workflow graph is reused without re-authoring.
Agent	Metric	ReAct	PolicyGuard	PolicyGuide
GPT 5.4	Overall	0.460	0.580	0.620
PV	0.750	1.000	0.917
Mut	0.192	0.192	0.346
Claude Sonnet 4.6	Overall	0.720	0.780	0.780
PV	0.958	1.000	1.000
Mut	0.500	0.577	0.577
Gemini 2.5 Pro	Overall	0.480	0.600	0.680
PV	0.750	1.000	0.917
Mut	0.231	0.231	0.462

Table 5: Author-designed Telecom ordered trace compliance (%; n=4). Step- and Trace-TCR condition on outcome-passing traces.
System	Step-TCR	Trace-TCR	Process-valid rate
ReAct	86.4	35.4	17.5
PolicyGuard	85.7	23.9	13.1
PolicyGuide	94.5	63.4	56.2

Table 6: Argument- (A), process- (P), and workflow-level (W) partition of the source policies (W splits PolicyGuard’s process-level class; P+W equals it).
Domain	A	P	W	Total	% P+W	% W
Airline	14	27	2	43	67.4%	4.7%
Retail	0	27	1	28	∼100%	3.6%
Telecom (main)	1	21	7	29	96.6%	24.1%
Telecom (manual)	0	1	20	21	100%	95.2%
Telecom (both)	1	22	27	50	98.0%	54.0%

Table 7: Hand-classified atomic requirements of the τ2-bench Retail policy document (28 requirements, 0 A / 27 P / 1 W; subtypes D-only 13, T-only 14, D+T 1). Line refers to retail/policy.md as released with τ2-bench; Type A = argument-level, P = process-level (flat), W = workflow-level (order-bound; Appendix B.1), with D = dialogue-dependent, T = requires a prior read-only tool call.
ID	Line	Requirement (paraphrased)	Type
Global rules
G1	10	Authenticate identity by locating the user id via email or name+zip—even when the user already provides the id	P (D+T)
G2	14	One user per conversation; deny any request about another user	P (D)
G3	16	List action details + obtain explicit “yes” before any DB-updating action	P (D)
G4	18	No fabricated information/knowledge/procedures; no subjective recommendations	P (D)
G5	20	At most one tool call per turn (not paired with a user-facing reply)	P (D)
G6	22	Deny user requests that are against the policy	P (D)
G7	24	Transfer iff unhandleable: call transfer_to_human_agents, then the literal handoff message	W (D)
Generic action rules
N1	82	Act only on orders with status pending or delivered	P (T)
N2	84	Exchange / modify-items tools callable only once per order	P (T)
N3	84	Collect all items to change into one list before making the call	P (D)
Cancel pending order
C1	88	Order status must be pending; check it before taking the action	P (T)
C2	90	User confirms order id + reason ∈ {‘no longer needed’, ‘ordered by mistake’}; no other reason	P (D)
Modify pending order
M1	96	Order status must be pending; check it before taking the action	P (T)
M2	98	Only shipping address, payment method, or item options may be modified—nothing else	P (D)
M3	102	New payment = a single method, different from the original	P (T)
M4	104	If the new payment is a gift card, its balance must cover the total amount	P (T)
M5	110	Modify-items is one-shot (order becomes unmodifiable): remind + confirm all items first	P (D)
M6	112	Each new item must be available	P (T)
M7	112	New item = same product, different option (no product-type change)	P (T)
M8	114	User provides a payment method for the price difference	P (D)
M9	114	If that payment is a gift card, its balance must cover the price difference	P (T)
Return delivered order
R1	118	Order status must be delivered; check it before taking the action	P (T)
R2	120	User confirms order id + the list of items to be returned	P (D)
R3	122–124	Refund method provided; must be the original payment method or an existing gift card	P (T)
Exchange delivered order

Table 8: Hand-classified atomic requirements of the τ2-bench Telecom main_policy.md (29 requirements, 1 A / 21 P / 7 W). Line refers to the document as released with τ2-bench; \raisebox{-0.4pt}{\scriptsize$n$}⃝ marks a step in an ordered procedure (“To do so you need to follow these steps”). Types as in Table 7.
ID	Line	Requirement (paraphrased)	Type
Global rules
G1	7	No fabricated information/knowledge/procedures; no subjective recommendations	P (D)
G2	9	At most one tool call per turn (not paired with a user-facing reply)	P (D)
G3	11	Deny user requests that are against the policy	P (D)
G4	13	Transfer iff unhandleable: call transfer_to_human_agents, then the literal handoff message	W (D)
G5	15	Try your best to resolve the issue before transferring	W (D)
Customer lookup
L1	94–97	Identify the customer via phone number, customer ID, or full name + date of birth	P (D+T)
L2	99	For name lookup, date of birth is required for verification	P (D)
Overdue bill payment (ordered procedure)
O1	105, 117	\raisebox{-0.4pt}{\scriptsize1}⃝Check the bill status is Overdue before acting (the API does not check it)	P (T)
O2	106	\raisebox{-0.4pt}{\scriptsize2}⃝Check the bill amount due	P (T)
O3	107–108	\raisebox{-0.4pt}{\scriptsize3}⃝Send the payment request (→ AWAITING PAYMENT); gated on O1	P (T)
O4	109–110	\raisebox{-0.4pt}{\scriptsize4}⃝Inform the user to check their payment requests	W (D)
O5	111	\raisebox{-0.4pt}{\scriptsize5}⃝Only after the user accepts, call make_payment	W (D+T)
O6	113	\raisebox{-0.4pt}{\scriptsize6}⃝Always verify the bill became PAID before telling the user	W (T)
O7	116	At most one bill in AWAITING PAYMENT at a time	P (T)
Line suspension
S1	125	Lift a suspension only after all overdue bills are paid	W (T)
S2	126	Do not lift if the contract end date is past—even if all bills are paid	P (T)
S3	128	After resuming, instruct the user to reboot the device	W (D)
Data refueling (ordered procedure)
F1	134	Refuel amount ≤2 GB	A
F2	136	\raisebox{-0.4pt}{\scriptsize1}⃝Ask how much data the user wants to refuel	P (D)
F3	137	\raisebox{-0.4pt}{\scriptsize2}⃝Confirm the price	P (D)
F4	138	\raisebox{-0.4pt}{\scriptsize3}⃝Apply the refuel to the line associated with the user’s phone number	P (D+T)
Change plan (ordered procedure)
P1	144	\raisebox{-0.4pt}{\scriptsize1}⃝Establish which line the plan change is for	P (D)
P2	145	\raisebox{-0.4pt}{\scriptsize2}⃝Gather the available plans	P (T)
P3	146	\raisebox{-0.4pt}{\scriptsize3}⃝Ask the user to select one	P (D)

Table 9: Hand-classified atomic requirements of the τ2-bench Telecom tech_support_manual.md (21 requirements, 1 P / 20 W). Line refers to the document as released with τ2-bench. Every rule is a diagnostic-gated (T) user-guidance (D) step; the three chapters form the prerequisite chain Service ⊂ Data ⊂ MMS; every row except TSS1 (the entry diagnostic) is workflow-level.
ID	Line	Requirement (diagnose → conditional fix → verify)	Type
Cellular service (ll. 55–99)
TSS1	69–72	Diagnose service via check_status_bar	P (T)
TSS2	74–78	If Airplane Mode ON → guide toggle_airplane_mode OFF	W (D+T)
TSS3	79–87	Check SIM: Missing → reseat; Locked → escalate; Active → ok (three-way branch)	W (D+T)
TSS4	88–92	If APN incorrect → guide reset_apn_settings, then reboot_device	W (D+T)
TSS5	93–99	If line suspended → handle per main policy, then verify service restored	W (T)
Mobile data (ll. 100–163)
TSD0	106–108	Prerequisite: the user must first have cellular service	W (T)
TSD1	122–127	Diagnose via run_speed_test	W (T)
TSD2	129–131	Airplane Mode (as in the Service chapter)	W (D+T)
TSD3	132–135	If mobile data disabled → guide toggle_data ON	W (D+T)
TSD4	136–141	If roaming abroad & data off → guide toggle_roaming + verify the line is roaming-enabled	W (D+T)
TSD5	142–145	If Data Saver ON → guide toggle_data_saver_mode OFF	W (D+T)
TSD6	146–150	If VPN ON & performance poor → guide disconnect_vpn	W (D+T)
TSD7	151–158	If usage exceeds the plan limit → offer change-plan or refuel	W (T)
TSD8	159–163	If network mode 2G/3G → guide set_network_mode_preference	W (D+T)
MMS (ll. 164–205)
TSM0	170–173	Prerequisite: the user must have cellular service and mobile data	W (T)
TSM1	181–183	Diagnose via can_send_mms	W (T)
TSM2	185–188	Ensure basic service + data connectivity first	W (T)
TSM3	189–193	If on 2G → guide set_network_mode_preference to 3G+	W (D+T)
TSM4	194–199	If MMSC URL unset → guide reset_apn_settings, then reboot_device	W (D+T)
TSM5	200–203	If Wi-Fi Calling ON → guide toggle_wifi_calling OFF	W (D+T)
TSM6	204–205	If the messaging app lacks storage/SMS permissions → guide grant_app_permission	W (D+T)

Table 10: Passk breakdown for the base-split results in Table 1 and Figure 4 (GPT 5.4, n=4). P4/P1 is the consistency ratio.
Domain	System	P1	P2	P3	P4	P4/P1
Airline	ReAct	0.640	0.530	0.485	0.460	0.72
ToolGuard	0.575	0.553	0.535	0.520	0.90
PolicyGuard	0.710	0.630	0.595	0.580	0.82
PolicyGuide	0.775	0.707	0.660	0.620	0.80
Retail	ReAct	0.800	0.700	0.638	0.596	0.75
PolicyGuard	0.645	0.506	0.421	0.360	0.56
PolicyGuide	0.809	0.715	0.654	0.614	0.76
Telecom	ReAct	0.384	0.273	0.226	0.193	0.50
PolicyGuard	0.406	0.292	0.237	0.202	0.50
PolicyGuide	0.866	0.763	0.682	0.614	0.71

Table 11: Pass1 in each of the four trials on the base splits. pstd is the population standard deviation across trial-level values.
Domain	System	T1	T2	T3	T4	pstd
Airline	ReAct	0.620	0.620	0.640	0.680	0.024
ToolGuard	0.560	0.580	0.580	0.580	0.009
PolicyGuard	0.700	0.740	0.700	0.700	0.017
PolicyGuide	0.800	0.720	0.820	0.760	0.038
Retail	ReAct	0.807	0.746	0.842	0.807	0.035
PolicyGuard	0.649	0.623	0.632	0.675	0.020
PolicyGuide	0.816	0.798	0.789	0.833	0.017
Telecom	ReAct	0.342	0.377	0.404	0.412	0.027
PolicyGuard	0.465	0.386	0.360	0.412	0.039
PolicyGuide	0.860	0.860	0.842	0.904	0.023

Table 12: Pooled stratified McNemar tests on per-task Pass4. D is the number of domain strata; a counts PolicyGuide-only passes and b the reverse, summed across strata.
Opponent	D	∑a	∑b	ndisc	Z	p
ReAct	3	77	19	96	+5.92	<10−8
PolicyGuard	3	97	19	116	+7.24	<10−12

Table 13: Per-domain paired-bootstrap differences in Pass4 on the base splits (10,000 task-level resamples). Positive values favor PolicyGuide.
Domain	Opponent	n	ΔP4 [95% CI]
Airline	ReAct	50	+0.160 [+0.020, +0.300]
ToolGuard	50	+0.100 [−0.040, +0.260]
PolicyGuard	50	+0.040 [−0.080, +0.160]
Retail	ReAct	114	+0.018 [−0.070, +0.105]
PolicyGuard	114	+0.254 [+0.149, +0.360]
Telecom	ReAct	114	+0.421 [+0.316, +0.526]
PolicyGuard	114	+0.412 [+0.298, +0.526]

Table 14: Guide-side model usage for the GPT 5.4 configuration (50 Airline and 40 Retail/Telecom tasks). Costs exclude the actor and user simulator.
Domain	Calls/ task	Prompt tok./call	Cached input	Output tok./call	Guide total $	Guide $/task
Airline	7.56	32,360	88.1%	2,478	20.10	0.40
Retail	7.42	22,803	85.8%	2,179	13.67	0.34
Telecom	11.47	28,518	86.5%	2,186	22.29	0.56

Table 15: Mean end-to-end wall-clock time per task.
Domain	ReAct (s/task)	PolicyGuide (s/task)	Ratio
Airline	36.4	210.1	5.78×
Retail	34.6	193.6	5.60×
Telecom	45.5	247.6	5.45×

Table 16: Programmatic validation rerun on the frozen workflow graphs.
Domain	Nodes	Auth. nodes	Validator flags
Airline	158	11	0
Retail	104	7	0
Telecom	127	5	1

Table 17: Call-NMR on passing Mut trajectories (n=4): percentage of successfully executed agent mutations missing a frozen guard-derived read prerequisite. †Telecom is an adapted, agent-side diagnostic whose read oracle saturates; its zeros do not establish equal procedural quality.
Call-NMR (%; ↓)	Airline	Retail	Telecom†
ReAct	25.4	47.6	0.0
PolicyGuard	32.5	34.8	0.0
PolicyGuide	15.6	34.7	0.0

왜 중요한가

금융, 통신, 항공 같은 실제 고객상담 업무에 LLM 에이전트를 투입하려면 단순히 '틀린 행동을 막는 것'만으로는 부족하고, 신원확인·승인·확인 같은 절차 전체를 지키는지가 중요하다. 이 연구는 모델을 재학습하지 않고도 외부에서 규정 준수를 감독할 수 있는 실용적인 틀을 제시해, 실제 상담 서비스에 AI를 도입할 때 신뢰성을 높이는 방법을 보여준다.

이 논문의 용어

Pass4 · 같은 작업을 4번 반복 시도했을 때 4번 모두 성공하는 비율. 일관성 있게 성공하는지를 재는 지표
워크플로우 그래프 · 정책 문서에 적힌 절차를 '누가 무엇을 언제 하는지' 노드와 연결선으로 표현한 순서도
검증기(verifier) · 에이전트의 대화와 행동을 지켜보며 규정 준수 여부를 판단하고 다음 할 일을 알려주는 별도의 감시용 AI
τ2-bench · 항공·소매·통신 분야 고객상담 AI 에이전트의 정책 준수 능력을 평가하는 벤치마크
공격 성공률(ASR) · 사용자가 거짓 정보로 에이전트를 속여 금지된 행동을 하게 만드는 데 성공한 비율

저자 · Seongjae Kang, Taehyung Yu, Sung Ju Hwang

arXiv에서 원문 보기

최신 논문

논문 전체 보기 →

METAL MEDIA 최신 기사