Role Discipline: System, User, Assistant

Role은 장식이 아니야

chat API는 대부분 system, user, assistant 메시지를 구분해. system 메시지가 권한이 제일 세고, spine이 살기 딱 좋은 자리지. user는 시킬 일, assistant는 답변이고. 이걸 섞어버리면 — tool schema를 user에 넣고, 규칙을 assistant에 적고, 긴 대화를 user 메시지 하나에 쏟아붓고 — 권한이 흩어지고 cache도 헷갈려.

여러 turn 넘어가도 그대로

지난 대화를 다시 실어 보낼 때 role을 그대로 지켜. 대화 전체를 거대한 user 메시지 하나로 뭉개도 돈은 하나도 안 굳어. 누가 뭘 말했는지 따라갈 능력만 망가지지. 요즘 API는 token 단위로 값을 매기지 메시지 단위로 매기지 않거든. role을 지키는 데 드는 비용은 구조를 깔끔하게 유지하는 수고뿐이야.

개념 하나에 role 하나

system은 규칙. user는 시킬 일. assistant는 답변. tool 메시지는 tool 결과. API에 'role' 자리가 있다는 건 그게 일을 한다는 뜻이야. 설계된 대로 써.

Code

깔끔한 role 배치·python

messages = [
  {"role": "system", "content": SPINE},
  {"role": "user", "content": prior_user_1},
  {"role": "assistant", "content": prior_assistant_1},
  {"role": "user", "content": prior_user_2},
  {"role": "assistant", "content": prior_assistant_2},
  {"role": "user", "content": current_question},
]

이러면 안 되는 예: 뭉개진 대화·python

# DO NOT DO THIS
messages = [
  {"role": "system", "content": SPINE},
  {"role": "user", "content":
      "Earlier I said X. You replied Y. Then I said Z. Now I want W."},
]
# Squashing kills role-aware attention and breaks cache structure.

Exercise

메시지를 만드는 코드를 하나 훑어봐. system에 spine이, user에 시킬 일이, assistant에 지난 답변이, tool 메시지에 tool 결과가 들어가 있는지 확인해. 뭉개진 데가 있으면 풀고.

Hint

user 메시지 안에 'Earlier I said' 같은 문장이 보이면 뭉개기 버그야.