'팀 단위 AI 업무 혁신' 자문 관련하여 문의드리고자 합니다. (연락처 요청)

안녕하세요 과장님, 아쉽지만 회사 정책 상 외부 자문이 불가능해서 도움을 드릴 수 없습니다.

uv sync 파이썬 버전문제 onnxruntime

공유 감사합니다!

🚨 python3.14 를 쓰고 계시면 chroma 에서 ConfigError 가 발생합니다.

좋은 내용 공유해주셔서 감사합니다! 자주 묻는 질문에 등록해두었습니다

n8n Self-signed Certificate in certificate chain 이슈

안녕하세요, localhost라 연동이 안되는 걸 수도 있는데 (포트 등 이슈) 아래처럼 시도해보시겠어요?sudo docker run -it --rm -d \ --name n8n \ -p 5678:443 \ -e N8N_PROTOCOL=https \ -e N8N_HOST= \ -e N8N_PORT=443 \ -v n8n_data:/home/node/.n8n \ docker.n8n.io/n8nio/n8n

🚨 OpenAI 유료계정인데 할당량 초과인 경우!!

공유 감사합니다!

MCP를 활용해서 간단한 에이전트를 만들어보세요

안녕하세요! 강의를 수강해주셔서 감사합니다. 다른 수강생분들이 작업하신 예제들을 보여드릴 수는 없고, 외부 MCP들을 모아둔 사이트에서 한번 보시고 만들어 볼만한 것들을 찾아보시는 걸 추천 드립니다https://github.com/modelcontextprotocol/servers?tab=readme-ov-file

PDF 형식

안녕하세요! 좋은 질문 감사합니다. 파일 안에 사진이 있는 경우에는, 경험상 비용이 발생하긴 하지만 Upstage의 Document API를 활용하는게 가장 좋은 선택입니다. 다른 대안이 있을 수도 있는데 저는 다른 방법은 시도해보지 않았습니다. 다만 Upstage의 Document API도 사진을 분석해주지는 않고, 아래 방식으로 진행하셔야 합니다. pdf 파일을 분석해서 사진의 위치를 알려주는데요(좌표 포함), 해당 영역을 코드로 잘라서 별도로 사진 파일로 저장한 다음에 사진 인식이 가능한 AI를 활용해서 사진의 설명을 생성하고 사진의 설명을 임베딩하는 방식입니다 제가 시도해봤던 방법들 중에서는 가장 효과가 좋았습니다.

문서 전처리 고민

안녕하세요, 좋은 질문 감사합니다. RAG의 핵심은 데이터를 어떻게 잘 전달하느냐 인데요, 질문하신 내용에 답변을 드려보자면마크다운 형식으로 간다면 유지하는 편이 좋습니다. 1.2 , 1.2.1 과 같은 구분이 문서의 형식을 나타내기 때문에 남겨두는 편이 좋습니다. 아래처럼 수정해주시면 더 좋습니다 ## 1.2 화면 설명 ### 1.2.1 개요 - 이 화면은 사용자가 업무를 처리하기 위한 화면입니다. ### 1.2.2 화면 위치 상단 메뉴 > 업무 관리 > 처리 화면 ### 1.2.3 처리 절차 1) 항목 선택 2) 저장 버튼 클릭 그리고 이런식으로 가능하시다면 더 좋습니다 ## 1.2 화면 설명 ### 1.2.1 개요 - 이 화면은 사용자가 업무를 처리하기 위한 화면입니다. ## 1.2 화면 설명 ### 1.2.2 화면 위치 상단 메뉴 > 업무 관리 > 처리 화면 ## 1.2 화면 설명 ### 1.2.3 처리 절차 1) 항목 선택 2) 저장 버튼 클릭 1.2.2와 1.2.3에 1.2의 내용을 넣어주면서, 어떤 화면에 대한 내용인지를 부연설명해서 더 좋은 context를 전달할 수 있습니다.- 와 같은 기호는 남겨두는 편이 좋습니다. 일반 줄글로는 텍스트들의 관계를 쉽게 파악할 수 없기 때문입니다.상단 메뉴 > 업무 관리 > 처리 화면의 경우에는 처리 순서의 depth를 확인할 수 있지만상단 메뉴 업무 관리 처리 화면이렇게 보면 어떤 관계가 있는지 알 수 없기 때문입니다1, 2 번에서 답변이 되었을 것 같은데요, 추가하시는 방향을 추천 드립니다

강의와 책 관련 질문

안녕하세요! 책에 관심 보여주셔서 감사합니다 PART II LangChain을 활용한 RAG 파이프라인 구성하기 가 강의 내용과 맞는 부분이라고 보시면 됩니다

3.6 human_in_the_loop 3rd case

안녕하세요! 좋은 질문 감사합니다.TL;DR핵심부터 말씀드리면, case 3(update_tool)은 "도구 자체를 바꾸는 것"이 아니라 "도구 호출을 건너뛰고, 사람이 직접 도구 결과를 제공하는 것"입니다.코드를 다시 보시면:if review_action == 'update_tool': updated_tool_message = { 'tool_call_id': tool_call['id'], 'name': tool_call['name'], 'role': 'tool', 'content': review_data # 사람이 직접 제공하는 "결과값" } return Command(goto='agent', update={'messages': [updated_tool_message]})여기서 두 가지를 확인할 수 있는데요goto='agent'tools 노드가 아니라 바로 agent로 갑니다. 즉, 실제로 도구를 실행하지 않습니다.role: 'tool'인 메시지를 직접 만들어서 삽입을 하게 되는데, 마치 도구가 실행된 것처럼 LLM에게 결과를 전달하는 가짜 ToolMessage입니다.이 패턴의 의도는 이렇습니다: AI가 잘못된 도구를 선택했을 때, 사람이 "이 도구 말고 웹에서 검색해줘"라고 자연어로 피드백을 주면, 그 피드백 자체가 ToolMessage의 content로 들어가서 agent가 다시 판단할 수 있게 되는 것입니다.실제 예시에서도 확인할 수 있습니다:Command(resume={"action": "update_tool", "data": "arxiv말고 web에서 검색해주세요"})여기서 arxiv말고 web에서 검색해주세요 라는 문자열이 ToolMessage의 content가 되어 agent에게 전달되고, agent는 이를 보고 다음에 duckduckgo_search를 호출하게 됩니다. 그러면 질문하신 것처럼 ai_message의 tool_calls에서 tool name을 직접 바꾸면 안 되는 것인지 의문이 들 수 있는데요,기술적으로 가능은 하지만, 실용적으로 문제가 있습니다:tool_name을 바꾸면 args도 함께 바꿔야 합니다. 각 도구마다 파라미터 스키마가 다르기 때문입니다. 강의에서 진행한 케이스의 경우 arxiv 도구와 duckduckgo_search 도구의 인자 형식이 동일한데요(모두 query를 사용함), 만약 스키마가 다른 경우에는 에러가 발생합니다.사람이 도구 이름과 정확한 인자까지 알아서 지정해야 하므로 human-in-the-loop의 편의성이 크게 떨어집니다.반면 case 3 방식은 사람이 자연어로 피드백만 주면, agent(LLM)가 알아서 적절한 도구와 인자를 다시 선택하므로 훨씬 유연합니다.