v0.0.1 후기 포스트 (링크)에서 추후 개발할 내용을 아래처럼 정리했다.
추후 개발할 내용
- 현재는 OpenAI 모델만을 작동 확인. Gemini와 Anthropic 모델의 작동 확인 필요.
- 전체 대화 혹은 특정 기간의 대화 (추천)을 집합적으로 평가하는 대시보드 추가
- 다양한 모델과 집합적 모니터링 대시보드를 통해서 모델별 평가 가능
- Spotify API와 Diversity 등을 통해서 흔하지 않은 노래 추천 기능 향상 도모
- LangSmith의 추적 내용을 streamlit 대시 보드로 통합 가능한지 확인 필요
많은 내용들 중에서 일단, 맨 마지막 부분인
- LangSmith의 추적 내용을 streamlit 대시 보드로 통합 가능한지 확인 필요
을 살펴보았다.
해결과정
목표를 위한 사고 과정은 다음과 같다.
1. LangSmith는 7일이 지나면 tracing 내역이 모두 사라진다. 7일 이상을 보려면 결제를 해야한다.
2. LangFuse 등의 대안들도 살펴보았으나 모두 비용을 요구한다.
3. LangSmith의 내용을 그대로 대시보드에 가져와서 표시하는건 불가능한거 같아서 직접 레이턴시를 측정하기로 했다.
4. 기존의 방식에서는 messages가 누적된 graph의 stream의 맨 마지막 결과만 가져왔다.
하지만 이제는 매 스텝 마다의 stream에 대해서 메시지를 가져오고, 시작시각과 종료시각 그리고 레이턴시를 계산해야 했다.
5. 기본적으로 LangGraph의 prebuilt create_react_agent로 만든 에이전트는 Graph다.
따라서 Subgraph까지 표시할거냐 말거냐는 결정해야 했는데 에이전트 내부의 활동은 개의치 않고, 에이전트 하나의 전체 활동에 대한 레이턴시만 우선 계산하기로 했다.
6. 이때, 대화의 턴 마다 레이턴시를 별도로 계산하기 위해서 따로 대화의 턴을, 전체 대화에 대한 레이턴시를 별도로 표기했다.
LangGraph 구조 시각화
Supervisor Agent로 Web Search Agent와 Load Preference Agent를 제어하는 구조다.
LangGraph의 prebuilt create_react_agent로 만든 에이전트는 Graph임을 표시한다.
여기서는 Web Search Agent를 표시했다.
Data in MongoDB
time_metadata 항목은 stream의 시작, 종료, 레이턴시 (end_time - start_time)로 구성되어있다.
대화는 여러개의 턴으로 구성되는데, 각 턴마다 시간이 얼마나 걸리는지 측정하기 위해서 conversation_start_time, conversation_end_time, conversation_latency를 모두 리스트 형태로 저장했다.
시간 형식의 경우 YYYY-MM-DD HH:MM:SS 등으로 저장할 수도 있지만 유닉스 시간으로 표기했다.
왜냐면 UTC+9이나 이런 표준시간대를 프론트엔드 측에서 알아서 양식을 정해서 뿌려주기 편하게 unix 형식으로 두는게 변환의 측면에서 편하리라 생각했기 때문이다.
유저의 이전 대화를 보여주기 위한 데이터의 경우 conversation_start_time, conversation_end_time, conversation_latency이 추가된 것 되에는 크게 바뀐게 없다.
LLM 성능 평가 대시보드
웹 검색에서 다소 시간이 걸리는 현상을 확인할 수 있다.
추후 개발할 내용
데이터에 있는 response_metadata를 활용하면 input_tokens와 output_tokens를 구할 수 있는데,
이를 활용해서 LLM API의 비용을 대략적으로 계산할 수 있다.
이와 관련된 내용도 대시보드에 추가해야겠다.
LLM의 가격에 대한 Geek News의 Price Per Token (토큰당 가격) – LLM API 가격 데이터 글 (링크)을 보면, 생각보다는 계산이 복합한듯하다. 이것도 직접 예측 비용과 실제 비용을 비교하면서 확인해가야 할듯하다.
회고
어떻게 레이턴시를 계산할지 여러가지를 찾다가 Custom Callback (링크)도 약간 건드려보았다.
출력을 했을 때 아래와 같은 데이터와 유사하게 나오는걸 확인해서 한 번 공부해서 정리해야겠다 싶었다.
현재의 저장된 메시지
{'lc': 1,
'type': 'constructor',
'id': ['langchain', 'schema', 'messages', 'AIMessage'],
'kwargs': {'content': '케이팝 여름 노래 5곡 추천해 드립니다:\n\n1. 태연 - "Why"\n2. 효린, 창모 - "BLUE MOON"\n3. 위너(Winner) - "LOVE ME LOVE ME"\n4. 양다일, 웬디 - "그해 여름"\n5. 쏠(Sole) - "RIDE(feat THAMA)"\n\n이 곡들은 여름에 듣기 좋은 청량하고 시원한 느낌의 케이팝 노래들입니다. 즐겁게 감상하세요!\n\nRECOMMENDATION_COMPLETE',
'additional_kwargs': {'refusal': None},
'response_metadata': {'token_usage': {'completion_tokens': 124,
'prompt_tokens': 1476,
'total_tokens': 1600,
'completion_tokens_details': {'accepted_prediction_tokens': 0,
'audio_tokens': 0,
'reasoning_tokens': 0,
'rejected_prediction_tokens': 0},
'prompt_tokens_details': {'audio_tokens': 0, 'cached_tokens': 0}},
'model_name': 'gpt-4.1-mini-2025-04-14',
'system_fingerprint': 'fp_6f2eabb9a5',
'id': 'chatcmpl-ByiF87ANdxW0ixQkqKjcjyGSgqkxl',
'service_tier': 'default',
'finish_reason': 'stop',
'logprobs': None},
'type': 'ai',
'name': 'supervisor_agent',
'id': 'run--a3aab1a0-679e-425a-876a-ecf6c88762c2-0',
'usage_metadata': {'input_tokens': 1476,
'output_tokens': 124,
'total_tokens': 1600,
'input_token_details': {'audio': 0, 'cache_read': 0},
'output_token_details': {'audio': 0, 'reasoning': 0}},
'tool_calls': [],
'invalid_tool_calls': []}}
Custom Callback 출력 결과 중 일부
여러 가지 콜백 함수가 있는데 start만 살펴보면,
- on_chat_model_start
- on_chain_start
- on_llm_start
- on_tool_start
이 있다.
여기서 on_chat_model, on_chain, on_llm이 무슨 차이인지 더 탐구해봐야겠다.
References:
https://langchain-ai.github.io/langgraph/agents/agents/
https://python.langchain.com/docs/concepts/callbacks/
https://towardsdatascience.com/callbacks-and-pipeline-structures-in-langchain-925aa077227e/
'AI Codes > LangChain & MCP & Agent' 카테고리의 다른 글
| LangGraph에서 비동기 병렬 처리 (0) | 2025.11.04 |
|---|---|
| LLM 에이전트 기반 음악 추천 챗봇 개발 v0.0.3 후기 (2) | 2025.08.13 |
| LLM 에이전트 기반 음악 추천 챗봇 개발 v0.0.1 후기 (1) | 2025.06.25 |
| Agent의 평가와 function calling 관련 글 모음 (1) | 2025.05.28 |
| Multi Agent와 ReAct 관련 글 모음 (0) | 2025.05.28 |
