지식 기반에 내용을 작성하는 LlamaIndex 에이전트는 먼저 인간의 검토를 거쳐야 합니다. 어떤 페이지든 덮어쓰기 전에 Impri로 게시 단계를 게이트(gate)해야 합니다.

에이전트적 RAG가 쓰기를 원할 때

대부분의 LlamaIndex 에이전트는 읽기 전용(read-only)입니다. 인덱스에서 청크를 검색하여 질문에 답하는 식이죠. 만약 같은 에이전트에게 위키 페이지 업데이트, 오래된 매뉴얼 수정, Confluence 문서 패치 등 _쓰기_가 가능한 도구(tool)를 제공한다면, 검색 부분은 안전하게 유지되지만 쓰기 부분에는 게이트가 필요합니다. 에이전트가 문서가 잘못되었다는 것을 인지하는 것은 유용하지만, 아무도 모르게 덮어쓰는 것은 그렇지 않습니다.

구체적인 예시로, 내부 위키를 대상으로 하는 지원 문서(support-docs) 에이전트를 생각해 봅시다. 사용자가 질문을 했을 때 에이전트가 일치하는 페이지가 오래되었다고 판단하면, 스스로 판단하여 진실의 원본 소스 위에 게시하는 것이 아니라 수정 초안을 작성하여 인간에게 전달해야 합니다.

FunctionTool로 쓰기 기능을 게이트하기

기존 검색 도구는 제한 없이 사용하도록 유지합니다. 읽기는 부작용(side effect)이 없으니까요. 그리고 변경 사항을 제안하는 역할만 하는 두 번째 도구를 추가합니다. '제안(propose) → 확인(poll) → 게시(publish)' 순서는 Impri에서 사용되는 것과 동일하며, 여기서는 LlamaIndex.TS를 위해 TypeScript로 래핑되었습니다:

import { FunctionTool, OpenAIAgent } from "llamaindex";

const IMPRI_BASE = "https://api.impri.dev";
...

여기서는 `editable: [

POST /v1/actions/:id/result의 payload 필드가 '승인됨(approved)'을 영수증으로 만듭니다. 여기에는 게시된 페이지의 ID, URL 및 새 개정 번호가 포함되며 — 이 세 가지 정보는 Impri 카드에 표시되고 GET /v1/actions/:id를 통해 result_payload로 반환됩니다. 이것이 없으면 업데이트가 승인되었다는 것은 알겠지만, 결과 페이지를 직접 찾아야 합니다.

검색과 작성은 별도의 도구로 유지하세요

신중하게 고려해야 할 몇 가지 사항:

• 검색을 제한하지 마세요(Don't gate retrieval). 읽기 전용 검색 도구를 동일한 흐름에 묶으면 모든 질문의 지연 시간(latency)이 늘어나고 검토자들이 카드 승인만 하도록 훈련시킵니다.
• 짧은 만료 기간 대신 긴 만료 기간을 사용하세요. 위키 수정은 환불이나 사고 대응처럼 시간 민감한 것이 아니므로, '몇 시간 내에 검토'를 강요하는 것보다 3일이 더 좋습니다.
• 부작용(side effect)당 하나의 작성 도구를 사용하세요. 에이전트에게