여기서 작업 흐름이란 실제로 무엇인가
인공지능 영역의 「작업 흐름」 도구 대부분은 얇은 층을 씌운 요청의 사슬입니다. ToRun의 작성기는 유형이 매겨진 단계로 이루어진 방향 있는 비순환 그래프(DAG)입니다. 모델 호출, 도구 호출, 조건 분기, 되풀이, 하위 흐름을 그래프로 잇고, 엔진이 의존 순서대로, 그래프가 허락하는 곳에서는 나란히 실행합니다.
각 단계는 자기 설정을 갖춘 온전한 개체입니다. 단계 종류(LLM 호출, 웹 검색, 코드 실행, 이미지 생성, 되찾기, 변환 등), 입력 도식, 오류 방침(빨리 실패, 기다렸다 다시 시도, 대안으로 이동), 단계별 실행 예산 상한, 시간 제한.
각 LLM 단계 안의 모델 배분은 ToRun의 다른 모든 것과 같은 역량 통로를 지납니다. 필요한 바를 선언하면——구조화된 출력, 시각, 도구 사용, 추론, 적어도 N 토큰의 맥락 창——실행기가 그때 쓸 수 있는 공급자 가운데 가장 알맞은 모델을 정합니다. 즐겨 쓰는 공급자가 5xx를 돌려주면 대체 사슬이 자동으로 이어받습니다.
품질 우선의 실행기와 그것이 실무에서 바꾸는 것
작업 흐름을 돌릴 때, 실행기는 가장 싼 선택이 아니라 품질 등급의 모델을 일부러 고릅니다. 두 가지 이유입니다. 자동화는 아무도 곧바로 살피지 않는 산물(보고서, 생성된 내용, 코드)을 만들어 품질의 흠이 조용히 쌓입니다. 그리고 중간 정도의 양에서는 비용 차이가, 다시 돌리거나 손으로 고치게 만드는 나쁜 출력의 값보다 작습니다.
실무에서는 「조사를 간추리고 보고서를 쓴다」는 작업 흐름이 가격의 바닥으로 달리는 대신 간추림에는 든든한 추론 모델을, 집필에는 질 좋은 문장 모델을 고른다는 뜻입니다. 거기엔 가벼운 모델로 충분하다는 것을 안다면 단계별로 덮어쓸 수 있습니다.
청구는 ToRun의 나머지를 따릅니다. 작업 흐름 안의 각 모델 호출은 얼려 둔 단가 스냅숏과 함께 정확히 한 건의 기록을 씁니다. 다섯 단계에서 세 가지 모델을 부르는 실행은 다섯 건의 기록을 냅니다. 각 실행의 정확한 비용을 단계별 내역으로 나중에도 확인할 수 있습니다——공급자의 값이 이미 움직인 몇 달 뒤라도.
실행을 살피기
모든 작업 흐름 실행은 구조화된 자취를 남깁니다. 자취는 그래프를 보이며 마디마다 주석을 답니다. 시작 시각, 끝난 시각, 정해진 모델, 입력과 출력의 토큰 수, 이루어진 도구 호출, 그리고 오류가 있었다면 그것도. LLM 단계에서는 보낸 요청 그대로와 받은 날것의 응답을 펼쳐 볼 수 있습니다.
단계가 실패하면, 자취는 오류가 모델 호출에서 왔는지(공급자 오류, 맥락 넘침, 내용 방침에 따른 거절), 뒤쪽 도구에서 왔는지(연결 시간 초과, 도식 검사 실패), 아니면 당신의 조건 논리에서 왔는지 일러 줍니다. 기록을 덧붙일 필요가 없습니다. 실행마다 기반 수준에서 잡힙니다.
어떤 실행이든 같은 입력으로 되풀이할 수 있어, 장애를 되살리기가 수월합니다.
작은 보기: 주간 경쟁 파악 작업 흐름
매주 월요일 아침에 돌리는 작업 흐름을 그려 보십시오.
- 웹 검색 단계——경쟁사 낱말 묶음에 대한 최근 보도를 찾아 주소와 발췌의 목록을 돌려줍니다.
- 되찾기 단계——지식 기반에서 최근 보고서 네 건을 끌어와 출발 맥락을 세웁니다.
- 간추림 단계(LLM)——검색 결과를 구조화된 소견으로 졸입니다. 새 기능, 가격 변화, 눈에 띄는 발표.
- 집필 단계(LLM)——간추린 소견에 뿌리를 두고, 한결같은 사내 문체로 간결한 내부 각서를 씁니다.
- 전달 단계——각서를 설정된 웹훅 종단으로 보냅니다.
그래프에는 자연스러운 의존이 있습니다. 3단계는 1과 2에 기대고(둘은 나란히 돌 수 있습니다), 4단계는 3에, 5단계는 4에 기댑니다. 실행기는 병행 설정을 따로 밝히지 않아도 이렇게 합니다. 변을 읽기 때문입니다.