hyejungg/ai-news-noti-bot

카카오워크 웹훅 연결

hyejungg opened this issue · 4 comments

hyejungg commented
  • 카카오워크 웹훅 설정 추가 (webhook url 은 몰리 -> .env 에 포함시키기)
  • 카카오워크 메시지 전송 로직 추가
  • 메시지 중복 체크 로직 추가 (고민 필요)
hyejungg commented

@jongwoo328
메시지 중복 체크 로직 중 고민이 있는데 같이 고민해주시면 좋을 것 같아서 언급 드립니다 ..

고민 되는 부분

  1. 중복 체크는 몇일 데이터까지 확인하는게 좋을지?
  2. 지금 생각나는 로직은 아래인데 개선하거나 더 좋은 방안이 있을지?
카카오워크 메시지를 만들 때 
1. db에서 최근 n일 데이터를 db에서 가져온다.
2. 크롤링 해온 데이터에서 1번 데이터 중 겹치는 것을 제거한다. 
3. 보낼 메시지 가공 + messages 컬렉션(db)에 저장할 dto 가공
4. 메시지 전송
5. 메시지 전달 성공 시 messages 컬렉션에 db 저장
  • 크롤링 해올 때 db에 저장된 사이트별로 keyword를 필터링해서 가져오는데 필터링 해온 데이터에다가 n일 데이터 중 중복되는 것을 지우면 사이트별로 0개일 때도 있을 것 같은데 이건 어떻게 생각하시나요 .. ? ㅠ
  • 또 고민되는 점이 메시지 전달 실패 시 messages 컬렉션이 log 성 데이터를 저장하는 목적이라면 성공/실패 여부도 저장해둬야 하는게 아닌가 싶기도 해서 ... 실패 시 실패했다는 것도 남겨둘까요 ?? (남기게 되면 스키마 변경 필요해보임)
  • 👀1
jongwoo328 commented

@hyejungg 저도 생각을 좀 해봤는데요..

  1. 중복 체크는 몇일 데이터까지 확인하는게 좋을지?
  • 중복체크 확인일자를 정해도 그 일자 이상 새 글이 없다면 예전 글을 새 글로 인식할 수도 있을 것 같네요
  • 이런 케이스를 생각하면 길면 길수록 좋을 것 같아요
  • 아예 영구 보관도 나쁘지 않을 수 있을 것 같고요 (db 사이즈가 되나요?)
  1. 지금 생각나는 로직은 아래인데 개선하거나 더 좋은 방안이 있을지?
  • 전체적인 순서는 말씀하신대로 가면 될 것 같습니다
  • 중복 체크 자체는 message 스키마로 봤을땐 url이나 title로 하실 것 같은데 그러면 대부분 문제는 없을 것 같네요
    • title이 변경되는 케이스, url에 post id 대신 title을 쓰는 케이스가 예외가 될 수 있을 것 같긴 합니다
    • 하지만 사이트별로 절대적인 identity 값을 노출하지 않을수도 있어서 url이나 title 기반이 현재로서는 가장 나아보이긴 하네요
    • 아니면 전에 말했던 것 처럼 중복체크용으로 쓸 key값을 저장하는 key를 스키마에 추가하는 방법도 있을 것 같고요
  • db에서 데이터를 가져올 때 우선은 긁어온 데이터 목록 중 가장 오래전에 작성된 글의 작성시간까지 db에서 가져와서 중복 체크를 하는게 더 안전할 것 같습니다. 만약 그 정보가 없을때는 적어주신 것 처럼 정한 일 수 만큼의 데이터를 가져오도록 하고요
  • 크롤링 해올 때 db에 저장된 사이트별로 keyword를 필터링해서 가져오는데 필터링 해온 데이터에다가 n일 데이터 중 중복되는 것을 지우면 사이트별로 0개일 때도 있을 것 같은데 이건 어떻게 생각하시나요 .. ? ㅠ
  • 이건 예상했던거기도 하고 저희가 어쩔 수 없는 내용이라 만약 없다면 있는것만 보내고 최악의 경우에 모든 내용이 갱신되지 않았으면 그냥 이번주는 없습니다 느낌으로 보내야 되지 않을까 싶네요
  • keyword에 걸리지 않아서 놓치는 것도 있지 않을까 라는 생각을 했지만.. 지금은 키워드 기반으로 일단 완성하시죠
  • 또 고민되는 점이 메시지 전달 실패 시 messages 컬렉션이 log 성 데이터를 저장하는 목적이라면 성공/실패 여부도 저장해둬야 하는게 아닌가 싶기도 해서 ... 실패 시 실패했다는 것도 남겨둘까요 ?? (남기게 되면 스키마 변경 필요해보임)
  • 남기는 것 자체는 혹시모를 상황에 있으면 좋을 것 같네요
  • 앞에도 말한 내용이지만 로그성 목적이라면 보관기간을 넉넉히 잡아도 좋겠어요
  • 👀1
hyejungg commented

@jongwoo328

아예 영구 보관도 나쁘지 않을 수 있을 것 같고요 (db 사이즈가 되나요?)

흠 .. 무료로 사용하려면 5GB 까지가 최대인 것으로 알고 있습니다.
영구 보관은 그렇고 안전하게 6개월 정도까지는 보관해도 5GB 는 넘진 않을 것 같네요.
AI 세계가 빠르게 변화하다보니 6개월 정도면 충분할 것 같은데 어떻게 생각하시나요? (3개월도 괜찮을 듯 .. )
image

keyword에 걸리지 않아서 놓치는 것도 있지 않을까 라는 생각을 했지만.. 지금은 키워드 기반으로 일단 완성하시죠

동의합니다.. 우선 제가 생각한 최선은 keyword 기반이긴 했는데 더 좋은 방법이 있을까요 ..? keyword 를 더 많이 넣어둘까 싶기도 합니다.
현재 있는 키워드는 아래와 같은데 더 생각나시는게 있으면 알려주세요 넣어두겠습니다!

"AI", "GAI", "Generative AI", "생성형 AI", "모델", "파라미터", "OpenAI", "GPT", "openai", "gpt", "gemini", "RAG"

아니면 전에 말했던 것 처럼 중복체크용으로 쓸 key값을 저장하는 key를 스키마에 추가하는 방법도 있을 것 같고요

이 부분 그때 제가 완벽하게 이해하진 못했는데 간단하게 알려주실 수 있을까요?

jongwoo328 commented

@hyejungg
제가 말한 중복체크부분 더 자세히 설명드리면

  • 일단 지금 스키마에 중복체크용 키가 하나 추가됩니다 예를들면 duplicateCheckKey라고 할게요. 여기는 스키마에 존재하는 다른 키 값을 넣게 됩니다
{
	"url": "url..",
	"title": "title..",
	"duplicateCheckKey": "title"
}
  • 그리고 중복체크할 때 duplicateCheckKey에 있는 키의 값을 가지고 중복 체크를 하는거에요. 중복 체크를 특정 키로 고정하지않고 가변적으로 넣을 수 있게 하자는 내용이었습니다.
  • 예를들면 url에 post id를 쓰는 사이트라면 변경될 수 있는 title 보다는 url 체크가 더 좋을 수 있을거고, 그런게 아니라면 title만 비교할 수도 있을거고, 나중에 site 스키마에 다른 정보가 추가되더라도 코드수정없이 비교할 수도 있고요..

흠 .. 무료로 사용하려면 5GB 까지가 최대인 것으로 알고 있습니다.
영구 보관은 그렇고 안전하게 6개월 정도까지는 보관해도 5GB 는 넘진 않을 것 같네요.
AI 세계가 빠르게 변화하다보니 6개월 정도면 충분할 것 같은데 어떻게 생각하시나요? (3개월도 괜찮을 듯 .. )

그러면 6개월 하시죠 5GB면 텍스트로 채우기 힘들어서 넉넉하게 잡아도 될거에요

  • 👍1
  • 👀1