내 파일에는 2805개 이상의 나쁜 단어가 있지만, 허용되는 나쁜 단어는 2000개뿐입니다. 더 많은 단어를 추가하는 방법은 무엇인가요? 텍스트 파일에서 10,000개의 나쁜 단어를 추가하고 싶은데, 어떻게 해야 하나요? 현재는 최대 2000개 항목만 추가할 수 있습니다.
현재 이 한도를 높일 계획은 없습니다. 이 부분이 큰 장애물이 된다면, 플러그인을 직접 작성하거나 의뢰하는 것을 고려해 보세요.
2개의 좋아요
감시 단어(watched words)를 사용하여 반복적인 스팸을 대응하다 보면 이 한계에 부딪힐 가능성이 있다고 생각합니다. 그래서 OP에게 도움이 되지는 않더라도, 미래에 다른 사람들에게 유용할 수 있는 몇 가지 생각이 떠올랐습니다.
코드 변경 없이 이 문제를 해결하는 방법은 [Using Regex with Watched Words]에 언급된 대로 정규식(regex)을 사용하는 것으로 변경하는 것입니다. 여러 단어를 하나의 정규식으로 묶을 수 있습니다. 정규식에 익숙하지 않으면 실수하기 쉽지만, 기술적으로는 가능합니다. (정규식을 잘 알고 있기 때문에 저는 이 방향으로 진행할 가능성이 높습니다.)
또한, 여기에서 플러그인을 작성하는 두 가지 방식이 있을 것으로 예상합니다.
2000개 제한의 이유는 알고리즘이 확장성이 좋지 않고 동기적으로 실행되기 때문이지만, 이는 임의의 제한입니다. 단순한 플러그인이 2000개 단어 제한을 원키 패치(monkey-patch)하여 성능 저하를 감수하면서 더 많은 단어를 허용할 수 있을 것으로 예상합니다. 하지만 제 개인적으로는 10,000개 항목에 대해서는 그렇게 하지 않을 것입니다!
다른, 혹은 상호 보완적인 접근 방식은 플래깅(flagging)을 위해 별도의 목록을 두고, 각 게시글 생성/수정 시마다 발동되는 사이드키크(Sidekiq) 작업을 통해 비동기적으로 처리하는 것입니다.
1개의 좋아요
다른 분들처럼 나도 이런 경로를 밟아왔습니다:
- 현재 GitHub 저장소에서 다운로드한 목록으로 시작합니다.
- 바로 2,000개 항목 제한에 부딪힙니다.
- 아, 정규식(Regex)을 쓸 수 있구나 - 최고!
- 복잡한 정규식은 쉽게 100자를 넘습니다.
- 쪼개야 합니다.
- 정규식을 다듬는데, 어이쿠, 이 것도 100자를 넘었네요.
- 더 세밀하게 쪼개야 합니다.
제한 조건과 춤을 추는 것은 불가능한 일이 아니라, 그저 짜증나는 일일 뿐입니다. 특히 그 제한이 인위적인 경우 더더욱 그렇죠. 그렇다고 해서, 이 필터링이 동기식(synchronous)으로 이루어지며 확장된 처리가 성능 문제를 일으킬 수 있다는 점, 그리고 가능한 한 많은 사용자에게 적합한 제한을 설정하려는 어려움은 충분히 이해합니다. 따라서 제한 조건 때문에 고생하고는 있지만, 그것에 대해 합리적으로 이의를 제기할 수는 없습니다.
여기 word_watcher.rb에서 필터링 코드를 확인했습니다. 개발자로서 플러그인을 작성해 보려는 시도를 해보고 싶지만, 그 코드는 확장 가능해 보이지 않습니다. 플러그인에서 JavaScript를 연결하여 Ruby 프로세스를 보완하는 방법을 전혀 알지 못합니다… 혹은 word_watcher 코드의 작성 방식상 그것이 가능한지조차 모르겠습니다.
방대한 목록을 처리하는 부담을 덜어주기 위한 개선 아이디어를 하나 제안합니다.
각 유형의 감시 목록(watch list)마다 전체 목록을 처리하는 대신, 서로 다른 필터 블록들을 순환하는 방식을 고려해 보세요. 예를 들어, 가장 흔하고 악용되는 필터를 block1에, 나머지를 block2~n에 배치할 수 있습니다. 동기식 필터링 프로세스는 한 번에 하나의 블록만 처리하며, 최종 저장(Save) 작업 시에만 모든 필터에 대한 완전한 순환을 수행합니다. 블록은 기존 목록에서 작동하므로, 누군가가 변경을 가할 필요가 없습니다. 기존 목록은 1,000개 항목의 블록으로 나뉘어지므로, block1은 1~1000번 항목, block2는 1001~2000번 항목 등이 됩니다. 최적화를 원하는 관리자는 이제 더 높은 우선순위의 필터를 목록 앞쪽으로 이동시킬 수 있습니다.
이 방식의 장점 중 하나는 문제를 포착하기 위해 전체 목록을 처리할 필요가 없다는 것입니다. 가장 가능성이 높은 문제는 더 작은 블록에서 포착될 수 있으며, 동기식 프로세스는 더 작은 블록의 처리를 더 빨리 완료할 수 있습니다. 물론, 감시 텍스트가 첫 번째 블록에서 발견되지 않으면 다른 블록을 처리해야 합니다. 이는 덜 가능성이 있는 악용을 포착하기 위한 약간 더 많은 오버헤드를 의미합니다. 이는 선택적 튜닝의 문제가 됩니다 - 만약 누군가가 그렇게 하고 싶다면 말이죠.
여기서 추가 옵션으로, 관리자가 블록 크기를 선택할 수 있도록 할 수 있습니다. 블록 크기를 줄이면, 예를 들어 루프 사이클당 500개 항목으로 줄이면, 각 동기식 프로세스는 더 빨리 진행되지만 처리해야 할 블록 수는 더 많아질 수 있습니다. 이는 존재하는 악용의 종류와 목록이 얼마나 잘 우선순위가 정해져 있는지에 따라 달라집니다. 다시 말하지만, 이러한 종류의 튜닝은 선택적이며, 솔직히 말하면 많은 관리자가 이런 식으로 심도 있는 튜닝을 하리라고는 의심합니다.
참고로, 정밀 튜닝은 정량화 가능한 지표가 있음을 의미합니다: 감시 단어(watch-word) 처리에 얼마나 많은 시간을 소요하고 있으며, 실제로 얼마나 많은 문제를 포착하고 있는가? 이런 네디한 수준의 세부 사항은 나중에 개선 사항으로 남기거나, 정말로 원한다면 플러그인으로 구현하는 것이 적절할 것입니다.
궁극적으로 "감시 단어 블록 처리"가 여기서 설명된 대로 구현된다면, 목록의 항목 수는 2,000개를 초과하도록 확장될 수 있습니다. 네, 더 긴 목록을 읽고 분할하는 데 일부 오버헤드가 발생할 것입니다. 다시 한번 말하지만, 이 프로세스에 얼마나 많은 시간이 소비되는지에 대한 지표가 있다면, 관리자는 최적화를 위한 자체 임계값을 결정할 수 있습니다… 하지만 많은 사람들이 이 정도로 깊이 파고들지는 않을 것 같네요. 공개된 가이드라인은 다음과 같은 것이 될 수 있습니다: “감시 단어 블록 처리 없이 제한은 2,000개 감시 단어로 유지됩니다. 블록 처리를 사용할 경우 특정 제한은 없지만, 항목 수가 증가함에 따라 성능 저하가 두드러지게 증가하므로, 실용적인 제한은 약 5,000개로 추정됩니다.”
여기서 기쁨을 느낄 수 있을까요?
결국 서버에서 이 작업을 수행하면 "무한"한 크기를 처리할 수 있으며, 게시물을 단어 단위로 분할한 후 “block” 테이블에 대한 단일 쿼리를 실행할 수 있습니다. 최악의 경우에도 테이블 스캔 1회만 필요합니다.
만약 여러분이 필요로 하는 것이 거대한 블록 목록이라면, 커스텀 플러그인을 만드는 것을 권장합니다.
2개의 좋아요
제가 배운 20개 이상의 프로그래밍 언어와 방언 중에서 루비(Ruby)는 포함되지 않습니다. 그래서 처음부터 플러그인을 만드는 것은 제가 감당할 수 없다고 생각하는 도전입니다. 다른 언어로라면 기꺼이 해볼 수 있겠지만… 아니면 다른 누군가가 그 일을 맡을 때까지 기다리는 편이 나을 것 같습니다. 
감사합니다.
이런 문제를 겪었습니다: Hit the blocklist limit for blocking words on the forum
필요한 단어 수에 따라 이 한도를 10,000으로 늘리거나 사용자 지정할 수 있어야 한다고 생각합니다.