Skip to main content
피드백 메서드는 둘, 둘 다 그 Flow의 트리거 시크릿으로 인증합니다. 의도가 다릅니다. 섞지 마세요.

feedback(traceId, {...})

답 자체에 대한 평가: 👍 / 👎, 코멘트, before → after 정정. 기존 end-user 피드백 엔드포인트를 앱에서 그대로 전달하도록 노출한 것입니다.
  • dislike는 그 트레이스의 확정 human 신호로 승격됩니다.
  • like는 그 트레이스에 붙어 있던 미결 신호를 회수합니다.
traces.feedback 별칭도 있습니다. 같은 호출이고, 스펙의 정식 이름입니다.
옵션:
  • rating (필수) "like" 또는 "dislike".
  • comment 자유 텍스트. 트레이스와 군집 검수에 노출됩니다.
  • correction { before, after } 짝. after는 사용자가 답이 어떻게 되었어야 한다고 말한 것. 개선 루프에 candidate fix 내용으로 들어갑니다.

signals.report(traceId, {...})

답 품질 탐지기가 볼 수 없는 외부 결과: 환불됨, 재오픈, 상담사 개입, 해결됨. candidate 신호origin=sdk_report를 달고 들어가 탐지 신호와 같은 군집/데이터셋 경로를 탑니다.
옵션:
  • outcome (필수) 자유 문자열. 흔한 어휘: resolved, reopened, escalated, refunded, abandoned. 한 세트로 정하고 일관되게 쓰세요. 그게 군집이 묶이는 축입니다.
  • reason 자유 텍스트.

왜 둘을 분리하나

feedbacksignals.report를 섞으면 탐지기와 군집이 시끄러워집니다.
  • feedback답이 옳았는지를 말합니다. 답 품질 지표에 실립니다.
  • signals.report다운스트림에서 실제로 무슨 일이 있었는지를 말합니다. 결과 지표와, 답 품질 탐지기가 놓친 실패를 드러냅니다.
기술적으로 옳은 답(👍 feedback)인데도 사용자가 이탈하는(escalated 신호) 일이 있습니다. 둘 다 담아야 하고, 서로 다른 트랙에 실려야 합니다.

traceId는 어디서 오나

  • flows.run 반환값 r.traceId. 기본값이고, 그 자리에서 씁니다.
  • 앱 로그 나중에 로그에 남긴 traceId로 피드백을 붙여도 됩니다.
  • newTraceRef 상관관계 실행 전 앱 로그에 상관 id를 심어 둘 때.

MCP · CLI로 같은 일

MCP 툴과 CLI로 같은 작업이 됩니다.
전체 CLI 모양은 nora feedback을 참고하세요.