Discourse에 AI 챗봇을 추가하는 것은 쉽습니다(훌륭한 플러그인 2개 덕분에요). 하지만 기술 지원을 수행하는 챗봇을 추가하는 것은 훨씬 어렵습니다! 이 글에서는 support.suretyhome.com을 위한 기술 지원 챗봇을 설정하는 과정에서 우리가 겪은 경험을 공유합니다. 우리가 원했던 것, 겪은 문제, 해결 방법, 그리고 앞으로의 계획입니다.
우리의 지원 팀은 정규 업무 시간에만 운영되지만, 고객들은 24시간 도움을 원합니다. 우리는 지원 팀을 대체하려는 것이 아닙니다. 우리의 목표는 다음과 같은 봇으로 지원 팀을 보조하는 것입니다:
- 포럼과 마찬가지로 밤과 주말을 포함하여 24/7 가용
- 인간 지원 팀이 조금 더 시간이 걸리는 동안 즉시 응답
- 포럼 검색으로 답변을 찾지 못했던 사용자들의 질문에 답변할 수 있을 수 있음
우리의 경험입니다.
플러그인 선택
AI 챗봇을 제공하는 정말 좋은 플러그인이 두 개 있습니다.
Discourse AI 플러그인은 Discourse 개발 팀의 공식 AI 플러그인입니다. 챗봇 외에도 다른 AI 기능들을 포함합니다. Discourse Chatbot 플러그인은 챗봇 기능만 제공합니다. Discourse AI보다 먼저 만들어졌으며, 그 한 가지 기능(챗봇)을 잘 수행하는 데 집중하고 있습니다.
처음에는 어떤 것을 사용해야 할지 몰라서 조언을 구하기 위해 여기에 질문을 남겼습니다.
많은 훌륭한 도움을 받았습니다. 결국 Discourse Chatbot을 선택했는데, 챗봇으로서 더 유연하고 커스터마이징할 수 있는 옵션(기능)이 더 많기 때문입니다. 우리의 사용 사례에는 Discourse AI로는 아직 구현하기 어려운 특정 요구 사항이 있었습니다. 둘 다 훌륭한 선택이 될 수 있습니다. 어떤 것이 적합한지는 포럼의 특정 필요에 따라 달라집니다.
초기 설정
Discourse Chatbot의 초기 설정은 선택할 옵션과 커스터마이징할 수 있는 부분이 많아서 다소 복잡한 작업이 될 수 있습니다. 설정 지침을 주의 깊게 따르고 모든 설정을 살펴보는 것이 중요합니다.
우리의 목표는 채팅과 같은 경험을 제공하는 것이었기 때문에 봇이 공개 주제나 PM(개인 메시지)이 아닌 Discourse Chat에서만 작동하도록 하였습니다. 우리가 취해야 했던 첫 번째 단계는 다음과 같습니다.
- Discourse Chat 설정 (Discourse Chatbot은 이에 의존함)
- Discourse Chatbot 설정에서 chatbot permitted in chat: 활성화
프롬프트 엔지니어링
Discourse Chatbot은 incredibly(놀라울 정도로) 커스터마이징할 수 있습니다. 설정이 아닌 모든 것은 Discourse의 Customize > Text에서 커스터마이징됩니다. 프롬프트 엔지니어링을 모두 여기에서 수행합니다. Customize > Text에서 chatbot.prompt를 검색하여 커스터마이징할 수 있는 모든 프롬프트 텍스트로 필터링할 수 있습니다.
봇이 우리가 원하는 방식으로 작동하도록 하려면 시스템 프롬프트를 편집해야 합니다. 하지만 시스템 프롬프트는 두 개가 있으며, 하나는 공개 토론용이고 다른 하나는 비공개 토론용입니다. 우리는 봇을 비공개 채팅 채널에서만 사용하므로 chatbot.prompt.system.rag.private를 편집해야 했습니다.
기술 지원 봇으로서, LLM이 기본적으로 갖는 특성보다 더 보수적이고 정확해야 합니다. 이를 달성하기 위해 시스템 프롬프트는 상대적으로 길어야 했습니다. 시스템 프롬프트에서 LLM에게 다음과 같은 질문에 대한 지시와 컨텍스트를 제공합니다:
- 당신의 봇은 누구이며 어떤 역할을 해야 합니까?
- 어떤 배경 정보나 컨텍스트를 알아야 합니까?
- 어떤 주제에 대해 이야기해야 합니까? 어떤 주제에 대해서는 절대 이야기하지 않아야 합니까?
- 어떤 글쓰기 스타일이나 톤을 사용해야 합니까?
- 사용자가 좌절할 때 무엇을 해야 합니까?
이 일반적인 프롬프트 엔지니어링 외에도, 시스템 프롬프트는 테스트 중에 발견한 문제를 해결하려는 시도를 할 수 있는 장소이기도 합니다. 봇이 심각한 실수를 하는 것을 발견하면, 시스템 프롬프트에 지시를 추가하여 수정할 수 있습니다. 하지만 주의하세요, 프롬프팅은 LLM에게 단순한 제안일 뿐입니다. 당신은 그것을 프로그래밍하는 것이 아닙니다. 단지 특정 방식으로 행동하도록 요청하는 것입니다. 그것이 듣지 않을 수도 있습니다.
Temperature와 Top P
봇을 더 보수적으로 만들고 허언을 덜하게 만드는 또 다른 도구는 temperature 설정입니다. 기본적으로 temperature 설정은 100이며, 이는 최대 temperature의 50%입니다. 이를 더 낮추면 봇이 더 보수적이고 결정론적이 되며 실수를 덜 하게 됩니다. 하지만 temperature가 매우 낮게 설정되면(예: 0) LLM의 사운드가 훨씬 덜 인상적입니다. 이는 여러분이 내려야 할 트레이드오프 결정입니다.
temperature 외에도 Top P 설정이 있습니다. 아마도 이 설정은 필요하지 않을 것이지만, 필요할 경우 사용할 수 있습니다. 자세한 내용은 OpenAI 문서를 참조하세요.
이 섹션의 Discourse Chatbot 설정은 다음과 같습니다:
- chatbot request temperature
- chatbot request top p
문제: LLM의 부정확함과 구식 정보
LLM은 과거에 방대한 양의 일반 데이터로 훈련되었습니다. 우리는 포럼에 대해 최신이고 구체적인 정보를 가지고 있으며 가능한 한 정확해야 합니다. 해결책은 검색 증강 생성(RAG)입니다.
RAG는 사용자에게 답변하기 전에 포럼에서 추가 정보를 검색합니다. 기술 지원 봇으로서, 우리는 LLM의 훈련된 지식에만 의존할 수 없으며, 답변하기 전에 봇이 포럼에서 기술 정보를 검색하도록 해야 합니다.
RAG를 수행하려면, Discourse Chatbot은 각 포럼 게시글을 의미론적 "특징"의 벡터로 나타내는 “임베딩” 데이터베이스를 생성해야 합니다. 이는 활성화해야 하지만, 다음 섹션에서 다룰 임베딩 전략을 설정한 후에 활성화하는 것을 권장합니다.
이 섹션의 Discourse Chatbot 설정은 다음과 같습니다:
- chatbot bot type high trust: RAG
- chatbot bot type medium trust: RAG
- chatbot bot type low trust: RAG
- chatbot embeddings enabled: 활성화 (임베딩 전략 설정 후)
문제: 많은 포럼 게시글이 유용하지 않음
봇이 답변하기 전에 포럼을 검색하게 하는 것(RAG)은 훌륭하지만 새로운 문제를 도입합니다. 포럼의 많은 게시글은 유용하지 않습니다. 일부 게시글은 유용하며, 봇이 찾기를 원하는 것이 바로 그것이지만, 많은 게시글은 단순히 대화적이며, 혼란스럽거나, 완전히 잘못되었습니다. 우리의 해결책은 봇이 찾기를 원하는 게시글로만 구성된 지식 기반(KB)을 큐레이션하는 것입니다.
Discourse Chatbot에서 이를 수행하려면 categories embeddings strategy를 사용합니다. 임베딩 전략은 봇이 포럼을 검색할 때 어떤 게시글이 사용 가능한지 결정합니다. 우리의 접근 방식은 단일 비공개 카테고리를 챗봇 지식 기반으로 사용하는 것이며, 따라서 임베딩 전략으로 categories를 선택합니다. 지식 기반 카테고리는 embeddings categories 설정에서도 식별되어야 합니다.
우리는 비공개 카테고리(직원만 볼 수 있음)를 사용합니다. 이 카테고리에서 많은 공개 주제를 복제하고 있기 때문에 사용자가 중복을 보고 싶지 않기 때문입니다. 주제를 비공개 카테고리로 복제하는 것은 몇 가지 다른 문제를 도입합니다.
- 주제를 복사하는 것은 많은 노력이지만, 주제가 업데이트되거나 답변이 달릴 때 복사를 유지하는 것은 더 나쁩니다.
- 봇이 포럼을 검색할 때 찾는 주제는 사용자가 참조 링크로 제공해야 하는 공개 주제가 아닙니다. 우리는 LLM에게 공개 주제에 대한 링크를 보내야 합니다.
이 두 가지 문제를 해결하기 위해, 우리는 공개 카테고리에서 주제들을 비공개 챗봇 KB 카테고리로 복사하고, 공개 주제가 업데이트될 때 KB 사본을 업데이트하는 데 도움이 되는 최소한의 도구를 만들었습니다. 우리가 사용하는 것과 같은 접근 방식을 사용하길 원한다면 여기에서 사용할 수 있습니다.
KB 도구는 공개 주제 전체를 단일 게시글로만 구성된 새로운 주제로 비공개 KB 카테고리에 가져옵니다. 모든 공개 주제 게시글을 연결하고 각 공개 게시글 내용 앞에 링크를 추가하여 수행합니다. 이렇게 하면 봇이 RAG 검색에서 비공개 KB 게시글을 찾을 때, 전체 공개 주제 내용과 답변에 참조로 포함할 수 있는 공개 게시글 URL을 얻습니다.
이 섹션의 Discourse Chatbot 설정은 다음과 같습니다:
- chatbot embeddings strategy: categories
- chatbot embeddings categories: (비공개 KB 카테고리)
- chatbot forum search function include topic titles: 비활성화 (기본값)
추가로, 게시글이 비공개 카테고리에 있으므로 포럼 검색 프롬프트에서 일부 보간 키를 제거해야 합니다.
- chatbot.prompt.function.forum_search.answer.topic.each.post: %{username} 및 %{date} 제거
- chatbot.prompt.function.forum_search.answer.topic.each.topic: %{title} 및 %{url} 제거
문제: LLM이 RAG 검색을 충분히 수행하지 않음
이제 좋은 정보로만 채워진 큐레이션된 게시글이 있는 비공개 카테고리가 있어 챗봇 지식 기반으로 사용할 수 있으므로, 모든 것이 순조로워야 할까요? 아닙니다. 우리가 겪은 다음 문제는 LLM이 RAG 검색 기능을 거의 사용하지 않았다는 것이었습니다.
GPT-4와 같은 LLM은 위험할 정도로 똑똑합니다. 그들은 이미 답을 알고 있다고 "생각"하고 도움이 필요 없다고 생각하지만, 실제로는 RAG 검색을 수행하고 지식 기반에서 답을 찾아야 하는 경우가 많습니다. 이를 해결하기 위해, 우리는 tool choice 옵션을 사용하여 LLM이 함수를 호출하도록 강제합니다.
우리는 로컬 포럼 검색을 강제할 수 있지만, 함수 호출을 강제하는 것만으로도 충분하다는 것을 발견했으며, LLM이 포럼 검색 대신 다른 함수를 호출할 수 있는 자유를 주고 싶습니다.
이 섹션의 Discourse Chatbot 설정은 다음과 같습니다:
- chatbot tool choice first iteration: force_a_function
문제: 포럼 검색 성능
함수 호출을 강제함으로써, LLM은 거의 모든 답변에 대해 RAG 검색을 안정적으로 수행합니다. 하지만 여전히 나쁜 결과를 얻고 있었습니다. 봇은 지식 기반에서 올바른 게시글을 찾지 못하고 있었습니다. 게시글에 정보가 너무 많아서 검색 기능이 가장 좋은 게시글을 찾는 능력을 방해하는 "노이즈"가 많았습니다.
예를 들어, 사용자가 HP Laser Jet 프린터의 삑삑 소리를 멈추는 방법에 대해 봇에게 묻는다고 상상해 보세요. LLM은 "HP LaserJet stop beeping"이라는 쿼리로 포럼 검색을 수행할 수 있습니다. 지식 기반에 그 문제를 완벽하게 다루는 게시글이 있을 수 있지만, 게시글 텍스트의 2%에 불과한 “질문” 부분(쿼리와 매우 유사할 것)만 있을 수 있습니다. 나머지 98%의 텍스트는 문제 해결 단계와 답변입니다.
Discourse Chatbot의 로컬 포럼 검색은 벡터 임베딩을 사용하여 쿼리와 가장 유사한 게시글(또는 몇 개의 게시글)을 찾는 의미론적 검색입니다. 가장 좋은 게시글의 질문 부분은 쿼리와 매우 유사하지만 전체 텍스트의 2%에 불과합니다. 나머지 98%의 텍스트가 게시글을 쿼리와 유사하지 않게 만드므로, 해당 쿼리에 대한 검색에서 게시글의 순위가 높지 않습니다.
이 문제에 대한 우리의 해결책은 검색 쿼리와 유사한 텍스트만 포함된 "미끼 게시글(bait posts)"을 지식 기반 주제에 추가하는 것입니다. 위의 예에서, 우리는 단순히 "HP Laser Jet beeping"만 포함된 미끼 게시글을 추가할 수 있습니다. 로컬 포럼 검색 기능은 쿼리와 매우 유사하므로 미끼 게시글을 쉽게 찾을 수 있습니다. 그런 다음 Discourse Chatbot이 미끼 게시글 대신 답변을 포함하는 실제 게시글 내용을 LLM으로 다시 보내도록 합니다.
우리의 KB 주제는 모든 내용을 첫 번째 게시글에 가지고 있으므로, KB 주제에서 답변을 미끼 게시글로 사용할 수 있습니다. KB 도구를 사용하여 주제를 지식 기반으로 가져온 후, KB 주제에 답변을 달아 미끼 게시글을 만들 수 있습니다.
이 섹션의 Discourse Chatbot 설정은 다음과 같습니다:
- chatbot forum search function results content type: topic
- chatbot forum search function results topic max posts count strategy: just_enough
- chatbot forum search function results topic max posts count: 1
미끼 게시글은 검색을 위해 지식 기반을 최적화하는 강력한 메커니즘을 제공하지만, 이를 눈먼 채로 수행해야 합니다. 검색이 발생하는 것을 볼 수 없으므로 미끼 게시글이 검색 순위에 어떻게 영향을 미치는지 정확히 알기 어렵습니다. 이 문제를 해결하는 데 도움이 되도록, 우리는 Discourse Chatbot이 사용하는 것과 동일한 의미론적 검색을 수행하지만 컴퓨터에서 로컬로 수행하고 유사도 점수와 순위와 같은 모든 세부 정보를 표시하는 작은 프로그램을 만들었습니다. 이를 통해 실제로 검색 성능을 향상시키고 지식 기반을 최적화하는 미끼 게시글을 만드는 것이 훨씬 쉬워집니다.
RAG, 큐레이션된 지식 기반, LLM의 함수 호출 강제, 미끼 게시글의 조합은 마침내 꽤 좋은 기술 지원 챗봇을 만들어냈습니다! 
LLM이 URL을 환각(Hallucinate)함
봇이 기술 질문에 잘 답변하고 있었지만, 여전히 성가신 환각 문제가 있었습니다. 그것은 사용자에게 답변할 때 URL을 자주 환각했습니다. 이는 LLM의 알려진 문제이며, 일반적인 합의는 그냥 받아들이라는 것입니다. 우리는 사용자가 그것에 대해 걱정하는 것을 원하지 않았습니다.
우리의 봇은 기술 지원을 제공하므로, LLM에게 정확하고 최신 정보를 제공하기 위해 RAG에 크게 의존합니다. 우리는 모든 답변 전에 RAG 검색을 수행하도록 강제합니다. 우리는 LLM이 "이해"하고 사용자와 소통하도록 하지만, 그들의 질문에 대한 답변에 사용되는 기술 정보에는 거의 전적으로 우리의 지식 기반에 의존합니다. 우리는 봇이 URL을 환각하는 것을 막기 위해 이를 활용할 수 있습니다.
우리의 해결책은 봇에 제약 조건을 추가하여 포럼 검색 결과에서 온 URL만 답변에 포함할 수 있도록 하는 것입니다. LLM이 이미 포럼 검색 결과에 없던 URL을 포함하려고 하면 Discourse Chatbot이 LLM에게 문제를 알리고 다시 시도하도록 요청합니다. 이 간단한 우회 방법은 URL 환각을 효과적으로 제거했습니다.
이 섹션의 Discourse Chatbot 설정은 다음과 같습니다:
- chatbot url integrity check: 활성화
문제: 챗봇이 모든 것을 처리할 수 없음
일부 지원 질문은 챗봇이 처리할 수 없으며, 이는 행동을 취해야 하기 때문입니다. 예를 들어, 계정 변경이 필요하거나 제품이 반환되어야 하는 경우(환불 및/또는 승인이 필요함) 봇은 이를 수행할 수 없습니다.
복잡성에 따라 달라집니다. 많은 질문은 직관적입니다 - 사용자가 올바른 쿼리로 포럼을 검색했다면 답을 찾았을 것입니다. 그런 경우, 봇은 포럼을 검색하고 답을 찾아 사용자에게 제시하는 데 꽤 좋습니다. 하지만 문제가 조사를 필요로 하거나 복잡한 분석을 필요로 할 때, 봇은 많은 가치를 추가하지 않는 일반적인 답변을 제공합니다.
봇이 문제를 처리할 수 없는 이러한 두 가지 상황 중 어느 것이든, 우리는 채팅을 인간 지원 팀으로 에스컬레이션하도록 해야 합니다. Discourse Chatbot에는 LLM이 정확히 그렇게 할 수 있는 함수가 있으며, escalate to staff라고 합니다.
이 섹션의 Discourse Chatbot 설정은 다음과 같습니다:
- chatbot escalate to staff function: 활성화
- chatbot escalate to staff groups: (에스컬레이션하려는 그룹)
우리는 이미 답변 전에 LLM이 함수를 호출하도록 강제하고 있지만, 이제 어떤 함수를 호출할지에 대한 문제가 있습니다. LLM은 local forum search 함수(RAG)를 호출해야 하는지, escalate to staff 함수를 호출해야 하는지? 사용자는 메시지를 보낼 때마다 이 결정을 내려야 합니다. 대부분의 경우 우리는 local forum search를 호출하기를 원합니다. 우리는 봇이 문제를 처리할 수 없거나, 사용자가 좌절하고 있다는 것을 알아차리거나, 사용자가 명시적으로 요청할 때만 escalate to staff를 원합니다.
우리는 프롬프팅을 사용하여 LLM이 어떤 함수를 호출할지 결정하는 방법을 안내합니다. Customize > Text에서 이를 위해 편집할 수 있는 프롬프트 텍스트는 다음과 같습니다:
- chatbot.prompt.system.rag.private
- chatbot.prompt.function.forum_search.description
- chatbot.prompt.function.escalate_to_staff.description
문제: 채팅을 모니터링할 수 없음
사용자가 실제로 챗봇을 사용할 때, 대화 내용을 보고 나쁜 답변이나 개선 기회를 찾는 것이 유용합니다. 하지만 Discourse는 관리자가 채팅을 읽을 수 있는 방법을 제공하지 않으며, 이는 채팅이 일반적으로 사람들 간의 비공개 대화이므로 당연합니다. 하지만 지원 봇과의 채팅은 비공개 대화가 아니며, 우리가 그것들을 검토할 수 없다면 봇을 지속적으로 개선할 수 없습니다.
좋은 소식은 Discourse가 관리자에게 포럼의 전체 채팅 기록을 CSV 파일로 내보내는 방법을 제공한다는 것입니다.
이 문제를 해결하기 위해, 우리는 채팅 기록 CSV 파일을 봇과 채팅한 각 사용자를 위한 HTML 파일 여러 개로 변환하는 작은 프로그램을 만들었습니다. 우리는 봇 사용 상황을 실시간으로 관찰할 수는 없지만, 이 솔루션을 통해 채팅 기록을 주기적으로 내보내고 HTML 파일로 변환하여 검토하고 봇을 개선하는 데 사용할 수 있습니다.
마무리
각 문제를 해결하고 지식 기반을 충분히 큐레이션한 후, 마침내 사용자가 챗봇을 사용하기 시작하도록 할 수 있었습니다.
지금까지 결과는好坏(좋고 나쁨)가 섞여 있습니다. 밤과 주말에 챗봇을 사용하여 질문을 해결하고 문제를 해결하는 사람들을 볼 때 흥미롭습니다. 챗봇을 사용하려 하지만 좋은 경험을 하지 못하는 사람들을 볼 때 눈이 열립니다. 그것은 일반적으로 우리의 지식 기반에 뭔가 빠지거나 불분명하다는 것을 의미합니다. 가끔은 시스템 프롬프트 개선이 필요한 문제를 발견합니다. 그리고 때로는 혼란이 있다는 것이 명확하며, 우리가 챗봇을 사용자에게 제시하는 방식을 개선해야 합니다.
채팅의 약 절반이 직원으로의 에스컬레이션을 필요로 하는 것으로 확인되었습니다. 그 중 에스컬레이션된 것의 약 절반은 봇이 상황을 처리할 수 없었을 가능성이 있는 경우입니다. 나머지 절반(채팅의 약 25%)은 봇이 문제를 해결할 수 있었지만 실패한 경우로, 이는 개선의 기회입니다.
직원으로의 에스컬레이션으로 이어지지 않는 채팅의 경우, 사용자가 실제로 문제를 해결했는지 아니면 그냥 포기하고 떠났는지 판단하기가 어렵습니다. 봇이 잘못된 답변을 제공할 때 무엇을 개선해야 하는지는 분명합니다. 합리적이고 좋은 답변을 제공하고 있을 때 사용자가 완전히 이해하고 문제가 해결되었는지 항상 분명하지는 않습니다. 그들이 우리에게 말하지 않는 한요.
전반적으로, 우리는 Surety 지원 챗봇의 이 첫 번째 반복에 만족하며, LLM이 개선되고 시간이 지남에 따라 우리의 지식 기반이 더 좋아지는 것을 기대하고 있습니다. 지식 기반을 작업하는 것이 지금 우리의 가장 큰 일입니다.
우리가 이 프로젝트를 작업하기 시작한 이후 Discourse Chatbot은 하이브리드 검색(의미론적 검색 및 텍스트 검색)에 대한 지원을 추가했으므로, 곧 그것에 대해 실험할 가능성이 높습니다.
Discourse Chatbot 플러그인에 대한 모든 힘든 작업을 위해 @merefield에게 감사드립니다. 작업하는 것이 매우 즐거웠고, 과업을 수행할 수 있음을 입증했습니다.
다른 사람이 자신의 포럼을 위한 기술 지원 챗봇을 구축하기로 결정한다면, 연락을 해서 알려주세요! 협력하고 아이디어를 교환할 수 있는 다른 사람들이 있으면 좋겠습니다. 흥미로운 일이 발생하거나, 변경 사항이 이루어지거나, 새로운 것을 배울 때마다 다시 업데이트하겠습니다.