포럼 리서처 AI 에이전트 가이드

:bookmark: 이 가이드는 Discourse AI의 포럼 리서처(Forum Researcher) 에이전트, 그 작동 방식, 그리고 포럼 콘텐츠 심층 분석을 위한 설정 방법을 설명합니다.

:person_raising_hand: 필요한 사용자 권한: 관리자 (활성화 및 설정을 위해), 모든 사용자 (액세스가 부여된 경우 상호작용을 위해)

포럼 리서처 에이전트 이해 및 사용

Discourse AI 플러그인에는 포럼 리서처(Forum Researcher) 에이전트가 포함되어 있습니다. 이는 포럼 내 콘텐츠에 대한 심층적인 연구를 수행하도록 설계된 강력한 도구입니다. 이 에이전트는 인사이트를 발굴하고, 토론을 요약하며, 커뮤니티 전반의 트렌드를 분석하는 데 도움이 될 수 있습니다.

요약

이 문서에서는 다음 내용을 다룹니다:

  • 포럼 리서처 에이전트의 작동 방식.
  • 포럼 리서처 설정 단계.
  • 에이전트와의 상호작용에 대한 모범 사례.
  • 포럼 리서처와 표준 포럼 헬퍼 도구 간의 차이점.
  • 적절한 대규모 언어 모델(LLM) 선택에 대한 안내.
  • 연구 작업에 대한 디버깅 팁.
  • 에이전트의 현재 한계.

작동 방식

포럼 리서처 에이전트는 전용 리서처(Researcher) 도구를 사용합니다. 이 도구는 다음과 같은 목적으로 설계되었습니다:

  1. 포럼 콘텐츠 접근: 포럼의 다양한 섹션을 읽을 수 있습니다.
  2. 고급 필터 적용: 유연한 필터 시스템을 통해 관련 정보를 정확하게 대상화할 수 있습니다. 다음 기준으로 콘텐츠를 지정할 수 있습니다:
    • 특정 카테고리 (예: category:support 또는 categories:support,feedback)
    • 태그 (예: tag:bug 또는 tags:bug,regression)
    • 사용자 또는 그룹 (예: username:sam, usernames:sam,jane, group:moderators, groups:moderators,admins)
    • 게시물 또는 주제 제목의 키워드 (예: keywords:regression,bug, topic_keywords:feature,request)
    • 게시물 날짜 범위 (예: after:2024-01-01 before:2024-06-30)
    • 주제 날짜 범위 (예: topic_after:2024-01-01 topic_before:2024-06-30)
    • ID로 특정 주제 (예: topic:123 또는 topics:123,456)
    • 주제 상태 (예: status:open, status:closed, status:archived, status:noreplies, status:single_user)
    • 게시물 유형 (예: post_type:first, post_type:reply)
    • 정렬 순서 (예: order:latest, order:oldest, order:latest_topic, order:oldest_topic, order:likes)
    • 인라인 결과 제한 (예: max_results:50)
    • 할당된 주제 (Assign 플러그인이 활성화된 경우, 예: assigned_to:username, assigned_to:user1,user2, assigned_to:*, assigned_to:nobody)
    • 필터는 AND 논리(공백으로 구분) 또는 OR 논리(필터 그룹 사이에 OR 사용)로 결합할 수 있습니다. 예: category:bugs status:open after:2024-05-01 OR tag:critical usernames:sally.
  3. 대규모 언어 모델(LLM)을 활용한 콘텐츠 분석: 필터링된 콘텐츠를 가져온 후, LLM을 사용하여 정보를 분석하고, 인사이트를 추출하며, 사용자의 특정 질문에 답하거나 연구 목표를 달성합니다.
  4. 구조화된 프로세스 준수: 특히 잠재적 비용을 고려하여 효율성과 정확성을 보장하기 위해, 포럼 리서처는 다음과 같이 설계되었습니다:
    • 이해(Understand): 처음에 연구 목표를 명확히 하기 위해 사용자와 함께 작업합니다.
    • 계획(Plan): 사용자의 목표에 기반하여 사용 가능한 필터를 활용하여 포괄적인 연구 접근법을 설계합니다.
    • 테스트(Dry Run): 전체 분석을 실행하기 전에, 에이전트는 일반적으로 "드라이 런(dry run)"을 수행합니다. 이는 LLM으로 즉시 처리하지 않고 필터 기준에 해당하는 게시물의 수를 계산하는 것입니다. 이후 에이전트는 이 수를 사용자에게 알려줍니다.
    • 정제(Refine): 드라이 런 결과에 기반하여, 게시물이 너무 많을 경우(높은 비용 또는 과도하게 광범위한 결과의 위험) 또는 너무 적을 경우(주요 정보 누락 가능성) 에이전트는 필터를 조정하는 데 도움을 줄 수 있습니다.
    • 실행(Execute): 드라이 런 후 범위가 적절하다고 확인되면, 에이전트는 콘텐츠를 LLM으로 전송하여 최종 분석을 실행합니다.
    • 요약(Summarize): 결과를 제시하며, 일반적으로 Discourse 마크다운을 사용하고, 원본 포럼 게시물 및 주제로의 링크를 보조 증거로 포함합니다.

이러한 체계적인 접근 방식 덕분에 리서처에게 다음과 같은 작업을 요청할 수 있습니다:

  • “지난 분기에 ‘mobile-app’ 카테고리에서 가장 자주 논의된 미해결 버그를 요약하고, 토론에서 언급된 제안된 해결책 또는 우회 방법을 식별해 주세요.”
  • “‘New User Onboarding’ 제안 주제(링크)에 대한 주요 찬반 논거를 식별하고, 각 측의 주요 지지자들을 나열해 주세요.”
  • “지난 1년간 ‘documentation-team’ 그룹의 활동을 검토하고, how-to 게시물에 대한 주요 기여에 대한 보고서를 제공하며, 상당한 긍정적 피드백을 받은 튜토리얼을 강조해 주세요.”

포럼 리서처 설정

포럼 리서처는 사용 시 LLM 비용이 발생할 수 있으므로 기본적으로 비활성화되어 있습니다.

  1. 에이전트 활성화: Admin → AI → Agents로 이동하여 활성화합니다.
  2. 액세스 제어: LLM 비용을 관리하기 위해 이 에이전트를 특정 그룹으로 제한하는 것이 강력히 권장됩니다. 더 세밀한 제어를 위해 AI 할당량(AI quotas)을 사용할 수도 있습니다.

활성화되면, 이 도구는 여러 가지 설정 옵션을 제공합니다:

  • LLM: 연구를 위한 특정 LLM을 선택합니다. 기본값은 현재 에이전트의 LLM입니다. 이 옵션을 통해 품질과 비용을 균형 잡을 수 있습니다.
  • 최대 결과 수: 비용을 제어하기 위해 쿼리당 처리할 게시물 수를 제한합니다. 기본값은 1000입니다.
  • 비공개 포함: 상호작용하는 사용자의 권한을 사용하여 보안 카테고리에서 검색할 수 있게 합니다.
  • 게시물당 최대 토큰 수: 토큰 비용을 절약하기 위해 긴 게시물을 잘라냅니다. 기본값은 2000 토큰이며, 최소값은 50입니다.
  • 배치당 최대 토큰 수: LLM으로 전송되는 데이터 청크 크기를 제어합니다. 큰 컨텍스트 윈도우를 가진 LLM에 유용하거나 집중력을 유지하는 데 도움이 됩니다. 8000 이하로 설정되면, LLM의 최대 프롬프트 토큰에서 2000 토큰 버퍼를 뺀 값으로 기본 설정됩니다.

상호작용 모범 사례

비용을 관리하면서 포럼 리서처를 최대한 활용하려면:

  • 목표를 구체적으로 명시하세요: 시작 이전에 무엇을 알고 싶은지 명확히 정의하세요. 에이전트는 정확한 목표가 있을 때 가장 잘 작동합니다.
  • 드라이 런 후 범위 확인: 에이전트는 일반적으로 먼저 '드라이 런’을 수행하고 요청에 기반하여 발견한 게시물 수를 알려줍니다. 이 숫자에 주의를 기울이세요. 너무 높으면(높은 비용 또는 초점이 흐려진 결과의 위험) 또는 너무 낮으면(중요한 정보 누락 가능성), 전체 분석을 실행하기 전에 에이전트와 필터를 정제하는 것에 대해 논의하세요.
  • 필터 반복 조정: 초기 드라이 런이 올바른 정보를 대상으로 하지 않는다면, 에이전트와 함께 필터 기준을 조정하세요. 더 구체적인 키워드를 추가하거나, 날짜 범위를 좁히거나, 카테고리/태그를 지정하세요.
  • 쿼리 통합: 에이전트는 단일 연구 실행에서 여러 관련 목표를 처리하도록 설계되었습니다. 관련 질문을 하나의 포괄적인 연구 요청으로 그룹화해 보세요.

표준 포럼 헬퍼 및 관련 도구와의 관계

포럼 리서처 에이전트는 SearchRead와 같은 표준 도구를 사용하는 일반 포럼 헬퍼와 구별됩니다.

  • 표준 SearchRead 도구:

    • Search 도구는 주로 관련 주제를 식별합니다. 이는 게시물 콘텐츠 및 기타 기준(태그, 카테고리 등)과 키워드를 일치시켜 수행됩니다. 각 일치하는 주제에 대해, 전체 게시물 콘텐츠가 아닌 관련 게시물에서 가져온 링크와 짧은 스니펫을 반환합니다.
    • Read 도구는 Search가 식별한 특정 주제(또는 그 안의 선택된 게시물)의 전체 콘텐츠에 액세스하는 데 사용됩니다.
    • 이러한 도구는 대상적인 검색을 위해 함께 작동합니다: Search는 주제를 찾고, Read는 그 내용을 소화합니다.
  • 포럼 리서처의 researcher 도구:

    • 직접적이고 심층적인 콘텐츠 분석: researcher 도구는 주제를 식별하는 것뿐만 아니라, 포괄적인 필터 기준에 해당하는 여러 게시물의 전체 콘텐츠(설정된 최대 결과 수까지)를 직접 처리하고 분석합니다.
    • 고급 필터링 및 종합: 포럼 전체에서(수백 개의 주제에 걸쳐) 게시물의 데이터셋을 구축하기 위해 더 복잡한 필터링 언어를 사용하고, 이 전체 데이터셋에서 정보를 종합하여 복잡한 질문에 답합니다. 이는 개별 주제를 하나씩 읽는 것과 근본적으로 다릅니다.

요약하자면, 포럼 헬퍼가 Search를 사용하여 주제를 특정하고(스니펫을 표시) Read를 사용하여 하나를 깊이 파고드는 반면, 포럼 리서처는 더 깊고 종합적인 인사이트를 발굴하기 위해 여러 게시물의 실제 텍스트에 걸쳐 광범위한 분석을 동시에 수행합니다.

어떤 LLM을 사용해야 하나요?

LLM 기술은 빠르게 발전하고 있으며, 모델들은 기능과 비용 효율성 면에서 지속적으로 개선되고 있습니다. 포럼 리서처 개발 동안, Gemini 2.5 Flash, Gemini 2.5 Pro, GPT-4.1, Claude 4 Sonnet과 같은 모델들은 복잡한 연구 계획에 대해 훌륭한 결과를 제공했습니다.

최선의 선택은 사용자의 특정 필요에 따라 달라집니다:

  • 고품질, 세심한 분석: 더 고급 모델이 선호될 수 있지만, 일반적으로 더 높은 비용이 수반됩니다.
  • 광범위한 개요 또는 비용 민감형 작업: 더 빠르고 경제적인 모델이 매우 효과적일 수 있습니다.

다음은 Discourse 내부 테스트에서 매우 구체적이고 복잡한 쿼리에 대한 시점별 예시입니다:

기능 카테고리의 상위 1000개 열린 주제를 살펴보세요 - 좋아요 순서(첫 게시물만) - 모든 기간 … 다음에 대한 경영진 보고서를 작성해 주세요:

  • CDCK가 구축해야 할 상위 20개 기능
  • CDCK가 가장 쉽게 구축할 수 있는 20개 기능
  • 명백한 중복 항목
  • 정의가 매우 불분명한 항목

더 이상 질문하지 말고, 연구를 실행해 주세요

  1. Gemini 2.0 Flash 예시
  2. Gemini 2.5 Flash (thinking 포함) 예시
  3. GPT-4.1 예시
  4. Claude 4 Sonnet 예시
  5. Gemini 2.5 Pro 예시

하이브리드 예시: 드라이버는 Gemini 2.5 Pro, 리서처 LLM은 Gemini 2.0 Flash
하이브리드 예시

연구 디버깅

Discourse에서는 ai_bot_debugging_allowed_groups 사이트 설정에 그룹을 추가하여 고급 AI 디버깅을 활성화할 수 있습니다. 이렇게 하면 LLM으로 전송되는 실제 페이로드를 볼 수 있습니다.

한계

현재 연구 LLM에 이미지를 전송하는 옵션은 없습니다. 이는 향후 버전에서 고려될 것입니다.

FAQ

  • 포럼 리서처는 모든 Discourse 플랜에서 사용 가능한가요?
    포럼 리서처는 Discourse AI 플러그인의 일부이며, 셀프 호스팅 사이트와 Enterprise 호스팅 플랜에서 사용할 수 있습니다.

  • 포럼 리서처가 보안 카테고리의 콘텐츠에 액세스할 수 있나요?
    네, 설정에서 “비공개 포함” 옵션이 활성화되어 있고 에이전트와 상호작용하는 사용자가 해당 카테고리에 액세스할 권한이 있는 경우 가능합니다.

  • 포럼 리서처 사용 비용을 어떻게 제어할 수 있나요?

    • 액세스를 특정 신뢰할 수 있는 그룹으로 제한합니다.
    • “최대 결과 수” 및 “게시물당 최대 토큰 수” 설정을 사용하여 처리를 제한합니다.
    • 비용 효율적인 LLM을 선택합니다.
    • 전체 연구를 실행하기 전에 “드라이 런” 추정치에 주의를 기울입니다.
    • AI 할당량을 활용합니다.

추가 자료

18개의 좋아요

sam 좋은 작업이었고, Discourse AI 페르소나의 꾸준한 진행에 진심으로 감사드립니다. 정말 인상적인 작업입니다.

여러 페르소나가 활성화되면, 작성자(composer)의 드롭다운 메뉴가 사용자에게 혼란스럽고 복잡하게 느껴질 수 있습니다. 몇 가지 조언을 구하고 싶습니다:

  • 사용자가 선택할 수 있도록 드롭다운에 여러 페르소나를 포함하는 것이 올바른 사용 방법인가요?

  • 기본(default) 페르소나가 백그라운드에서 전문화된 페르소나를 호출할 수 있나요?

  • 권한을 통해 가시성을 제어하여, 헬퍼 페르소나가 일반 사용자에게 숨겨진 채 자동화(automation)와 함께 사용되도록 하면 여러 응답 게시글이 생성되는 문제가 발생할 것 같습니다. 이러한 페르소나를 도구로 활용할 수 있다면 좋겠습니다.

구성 팁이나 배포 가이드라인 예시가 있다면 도움이 될 것입니다.

2개의 좋아요

안녕하세요,

우선, 정말 훌륭한 작업이었습니다! 포럼에 있는 모든 지식을 큐레이션할 수 있게 되어 정말 기다리고 있던 기능이었어요.

작은 문제 하나를 발견했습니다:

  • 저희 포럼은 독일어로 운영되고 있는데, 때때로 LLM이 이렇게 „보이는“ 독일식 따옴표를 사용하여 검색을 시도하는 경우가 있었습니다. 이로 인해 검색 결과가 비어 있는 문제가 발생하고 있습니다.
1개의 좋아요

어떤 LLM을 사용 중이신가요? 페르소나를 복사하고 힌트를 포함하여 시스템 프롬프트를 독일어로 다시 작성해 보시는 것도 좋을 수 있습니다.

사실 저는 이미 그 작업을 수행했고, 심지어 추가 지시 사항까지 부여했습니다:

- 포럼에서 정교한 검색 매개변수를 사용할 경우, ``"`` 인클레이션을 사용해야 하며 ``„“`` 인클레이션을 사용하면 안 됩니다.

하지만 문제는 여전히 지속되고 있습니다. GPT 4.1에서는 항상 발생하고, Gemini 2.5 Pro와 Flash에서는 간헐적으로 발생합니다.

참고로 topic_keywords:keywords: 매개변수를 사용하는 방법에 대한 더 자세한 정보를 어디서 찾을 수 있을까요? 메타 포럼이나 ask.discourse.com에서도 관련 정보를 찾지 못했습니다. LLM이 수행하려는 검색을 직접 재현해 보고 싶습니다. 포럼 검색(현재 3.5.0.beta8-dev 버전 사용 중)에서 이 매개변수들을 사용할 때 검색 결과가 전혀 나오지 않습니다.

gemini 2.5 researcher에서 이상한 동작을 발견했습니다:

LLM 응답:

이제 이 내용과 기타 기여물로부터 정보를 정리하여 균주 설명을 작성하겠습니다. 잠시 시간이 걸릴 것입니다. 완료되면 다시 연락드리겠습니다.

하지만 실제로는 응답이 여기서 끝나며, 계속 진행하려면 수동으로 다시 트리거해야 합니다.

이것이 레이트 리미트(rate limit) 때문일 수 있을까요?

리서처 페르소나는 Discourse 코어 검색 구현을 사용하지 않고 사용자 정의 구현을 사용합니다. 이 구현은 파싱된 후 전체 텍스트 검색을 직접 호출합니다.

아, 이제 알겠어요. 프롬프트를 통해 검색 동작을 더 세밀하게 제어할 수 있도록, 커스텀 검색 구현에 대한 문서가 조금 더 있었으면 좋겠네요.

1개의 좋아요

이것은 1000% LLM의 환각(hallucination)입니다.

학습 데이터 코퍼스에서는 이것이 “흔한” 응답이므로, 주의하지 않으면 이런 식으로 지어낼 수 있습니다 :frowning:

2개의 좋아요

디버깅을 활성화하고 (i) 버튼을 누르면, LLM에게 연구원 전체 언어를 지정하는 프롬프트의 해당 섹션이 표시됩니다.

리서처 페르소나가 커스텀 및 고급 검색 매개변수를 사용할 수 있다는 점은 훌륭하다고 생각하지만, 이 상황에서는 프론트엔드에서 동일한 검색 매개변수와 값을 사용할 수 없어 검색 쿼리를 수동으로 재현한 뒤 시스템 프롬프트를 사용자 정의하거나 세분화하거나, 결과가 0건으로 반환될 때 검색을 디버깅하기가 어렵습니다.

API를 통해 커스텀 검색을 재현할 수 있는 방법이 있을까요?

1개의 좋아요

지금은 아니지만, 정말 좋은 아이디어입니다. 기본적으로 이것은 일종의 필터입니다.

2개의 좋아요

샘, 정말 잘 쓰셨네요! 이제 디스코스 AI를 이렇게 쉽게 활용해 Deep Research 에이전트와 같은 것을 만들 수 있다니 정말 인상적입니다!
다만 한 가지 걱정되는 점이 있습니다:
image :open_mouth:

3개의 좋아요