Skip to main content
개선은 저마다 레버 하나, 그러니까 시스템의 특정 부분을 겨냥합니다. 맞는 레버를 고르는 게 중요합니다. 엉뚱한 걸 고르면 힘만 빼고 회귀까지 끌어들이기 일쑤입니다.

레버들

1. 프롬프트

Agent의 역할이나 시스템 프롬프트를 바꿉니다. 이럴 때 잘 듣습니다.
  • 빠진 동작(“항상 소스를 인용”).
  • 톤이나 형식이 어긋남.
  • 지금 프롬프트가 언급하지 않는 가장자리 케이스.
테스트가 빠르고 고쳐 보기도 쌉니다. 다만 너무 다시 쓰면 다른 동작이 흔들립니다.

2. 도구 설명

도구가 무엇을 한다고 하는지를 다듬습니다. 이럴 때 잘 듣습니다.
  • Agent가 엉뚱한 도구를 고름.
  • 맞는 도구를 골랐는데 인자를 틀림.
  • 불러야 할 도구를 안 부름.
들인 품에 비해 효과가 큽니다. LLM은 이 설명을 보고 도구를 쓸지 정하니까요.

3. 도구 구현

도구가 실제로 하는 일이나 데이터를 돌려주는 방식을 바꿉니다. 이럴 때 잘 듣습니다.
  • 도구 응답이 헷갈리게 함(반쪽 데이터에 성공을 돌려줌).
  • Agent가 필요한 필드를 도구가 안 담아 줌.
  • 도구가 너무 헐거워서 막아야 할 작업까지 허용함.
코드를 바꿔야 해서 고쳐 보기가 느리지만, 가끔은 피할 수 없습니다.

4. 리트리벌 프리셋

리트리벌 설정(가중치, 필터, top-K, 부스트)을 바꿉니다. 이럴 때 잘 듣습니다.
  • 맞는 청크가 색인은 됐는데 안 딸려 옴.
  • 청크가 딸려 오긴 하는데 순서가 틀림.
  • 관련 낮은 청크가 컨텍스트를 뒤덮음.

5. 데이터 소스

지식을 넣거나, 태그하거나, 대체하거나, 다시 짭니다. 이럴 때 잘 듣습니다.
  • 답이 지식에 아예 없음(넣기).
  • 답은 있는데 오래됨(대체).
  • 답은 있는데 태그가 틀림(다시 태그).
Flow를 건드릴 필요가 없는, 순수한 데이터 변경입니다.

6. 메모리 룰

절차 룰을 더합니다. 이럴 때 잘 듣습니다.
  • Agent에 상시 동작이 필요함(“Y 전에 항상 X”).
  • 특정 교정을 앞으로 모든 실행에 적용해야 함.
넣기 빠르고 빼기 쉽고, 배포도 필요 없습니다(룰은 바로 먹습니다).

7. 인과 그래프

엣지나 변수를 더하거나 손봅니다. 이럴 때 잘 듣습니다.
  • 검증이 헛발질함(그래프가 틀림).
  • 검증이 진짜 오류를 못 잡음(그래프에 엣지가 빠짐).

8. 라우팅

의도마다 Agent를 나눕니다. 이럴 때 잘 듣습니다.
  • Agent 하나가 너무 많은 걸 하려다 뭐 하나 제대로 못함.
  • 의도마다 비용 성격이 크게 다름(싼 의도는 싼 모델로 보내기).
Flow를 다시 짜는 일이라 시뮬레이션이 꼭 필요합니다.

9. 가드레일 / 승인

특정 액션에 가드레일이나 승인 게이트를 더합니다. 이럴 때 잘 듣습니다.
  • Agent가 사람 리뷰를 거쳐야 할 결정을 내림.
  • 특정 출력을 아예 막아야 함.
품질을 고치진 못합니다. 품질이 나아지는 동안 피해를 막아 줄 뿐입니다.

10. 모델 스왑

Agent가 쓰는 모델을 바꾸거나 폴백을 씁니다. 이럴 때 잘 듣습니다.
  • 실패가 끊이지 않아 모델이 이 도메인을 감당 못한다고 보임.
  • 비용과 품질의 맞교환이 Pareto 프론티어의 다른 모델을 가리킴.
가장 큰 레버이고 비용과 지연에 미치는 영향도 가장 큽니다. 시뮬레이션을 넉넉히 돌리세요.

Nora의 레버 선택

근본 원인 유형마다 Nora가 선호하는 레버가 있습니다.
  • 리트리벌 이슈 → 리트리벌 프리셋 > 데이터 소스 > 프롬프트.
  • 프롬프트 이슈 → 프롬프트 > 메모리 룰 > 도구 설명.
  • 도구 이슈 → 도구 설명 > 도구 구현 > 프롬프트.
  • 데이터 이슈 → 데이터 소스(넣기/태그/대체). 이것 말곤 안 고쳐집니다.
  • 메모리 이슈 → 메모리 룰 > 스코프 설정 > 새 메모리 스페이스.
  • 그라운딩 이슈 → 인과 그래프 > 데이터 소스.
  • 모델 이슈 → 모델 스왑 > 프롬프트 조이기.
순서는 “이 유형을 그럴듯하게 다룰 만한 것 중 가장 싼 것부터” 를 따릅니다.

레버 직접 고르기

Nora의 기본값은 덮어쓸 수 있습니다. Proposals → Change lever에서 다른 레버를 고르면 Nora가 그 레버를 겨냥해 제안을 다시 만듭니다. 자동 진단보다 여러분이 도메인을 잘 알 때 좋습니다. 예를 들어 Nora는 리트리벌 수정을 제안하는데, 룰 하나면 더 간단하다는 걸 여러분이 아는 경우죠.

레버가 여럿 걸릴 때

복잡한 클러스터는 근본 원인도 여럿, 그럴듯한 레버도 여럿입니다. Nora가 레버마다 제안을 만들고, 어느 조합을 출시할지 여러분이 고르게 합니다(대개 하나면 됩니다. 너무 많이 고치면 회귀를 부릅니다). 레버 두 개를 한 번에 출시했다면, 어느 쪽이 실제로 도왔는지 가려내려면 시뮬레이션이 꼭 필요합니다.