Discourse AI는 현재 콘텐츠에 대해 구조화된 출력(structured output)을 사용하고 있습니다. 그러나 구조화된 출력은 많은 API 제공업체에서 지원되지 않으며, 저의 국가에서 DeepSeek나 Qwen과 같은 거의 모든 AI 제공업체도 이를 지원하지 않습니다. 구조화된 출력을 사용하면 주요 AI 제공업체 몇 곳으로만 제한되는 매우 제한적인 API 선택지가 됩니다.
Discourse AI가 현재 제공업체 선택의 제한을 깨야 한다면, 구조화된 출력을 포기하는 것이 필수적이며, 이를 없애도 실제로 깨지는 것은 없다고 생각합니다. 해결책으로 간단한 고유 구분자를 사용하거나, JSON 스키마나 예시를 제공하여 AI가 JSON을 생성하도록 요청하되 구조화된 출력을 사용하지 않는 방식을 채택할 수 있는데, 왜 그렇게 하지 않는 것일까요?
중국을 위한 API 엔드포인트를 통해 Moonshot AI Kimi K2를 시도해 볼 수 있을까요?
기본 API URL이 https://api.moonshot.cn/v1인 것 같습니다.
저는 "다음은 요약입니다"와 같은 문구를 모델이 추가하거나, AI 어시스턴트의 제안된 제목 목록을 가져올 때 파싱이 실패하는 등의 문제에 대한 수천 건의 불만을 겪었기 때문에 구조화된 출력 요구 사항을 도입했습니다. 이제 번역이 추가되면서, 수백만 번의 LLM 호출에서 모델이 출력에 아무것도 추가하지 않도록 신뢰할 수 있어야 하는 상황이 되면서 이 문제는 더욱 악화되었습니다.
신뢰성의 필요성과 구조화된 출력의 일반적인 가용성을 고려하여, 해당 기능이 지원되는 제공업체에 대해 이 결정을 내렸습니다. 하지만 OpenAI 제공업체의 API 요청에서 구조화된 출력을 비활성화하는 체크박스를 추가하는 PR에는 개방적인 자세를 취하겠습니다.
좋은 제안입니다. 저는 Discourse 팀에게 이를 요구할 위치에 있지 않거나 요구할 수도 없으므로, 그저 몇 가지 제안을 드리는 것입니다.
더 견고한 파싱을 위해 구식 “separators” 솔루션을 사용하여 다음과 같은 XML과 유사한 원시 콘텐츠를 사용할 수 있습니다:
<SUMMARY_START>
Summary contnet.
<SUMMARY_END>
<SUGGESTIONS_START>
<SUGGESTION_START>
Suggestion 1
<SUGGESTION_END>
<SUGGESTION_START>
Suggestion 2
<SUGGESTION_END>
...
<SUGGESTIONS_END>
이 경우 <START>와 <END> 태그 밖의 내용은 신경 쓰지 않으면 됩니다. 이렇게 하면 가장 무능한 프로덕션용 AI 모델이라도 라벨을 올바르게 처리할 수 있다고 생각합니다.
또한 AI에게 추가 설명을 넣지 않도록 지시하고, 해당 체크박스를 활성화할 경우 관리자에게 발생할 수 있는 문제를 경고하는 것도 좋습니다.
Discourse AI가 생성하는 요청 본体的(request body)이 어떤 모습인지 정확히 알지 못합니다. 하지만 만약 그렇지 않다면, system 역할의 첫 번째 메시지에 시스템 프롬프트를 넣고, 다음 system 역할 메시지에 Past important content:\n과 같은 접두사와 함께 벡터 데이터베이스 조회 결과를 넣으며, 게시글 내용이나 기타 실제 데이터는 user 역할의 메시지에 넣으면 됩니다.