graphRAG - Neo4J로 구현하는 지식 그래프 기반 RAG 시스템 (feat. LangChain)
시멘틱 온톨로지 구축을 위해 데이터를 먼저 공부하고있습니다. RAG는 구축된 데이터가 들어간걸 조회할 때 쓰는거라고 생각하고있습니다. 온톨로지 구축을 위해 원천데이터 자체를 분석해서 도메인 사전을 만들어야한다는것을 알고있는데 이걸 어떤식으로 구조화해서 구축해야하는지가 감이 안옵니다. 정규식으로는 한계가 있을 것 같고 LLM으로 하자니 할루시네이션 등의 문제가 발생할 여지가 있고요 이런 관련된 강의를 진행하시거나, 제가 강사님 3가지 로드맵을 다 구독중인데 3개중 볼만한 강의가 있으면 회차좀 가이드부탁드립니다..
안녕하세요 선생님, 실제 필드에선 클라이언트의 요구 사항이 명확하지 않고, 기획자가 없으며, 개발자가 대부분의 일을 다 해내야 하는 경우가 있는데, 클라이언트(대표님 또는 상사)와 소통, 기획서 작성, 설계, 개발까지 혼자 하게 될 때 현명하게 대처하는 방법은 뭐가 있을까요? 큰 기업은 각자의 업무에 집중할 수 있겠지만, 작은 기업은 그게 쉽지 않은 걸 알고 있습니다 클라이언트와 소통, 화면 기획 및 요구 사항 작성등은 어떤식으로 공부해야할까요?
안녕하세요 수업자료 다운 받으면 자료가 하나도 보이지않는다는 문의남겼었습니다 알려주신 방법, 다른 문의에 있는 방법대로 다해봤으나 여전히 같은 문제가 발생합니다 마지막 방법으로 인쇄 눌러서 복사하려고하니깐 이러한 형태로 뭉쳐서 나오기에 공부하는데 어려움이 생깁니다 제가 지금 공부를 바로시작하려는데 계속 어려움이있으니 정보처리기사 zip파일 메일로 보내주시면 빠르게 공부할수잇을것같습니다 s2yeeuns@naver.com 빠른조치부탁드립니다
안녕하세요. 공통 코드와 계층 구조 관련해서 질문이 있어 질문 드립니다. 이전에 경험했던 프로젝트 보면 공통 코드와 계층 구조 테이블을 다 합친 일명 '만능 코드 테이블' 에 모두 넣고 사용하는 방식도 사용했는데 이번 공통 코드(자연키, 복합키) 강의와, 계층 구조의 강의를 들으며 시야가 또 달라지네요. 예를 들면 주문 상태 코드와, 상품 코드를 하나의 테이블의 대체키, 외래키를 적용해서 사용했었네요. 혹시 '만능 코드 테이블'의 경우는 추후 유지보수와 개발 편의 관점에서 개선해야하는 부분이 맞겠지요? 만약에 개선하게 된다면, 어떤 기준으로 나누면 될지. 설계적 관점에 대해 혜안을 듣고 싶습니다. 예를 들면, 공통 코드 테이블 2개와, 계층 테이블 이렇게 두고 계층의 가능성으로 보통 나누는지 궁금하고, 추가로 도메인 성격까지 고려해서 테이블을 또 쪼개는지 등이 궁금합니다. 그리고 CS 팀에서 고객 문의 사항에 문의 유형을 최초 상품, 주문, 배송 이런식으로 공통 코드에 넣어서 사용하고 있었는데, 갑자기 정책이 바뀌면서 주문 하위에 주문 오류, 주문 취소 등 하위 개념이 생기면 계층 테이블로 옮겨야 할 거 같은데 이런 경우는 애초에 기획당시에 개발자가 확장 가능성에 대해 고민을 하고 공통 테이블로 넣었으면 안되는 것인지에 대한 부분도 궁금하네요. 매번 질높은 강의로 도움주셔서 감사합니다!
[강의] 간단한 주문 조회 V1 : 엔티티를 직접 노출 [시간] 8분 25초 [질문 내용] 양방향 연관관계로 인한 무한 루프 문제까지는 발생하였고, @JsonIgnore로 해결하였습니다. 그런데 강의 내에서 지연 로딩으로 인해 발생하는 "Internal Server Error"가 발생하지 않고 아래 사진과 같이 200 OK가 뜨면서 조회 결과가 나옵니다 ㅜㅜ 강의와 같은 에러가 발생하지 않는 이유를 모르겠습니다...
형 질문있어. 페이징 기반 ItemReader 에서는 예제와 같이 ORDER BY 를 추가해야 한다. ORDER BY 가 없으면 매 페이지를 읽을 때마다 데이터의 순서가 보장되지 않아 일부 데이터가 누락되거나 중복될 수 있다. 라고 했잖아. 이 말은 곧 " JpaCursorItemReader 는 ORDER BY를 추가하지 않아도 괜찮다"로 들리는데 맞아? GPT는 아니라고 하거든. cursor 기반도 마찬가지로 ORDER BY가 없으면 재실행마다 DB에 정렬 순서를 위임하는데, DB는 쿼리 플랜이 변경되는 등 여러 원인들에 의해 실행마다 달라질 수 있대. 뭐가 맞아?
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요. 08:40 쯤에 public void changeTeam(Team team) { this.team = team; team.getMembers().add(this); } 이 부분에서, 내 팀을 변경해주고 변경할 팀에 해당 member를 넣어주는데 팀만 변경해 주면 되지 않나요? 따로 해당 team의 .getMember에 해당 멤버를 넣어주는 이유가 무엇인지 궁금합니다. 저장하기 전 까지는 해당 영속성에서는 이전 team에 할당이 되어 있어 수동으로 바꿔주는 것 인가요?
안녕하세요, 유저 테이블과 구독 테이블 설계 중 해결하기 까다로운 지점이 생겨 질문드립니다. *현재 상황을 보다 이해하시는데 문제가 없으시기 위해 ai로 질문을 정리한점 먼저 말씀드립니다. 1. 현재 상황 및 서비스 정책 유저 테이블: id(PK) , email(UK) / 탈퇴 시 소프트 삭제, 개인정보 보호를 위해 이메일 마스킹 필수. 구독 테이블: 현재 활성화된 구독 정보 딱 1건만 관리 (이력은 별도 테이블 존재). 서비스 정책: 탈퇴 후 동일 이메일로 재가입 시, 기존 로우 복구가 아니라 새로운 로우로 Insert 됩니다. 단, 재가입 시 과거 구독 정보는 그대로 이어받아야 합니다. 2. 제가 고민해 본 방법들과 예상되는 문제점 생각한 방법 1) 구독 테이블이 유저 PK( id )를 외래키로 바라보게 한다. 예상 문제: 재가입 시 유저 테이블에 새 로우가 Insert 되면서 새로운 PK를 발급받기 때문에, 과거 PK를 바라보고 있던 구독 테이블과 연결 고리가 끊어집니다. 생각한 방법 2) 유저 테이블에 '이메일 해시(유니크X)'를 두고, 구독 테이블과 해시값으로 매핑한다. 예상 문제: 해시는 개인정보가 아니므로 탈퇴 후에도 유저 테이블에 남겨둘 수 있어 재가입 매칭은 가능합니다. 하지만 유저가 중간에 이메일을 변경하는 경우 , 유저 테이블의 이메일 해시뿐만 아니라 구독 테이블 및 구독 이력 테이블의 해시값까지 전부 동시 UPDATE 쳐야 하는 번거로움이 생깁니다. 3. 질문 요약 개인정보 보호를 위해 유저 테이블의 이메일 원본은 마스킹하면서도, 재가입 시 동일인임을 식별해 과거 구독 정보를 매칭해 주어야 합니다. 여기에 유저의 이메일 변경 가능성까지 고려해야 하는 상황입니다. 이 경우 구독 테이블의 매핑 키 체계를 어떻게 잡는 것이 가장 깔끔하고 현명한 DB 설계 원칙 일까요? 실무에서 이런 케이스를 해결하는 정석적인 아키텍처 가이드가 궁금합니다!
자연키vs대리키 강의를 보면 대리키를 사용하는게 안정성,유연성에 있어 많은 장점이 있어 대부분 대리키를 사용한다고 하셨는대, 다음과 같은 케이스에도 대리키를 쓰는게 좋을지 궁금합니다. (뒤에 강의에 나올수도 있지만 현시점 궁금해서 질문드립니다.) 1. 조인테이블의 경우 a,b테이블의 pk인 대리키를 이용해 복합키를 만들어서 pk로 쓰면 될지, 아니면 그것 역시 따로 대리키를 만들어야 할지 궁금합니다. 2. 정말 단순한 enum 형태의 테이블일 경우, 예를 들어 유저상태값을 표현하기위해 정상,휴면,탈퇴 등을 기록하는 테이블의 경우 자연키, 대리키 어떤거를 써야할지 궁금합니다. 제가 경험한 바로는 enum 형태의 간단한 테이블조차 대리키를 사용하니 유저 테이블을 조회할때 간단한 상태값조차 조인을 해서 봐야하니 불편하더라고요. 감사합니다.