Discourse AI 주제 요약 🤖

[JamesPick]

요약을 작동하는 플로우에 적용해 보려고 몇 가지 발견한 점이 있습니다:

• 요약은 첫 번째 게시물부터 존재할 이유가 충분합니다. 주제가 커질수록 요약은 자연스럽게 진화하니까요. 물론 이러한 갱신은 설정에 의해 제한됩니다.
• 사용자가 특정 주제에 작업하고 있을 때, 요약은 페이지 상단에 배치되지만 사용자는 항상 하단(마지막 게시물, 마지막으로 읽은 게시물)으로 이동하게 됩니다. 따라서 이러한 사용자는 거의 항상 요약을 읽지 않게 됩니다. 정말 멋진 기능이지만, 유용하더라도 사용자가 맨 위까지 스크롤해서 요약을 볼 동기가 없으므로 결코 보지 못할 것이라고 생각합니다. 요약이 toc / 날짜 줄 아래 오른쪽 열에 배치되어 항상 보이도록 할 수는 없나요?

[merefield (Robert)]

@JamesPick

첫 번째 게시물의 요약을 포함할 이유가 없습니다. 주제가 확장됨에 따라 요약도 자연스럽게 진화할 것이기 때문입니다. 물론 설정에 따라 갱신이 제한됩니다.

비용 문제와 동시에 너무 많은 중복 정보가 공간을 차지하는 문제는 어떨까요?

사실 요약을 가장 가치 있게 만드는 시점은 토론이 본격적으로 진행되어 게시물이 여러 개 쌓였을 때일 것입니다.

어쨌든, 여기서는 임의로 임계값을 설정할 수 있고, 저의 조치가 필요하지 않을 것 같습니다.

@JamesPick

요약을 오른쪽 열의 목차/날짜 줄 아래에 배치할 수 있을까요? 그러면 항상 표시될 수 있을 텐데요.

기존 독자들이 요약을 읽는 데 관심을 가질지 확신할 수 있을까요? 요약은 처음 요약을 보고 더 아래로 읽는 데 가이드로 사용할 수 있는 신규 독자들에게 더 가치 있을 것 같다는 점을 지적합니다.

다만, 읽기에 불편하지 않도록 표시 폭이 충분히 넓다면 좋은 아이디어입니다. 하지만 이것이 도전 과제가 될 수 있습니다.

저의 실험적 해결책은 레이아웃 플러그인을 활용하여 주제(Topic)의 오른쪽이나 왼쪽에 표시될 수 있는 호환 위젯을 만드는 것입니다. (실제로 상단(Top) 지원을 추가하면 원래 위치인 상단에도 배치할 수 있습니다!)

이 문제를 해결하는 다른 방법들도 있습니다:

• 상단으로 이동 버튼을 추가합니다(테마 구성 요소가 이미 존재합니다). "요약으로 이동"이라는 라벨을 포함하도록 수정할 수도 있습니다.

어쨌든 로드맵에 추가하겠지만, 위의 의견에 대해 어떻게 생각하시는지 알려주세요.

[JamesPick]

@JamesPick

첫 번째 게시물의 요약을 두는 데에는 이유가 없습니다. 주제가 늘어남에 따라 요약도 자연스럽게 진화할 테니까요. 물론 설정에 따라 갱신이 제한될 수 있습니다.

비용 측면에는 동의합니다. 하지만 이것이 '대체 미리보기’로 사용될 예정이라면 요약을 생성해야 합니다. 설정을 업데이트하여 작동하게 할 수 있는지 확실하지 않습니다. 뭔가 놓친 것 같은데 다시 가서 확인해 보겠습니다.

@merefield

기존 독자들이 요약을 읽을 만큼 관심을 가질 것이라고 확신합니까?

좋은 지적입니다… 시간이 지나면 알 수 있을 것 같습니다. 하지만 사용자가 요약에 익숙해지면, 시간이 지남에 따라 간단히 한눈에 살펴볼 것이라고 생각합니다. 실제로 사용자가 여러 주제에 관여하고 있다면, 어떤 일이 있었는지 빠르게 떠올리는 데 좋은 메모리 트리거가 될 수 있습니다. 아마 미래에는 사용자가 특정 주제에 마지막으로 접속한 이후에 무슨 일이 있었는지 요약을 생성하도록 클릭할 수 있게 될까요? (다시 한번 API 호출 비용이 허락하는 한에서)

@merefield

제 실험적 해결책은 레이아웃 플러그인을 활용하여 호환되는 위젯을 만드는 것입니다.

이 아이디어를 좋아합니다. 네. 상단으로 이동하는 버튼보다 낫습니다. 그 버튼을 누르면 이전에 있던 곳으로 다시 돌아가야 하니까요(그곳이 마지막 게시물이 아닐 수도 있고).

[merefield (Robert)]

해당 기능의 0.1 버전이 완성되었습니다:

FEATURE: Add Layouts widget (#1)

동작하려면 Layouts 플러그인을 설치하고 올바른 사이드바를 구성해야 합니다.

이제 플러그인에 상단 표준 요약을 끄는 추가 설정이 있습니다.

거의 무상으로 얻는 부수적 효과로, 이제 모바일에서도 편리한 슬라이드 드로어를 통해 요약을 호출할 수 있게 되었습니다.

@JamesPick

[JamesPick]

@merefield

해당 기능의 0.1 버전이 완성되었습니다:

정말 훌륭합니다!

다만 방금 생성된 요약에 내부 “Whisper” 게시물의 세부 정보가 포함되어 있었습니다. openai로 전송되는 데이터에서 이러한 게시물을 제외할 수 있을까요?

[merefield (Robert)]

좋은 지적입니다. 바로 수정하겠습니다.

[merefield (Robert)]

IMPROVE: ignore admin posts and whispers, move prompt config to locales (#2)

IMPROVE: Move main prompt to locale, improve links to openai in settings (#3)

• 일반 사용자 게시물만 요약합니다(“관리자 조치”(예: “토픽 열림”) 및 속삭임 게시물은 무시)
• Admin → Customize → Text의 로케일 설정 ai_topic_summary.prompt.*을 통해 프롬프트 엔지니어링 허용
  • 이제 불필요해진 사이트 설정 제거
• 설정 내 OpenAI 링크를 클릭 가능하도록 변경(감사합니다 @MarcP)
• 모델 선택을 더 보기 좋은 드롭다운으로 변경

@JamesPick

[JamesPick]

감사합니다.
다만 질문이 하나 있습니다. 관리자 게시물을 모두 제외하고 계신 건가요? 그렇다면 게시물을 작성하는 관리자 사용자는 관리자용 계정과 커뮤니티 게시 및 상호작용을 위한 계정으로 두 개의 별도 계정을 갖는 것이 좋은 관행인가요? 제 사이트에서는 제가 주제에 자주 게시물을 올리는데, 그 내용도 요약에 포함되길 바랍니다(저는 사이트 관리자입니다).

[merefield (Robert)]

정리하자면:

"관리자"가 작성하는 “주제 닫힘”, “주제 열림” 등의 게시물은 사실 믿기 어렵겠지만, 실제로는 게시글 스트림에 포함된 게시글입니다.

우연히 модератор이나 관리자인 사용자가 작성한 일반 게시글이 아닙니다.

[JamesPick]

그 설명에 대해 정말 감사합니다

[merefield (Robert)]

괜찮아요. 더 잘 만들 수 있도록 도와주셔서 감사합니다.

[lubezniy (Victor Lyubezny)]

감사합니다. 이 플러그인을 설치하고 시작하려고 했는데, 몇몇 게시물에 댓글을 남기려 하면 HTTP 500 오류가 발생합니다. production.log 파일에서 다음과 같은 메시지를 확인할 수 있습니다:
StandardError (이 모델의 최대 컨텍스트 길이는 4097토큰이지만, 15682토큰(프롬프트 15482, 완성 200)을 요청했습니다. 프롬프트 또는 완성 길이를 줄여 주세요.)

[merefield (Robert)]

네, 그러니까요 … 설정을 통해 요약할 양을 줄여야 합니다.

이것은 버그라고 생각하지 않습니다. 단순히 너무 욕심부리고 계신 것뿐입니다

설정을 자신의 환경에 맞게 조정해야 합니다. 조절할 수 있는 게시물 제한과 문자 제한이 있습니다. 토큰은 보통 4자입니다.

기본값이 다소 너그럽게 설정되어 있을 수도 있지만 … 이는 토큰 한도를 근사치로 맞추기 위해 설정된 것이므로 다소 이상합니다.

이 설정들을 공유해 주시겠습니까?:

에러 메시지의 정보를 참고하여 변경 사항을 조정해 주세요.

GPT-4(접근 권한을 얻게 되면)는 토큰 한도를 최대 8배까지 처리할 수 있을 것으로 기대됩니다. 그날을 기대하고 있습니다.

[merefield (Robert)]

병합됨:

IMPROVE: add logic to strip quotes and put behind setting (#4)

• 이제 게시물의 인용문을 제거하여 중복을 방지하고 토큰 예산 사용량을 최적화합니다.
• 이전 동작 방식을 선호하신다면 새 설정을 해제할 수 있습니다.

[JamesPick]

@merefield 이 프로젝트에서 사용하고 있는 언어 모델에 대해 간단한 질문이 있습니다. 왜 gpt-3.5-turbo를 활성화하기로 결정하지 않으셨나요?

저희도 이메일 및 전화 통화 전사 요약에 gpt-3.5를 사용하는 것을 직접 테스트해 보았는데, 매우 좋은 결과를 내고 있습니다. 이메일 메시지나 전사 내용 자체는 사용자(user) 콘텐츠에 넣었습니다.

예를 들어 전화 통화 전사의 경우, ‘system’ 콘텐츠에 다음 내용을 추가했습니다.

이 전사 내용이 전화 통화인지, 아니면 발신자가 음성 메시지를 남긴 것인지 식별하세요.
전화 통화인 경우 전화 통화의 요약을 제공하고, 다음 섹션을 항목별로 작성하세요.

• 합의된 사항
• 제기된 질문
• 가능한 불일치 사항 / 우려 사항
• 감정 점수: (참여자별)
• 팀 리드 검토: (이 통화가 팀 리드에 의해 검토되어야 하는지 표시해 주세요)

음성 메시지인 경우 '남긴 음성 메시지 [대상]'이라는 제목을 제공하고, 새 줄에서 음성 메시지를 한 문장으로 요약하세요

[merefield (Robert)]

@JamesPick

왜 gpt-3.5-turbo를 활성화하기로 결정하지 않았나요?

그것은 채팅에 최적화되어 있었으며, 당시 Open AI는 요약(Summarisation) 작업에 Davinci 003 사용을 여전히 권장하고 있었기 때문입니다. GPT-4 관련 기술이 더 널리 제공되기 시작하면 이 부분을 재검토해 볼 의향이 있습니다.

참고로 ChatGPT와 Davinci-003는 동일한 세대 모델이므로, 결과 측면에서 둘 사이에 큰 차이가 있다고 보기 어렵습니다.

[satonotdead]

링크에서 가져온 내용을 요약하고, 게시글이 전송되기 전에 해당 게시글을 제안하는 가능성을 분석해 보셨나요?

이런 작업을 위해 ChatGPT 챗봇과 대화해 보았지만, 챗봇이 엉뚱한 방향으로 흘러가서 결국 그 방식을 중단해야 했습니다.

워크플로는 마지막에 다음과 같은 문구로 마무리할 수 있을 것 같습니다.

ChatGPT가 생성한 내용

많은 포럼에서 사람들이 ChatGPT를 자신의 실제 답변에 그대로 사용하고 있는 문제를 자주 볼 수 있습니다(이 때문에 많은 사용자가 거의 로봇처럼 행동하는 것처럼 보입니다).

[merefield (Robert)]

원격 콘텐츠는 현재 범위 내에 있지 않습니다. 아마도 향후 계획일 수 있습니다.

[Ed_S]

한 가지 말씀드릴 게 있습니다. 지난주에 두 번이나 어떤 글을 읽다가, 마지막에야 그것이 LLM이 작성한 것이라는 고지를 발견했습니다. 두 번 다 마음이 불편했어요. 글 뒤에 누군가가 있다는 믿음으로 그 글의 의미를 이해하려 노력했는데, 알고 보니 그렇지 않았으니까요.

그래서 저는 (강하게) 고지를 본문 앞에 두는 것을 권장합니다.

[satonotdead]

답변해 주셔서 감사합니다. 해당 기능이 향후 계획에 포함될 수 있다는 점은 이해합니다.

하지만 저는 링크의 내용을 ChatGPT에 질문했고, ChatGPT가 답변을 주었습니다(즉, 정상 작동 중입니다!). 그리고 누구나 이 방식으로 멘션을 달아 게시물을 수정하거나 삭제할 수 있습니다.

이 방식은 정말 유용합니다.