주방의 악몽: LangChain 에이전트 편

레시피를 분석하고 식단 계획을 세워주는 건강 앱을 만들었습니다.

웹 앱에는 FastAPI와 React를 사용했습니다. 에이전트에는 LangChain을 사용했고, 에이전트가 무엇을 하고 있는지 확인하기 위해 LangSmith를 사용했습니다.

목표는 간단했습니다. 사용자가 URL을 제공하면, 앱이 레시피를 가져와 메인 요리, 사이드 메뉴, 소스와 같은 구성 요소로 나눕니다. 그런 다음 사용자는 이를 조합하여 식사를 구성하거나 칼로리를 추적할 수 있습니다.

에이전트의 신뢰성 문제라는 큰 난관에 부딪혔습니다.

처음에는 레시피를 그룹화하고 출력을 형식화하는 데 하나의 에이전트만 사용했습니다. 하지만 계속 실패했습니다. 항목이 중복되거나, 조리법이 누락되거나, 모든 내용을 하나의 거대한 덩어리로 합쳐버리곤 했습니다.

이를 해결하기 위해 듀얼 에이전트 설정을 시도했습니다:

• 에이전트 1 (Grouping): 다양한 레시피 구성 요소를 찾고 재료와 조리법을 정리합니다.
• 에이전트 2 (Structuring): 정리된 텍스트를 가져와 깔끔한 JSON 형식으로 변환합니다.

하루는 잘 작동했습니다. 하지만 다음 날 에러가 다시 발생했습니다. 구조화(structuring) 에이전트가 재료와 조리법이 모두 누락된 JSON을 반환하기 시작한 것입니다.

print 문 사용을 중단하고 LangSmith를 사용하기 시작했습니다.

LangSmith는 지연 시간(latency), 토큰 사용량, 비용을 보여줍니다. 무엇보다 중요한 점은 체인이 정확히 어느 부분에서 끊어지는지 보여준다는 것입니다.

제 경우, 그룹화(grouping) 에이전트는 완벽하게 작동하고 있었습니다. 모든 세부 사항이 포함된 훌륭한 markdown을 생성했습니다. 문제는 두 번째 에이전트에서 발생했습니다. 변환 과정에서 데이터를 유실하고 있었습니다.

현재 세 가지 해결책을 작업 중입니다:

• 에이전트 신뢰성 향상: 구조화 에이전트가 원래 프롬프트에 없던 요리 종류(cuisine) 필드를 추측하려 한다는 것을 발견했습니다. 이러한 혼란이 에러를 유발합니다.
• 검증(validation) 추가: Python 함수를 사용하여 출력을 확인하겠습니다. markdown이 정확하고 중복이 없는지 확인하고 싶습니다.
• 관측성(observability) 개선: 더 쉬운 추적을 위해 모든 에이전트 실행을 특정 사용자 요청과 연결하고 싶습니다.

에이전트를 활용한 개발은 한 번에 끝나는 작업이 아닙니다. 테스트와 수정의 끊임없는 반복입니다.

Source: https://dev.to/kristianroopnarine/kitchen-nightmares-langchain-agents-edition-45co

Optional learning community: https://t.me/GyaanSetuAi