> ## Documentation Index
> Fetch the complete documentation index at: https://docs.platform.nora.my/llms.txt
> Use this file to discover all available pages before exploring further.

# 어느 레버 튜닝

> 프롬프트, 도구, 리트리벌, 메모리, 룰 — 이 실패에 어느 변경이 말 되나?

모든 개선이 하나의 레버 — 시스템의 특정 부분 — 타겟. 올바른 레버 선택이 중요: 잘못된 것은 노력 낭비하고 종종 회귀 도입.

## 레버

### 1. 프롬프트

Agent 의 역할이나 시스템 프롬프트 변경. 효과적:

* 누락 동작 ("항상 소스 인용").
* 잘못된 톤이나 포맷.
* 현재 프롬프트가 언급 안 하는 엣지 케이스 처리.

테스트 빠름, 반복 저렴. 위험: 너무 재표현하면 다른 동작에 드리프트.

### 2. 도구 설명

도구가 약속하는 것 정제. 효과적일 때:

* Agent 가 잘못된 도구 선택.
* Agent 가 올바른 도구를 잘못된 인자로 선택.
* Agent 가 호출해야 할 도구 호출 안 함.

노력 단위당 매우 효과적 — LLM 이 설명으로 도구 사용 결정.

### 3. 도구 구현

도구가 실제 하는 것이나 데이터 반환 방식 변경. 효과적일 때:

* 도구 응답이 오해 소지 (부분 데이터에 성공 반환).
* 도구가 Agent 필요한 필드 포함 안 함.
* 도구가 너무 허용적 (게이트되어야 할 작업 허용).

반복 느림 (코드 변경) 지만 가끔 불가피.

### 4. 리트리벌 프리셋

리트리벌 설정 (가중치, 필터, top-K, 부스트) 변경. 효과적일 때:

* 올바른 청크가 인덱스됐지만 리트리벌 안 됨.
* 청크 리트리벌됐지만 잘못된 순서.
* 낮은 관련도 청크가 컨텍스트 홍수.

### 5. 데이터 소스

지식 추가·태그·supersede·재구조화. 효과적일 때:

* 답이 지식에 아예 없음 (추가).
* 답 있지만 오래됨 (supersede).
* 답 있지만 잘못 태그됨 (재태그).

Flow 만질 필요 없음 — 순수 데이터 변경.

### 6. 메모리 룰

절차적 룰 추가. 효과적일 때:

* Agent 가 상시 동작 필요 ("Y 전 항상 X").
* 특정 교정이 모든 미래 실행에 적용되어야.

추가 빠름, 제거 쉬움, 배포 불필요 (룰이 즉시 발효).

### 7. 인과 그래프

엣지·변수 추가/조정. 효과적일 때:

* 검증이 오발화 (그래프가 틀림).
* 검증이 실제 에러 못 잡음 (그래프에 엣지 누락).

### 8. 라우팅

다른 인텐트를 다른 Agent 로 보낼 Router 추가. 효과적일 때:

* 단일 Agent 가 너무 많은 것 시도하고 아무것도 잘 못함.
* 인텐트별 비용 프로필이 예리하게 다름 (저렴한 인텐트를 저렴한 모델로 라우팅).

Flow 재구조화하므로 시뮬레이션 필수.

### 9. 가드레일 / 승인

특정 액션에 가드레일이나 승인 게이트 추가. 효과적일 때:

* Agent 가 사람 리뷰 있어야 할 결정 내림.
* 특정 출력이 즉시 블록되어야.

품질 고치지 않음 — 품질 개선되는 동안 손해 방지.

### 10. 모델 스왑

Agent 가 쓰는 모델 변경 (또는 폴백 사용). 효과적일 때:

* 지속적 실패가 모델이 도메인 처리 못함 시사.
* 비용/품질 트레이드오프가 Pareto 프론티어의 다른 모델 가리킴.

가장 큰 레버, 가장 큰 비용/지연 영향. 광범위하게 시뮬레이션.

## Nora 의 레버 선택

각 근본 원인 카테고리에 대해 Nora 가 특정 레버 선호:

* **리트리벌 이슈** → 리트리벌 프리셋 > 데이터 소스 > 프롬프트.
* **프롬프트 이슈** → 프롬프트 > 메모리 룰 > 도구 설명.
* **도구 이슈** → 도구 설명 > 도구 구현 > 프롬프트.
* **데이터 이슈** → 데이터 소스 (추가/태그/supersede) > 다른 것으로 안 고쳐짐.
* **메모리 이슈** → 메모리 룰 > 스코프 설정 > 새 메모리 스페이스.
* **그라운딩 이슈** → 인과 그래프 > 데이터 소스.
* **모델 이슈** → 모델 스왑 > 프롬프트 조임.

순서는 "이 클래스를 그럴듯하게 다룰 가장 저렴한 시도" 반영.

## 수동 레버 선택

Nora 의 기본 오버라이드 가능. **Proposals → Change lever** — 다른 레버 선택하면 Nora 가 그 레버 타겟한 제안 재생성.

자동 진단보다 도메인 잘 알 때 유용. 예: Nora 가 리트리벌 수정 제안하지만 룰이 더 간단할 걸 앎.

## 여러 레버 적용될 때

복잡한 클러스터는 여러 근본 원인과 여러 합리적 레버. Nora 가 레버당 제안 생성하고 어느 조합 출시할지 선택하게 함 (보통 하나면 충분 — 과잉 수정은 회귀 초래).

두 레버 한 번에 출시하면 어느 것이 실제 도왔는지 격리하려면 시뮬레이션 필수.