저는 사이트에서 모든 AI 통합을 비활성화하고 싶었고, 이것이 단일 설정으로 처리되는 것이 정말 마음에 듭니다. OP가 찾고 있는 것의 대안은 discourse_ai_enabled의 사용자별 버전일 수 있습니다. 이렇게 하면 AI가 사이트 전체에서 단순히 켜짐/꺼짐이 아니라 사용자별로 제어될 수 있습니다. 사이트 레벨에서 켜져 있는 AI 기능도 사용자별로 억제할 수 있습니다. 그러면 discourse_ai_enabled의 로직은 사이트 전체가 true이고 사용자별로도 true인 경우에만 활성화되는 방식이 됩니다.
일반적으로 불필요한 복잡성을 피하기 위해 새로운 사용자 지정 설정을 추가하는 것을 신중하게 고려하지만, AI는 설정 가능한 옵션이 가장 많은 기능입니다. AI가 존재하기 시작한 짧은 기간 동안에도 Discourse에서 가장 사용자 지정 가능한 기능이 된 것 같습니다.[1]
아래는 대략적인 분석입니다. 저는 여기서 비교적 신참이라, 실수가 있을 수 있으니 과정을 보여드립니다.
su discourse -c 'bundle exec rails runner "SiteSetting.defaults.all.keys.sort.each { |k| puts k }"' > keys.txt
wc -l keys.txt
1663 keys.txt
cut -d _ -f 1 keys.txt | sort | uniq -c | sort -rn > counts.txt
이것이 올바른 집계 방식이라면, 가능한 사이트 설정은 총 1,663개입니다. 이 중 104개가 ai_로 시작하고, AI 관련 설정 중 3개는 그렇지 않습니다(composer_ai_helper_allowed_groups, discourse_ai_enabled, post_ai_helper_allowed_groups). 따라서 제 계산에 따르면, AI는 압도적으로 가장 큰 사용자 지정 설정 그룹입니다(총 사이트 설정의 1,663개 중 107개, 즉 6.4%). 상위 10개는 다음과 같습니다:
- 107 ai
- 84 discourse
- 83 chat
- 71 max
- 65 enable
- 48 default
- 30 dfp
- 28 oauth2
- 28 amazon
- 28 allow
한편으로, AI 기능의 사용자별 억제는 1,663개 중 1개에 불과합니다. 하지만 다른 한편으로, 많은 코드 경로가 사이트 전체 단위로 이를 확인하는 상황에서 사용자별로 확인하는 것은 어려울 수 있습니다. 이것은 제가 추측하기에 자격이 없는 트레이드오프입니다.
또한 비교적 명확하게 정의되고 독립적인 기능이며, 상대적으로 새로운 기능이기 때문에
ai_접두어로 일관되게 명명되어 있어 다른 컴포넌트보다 설정을 세는 것이 더 쉽습니다. 그래서 _대략적인 분석_이라고 표현했습니다. ↩︎