데이터베이스 테이블의 검색(SELECT) 속도를 획기적으로 향상시켜주는 자료구조

책의 목차에 비유한 인덱스 설명

• 인덱스가 없을 때 책에서 특정 단어를 찾으려면 첫 페이지부터 끝까지 모든 페이지(Full Scan)를 확인

• 데이터베이스에서는 테이블의 모든 행을 확인

• 느림

• 인덱스가 있을 때 책의 목차나 색인을 통해 원하는 내용이 몇 페이지에 있는지 확인하고, 그 페이지로 바로 이동

• 데이터베이스에서는 인덱스에서 데이터의 물리적 주소를 찾아 바로 접근

• 빠름

Index의 자료구조

A. B+Tree(B-Plus Tree) - 가장 일반적 & 표준

• 특징 데이터를 정렬된 상태로 유지

• 리프 노드*에만 실제 데이터를 저장하거나 데이터의 포인터를 저장하며, 이 리프 노드들은 링크드 리스트로 연결

• 사용 목적

• 범위 검색*(<, >, BETWEEN) 및 정렬(ORDER BY)에 매우 효율적이며, 대부분의 관계형 데이터베이스(RDB) 인덱스의 기본값

B. Hash Index(해시 인덱스)

• 특징 키 값에 해시 함수를 적용하여 해시 테이블 형태로 저장 데이터가 정렬되어 있지 않음

• 사용 목적

• 동등 비교 검색*(=)시 주소를 O(1)로 가장 빠르게 검색

• 제한 데이터가 정렬되어 있지 않아 범위 검색이나 정렬에는 사용 불가(DBMS에 따라 지원 여부 및 활용 범위가 다름)

Index의 유형

A. 클러스터드 인덱스(Clustered Index)

• 역할 인덱스의 리프 노드가 실제 데이터 행 자체 데이터의 물리적인 저장 순서가 이 인덱스 순서대로 정렬

• 개수 테이블당 오직 1개만 생성 가능, 주로 Primary Key(기본 키) 지정 시 자동으로 생성

• 조회 인덱스 검색 후 데이터에 바로 접근(1단계) -> 가장 빠른 조회 제공

B. 세컨더리 인덱스(Secondary Index, 보조 인덱스)

• 역할 데이터와 별도로 생성 리프 노드에는 컬럼 값과 해당 데이터의 클러스터드 키 값(또는 물리적 주소)만 저장

• 개수 테이블당 여러 개 생성 가능

• 조회 세컨더리 인덱스 검색 -> 클러스터드 키 획득 -> 클러스터드 인덱스를 통해 테이블 접근(2단계)이 필요

장단점 및 생성 기준

장단점

장점

• 조회 검색(SELECT) 속도 및 시스템 전반의 성능 향상

단점

• 저장/변경
• 추가 저장 공간* 필요 데이터 변경(CUD) 시 성능 저하(인덱스 갱신 필요)

생성 기준

1. 규모가 큰 테이블: 데이터 양이 적으면 Full Scan이 더 빠를 수 있음
2. WHERE, ORDER BY, JOIN 절에 자주 사용되는 컬럼
3. 카디널리티(Cardinality)가 높은 컬럼: 데이터의 중복도가 낮은 컬럼일수록 효율적(ex. ID, 주민번호, 이메일)

생성 및 활용

생성

-- (기본값) B+Tree 세컨더리 인덱스 생성
CREATE INDEX idx_members_join_date ON members (join_date); 

-- 특정 자료구조 명시 (DBMS가 지원하는 경우)
CREATE INDEX idx_members_email ON members (email) USING HASH;

커버링 인덱스를 활용한 최적화

쿼리가 요구하는 모든 컬럼이 인덱스에 포함되도록 인덱스를 설계하여, 실제 테이블 접근(Table Fetch) 없이 인덱스만으로 조회를 완료

-- 복합 인덱스 생성 (이름 검색 후 가입일 조회에 사용)
CREATE INDEX idx_members_name_date ON members (member_name, join_date);

-- 쿼리: 이름으로 검색하고 가입일만 조회
-- 이 경우, 인덱스(member_name, join_date)만 읽어 결과를 반환 (최적의 성능)
EXPLAIN SELECT member_name, join_date FROM members 
WHERE member_name = '홍길동';

옵티마이저의 역할

인덱스를 만들더라도, 데이터베이스 내부의 옵티마이저(Optimizer)가 쿼리 실행 시 비용을 계산하여 인덱스 스캔보다 Full Scan이 빠르다고 판단하면 인덱스를 사용하지 않을 수 있음 (ex. 조회하려는 데이터 비율이 전체의 10~20%를 초과할 때)

풀스택 GPT를 재밌게 수강중인 수강생입니다 새로운 AI 강의도 재밌을 것 같아서 구매합니다 배울게 많아보여서 두근두근하네요 ㅎㅎ

아래 3개의 DB를 성능, 편의성 두 가지 측면에서 비교해보도록 하자.

• 성능: 지원 기능, 작업 처리 능력, 확장성, 한계점(한계에 부딫힐까 걱정되는 부분이 존재하는가)

• 편의성: 설치, 백업 및 유지 관리

1. SQLite

• 성능: 3/5
• 편의성: 5/5

주요 특징

• 'Lite'는 성능과는 아무 관련이 없으며 실제로 얼마나 가벼운지, 리소스를 얼마나 적게 사용하는지, 설치, 백업 및 사용이 얼마나 쉬운지를 나타내며, 모든 휴대폰, 비행기, 스마트워치 및 IoT 장치에 내장되어 있을 정도로 가벼움.
• 가벼운 파일 기반 DB로, 설치 및 백업이 매우 간단함.
• 수백만 개의 행과 기가바이트 단위의 데이터를 처리할 수 있음.
• 테이블 열 유형이 간단하며, MySQL과 PostgreSQL에 필요한 모든 유지 관리 작업이 필요 없는 점이 장점.
• 서버 없이 애플리케이션 코드에 통합 가능.
• 단일 서버에 적합하며, 다중 서버 환경에서는 부적합.

요약

SQLite는 소규모 프로젝트나 단일 서버에서 쉽게 사용할 수 있으며, 유지 보수가 간단한 DB이다. 하지만 다중 서버 환경에서는 한계가 있다.

2. MySQL

• 성능: 4/5
• 편의성: 4/5

주요 특징

• 오랫동안 인기가 많은 견고한 DB.
• 많은 SQL 기능을 지원하며, 특히 ALTER TABLE 명령, 날짜 및 시간 데이터 유형, JSON 등 SQL 기능이 강점.
• Oracle의 인수 이후에도 지속적인 업데이트와 버그 수정이 이루어짐.
• PlanetScale과 같은 강력한 도구로 개발자 경험이 우수함.
• 백업, 업그레이드, 마이그레이션 등에서 SQLite보다 복잡함.

요약

MySQL은 많은 기능과 안정성을 제공하며 대규모 프로젝트에 적합하지만, 관리가 다소 복잡할 수 있다. PlanetScale 같은 툴을 활용하면 편의성이 증가한다.

3. PostgreSQL

• 성능: 5/5
• 편의성: 3/5

주요 특징

• 가장 진보된 오픈 소스 DB로, 많은 개발자가 선호.
• 확장 기능이 매우 강력하며, NoSQL 키-값 저장소로 전환(hstore)하거나, DB 트리거(plpython3u: SQL 쿼리에 python 코드를 작성할 수 있음)와 같은 고급 기능을 제공.
• 다양한 확장 기능으로 DB의 기능을 크게 확장할 수 있음(pgvector: 벡터 DB로 변환, PostGIS: 지리공간 데이터, pg_cron: DB 내에서 작업을 예약 등 pgxn.org 같은 웹사이트 참고)
• 확장 기능을 많이 사용할 경우 시스템이 복잡해질 수 있음.

요약

PostgreSQL은 강력한 기능과 확장성을 제공하지만, 복잡한 시스템 구조로 인해 관리가 어려울 수 있다. 고성능과 다양한 기능을 필요로 하는 프로젝트에 적합하다.

결론

• SQLite: 유지 보수와 간편한 관리가 중요한 소규모 프로젝트에 적합.

• MySQL: 대중적인 선택으로, 기능이 풍부하고 대규모 프로젝트에도 적합.

• PostgreSQL: 고성능과 확장성이 필요한 프로젝트에 이상적이지만, 관리가 복잡할 수 있음.

Reference

nomad coders - DB 고민 끝내드림 💥 Jake Seo tistory blog - PlanetScale 정리

AWS 관련 오늘 한 일

• 회원 가입
• EC2 인스턴스 생성
• 인스턴스 진입 및 update, python, gunicorn, nginx 설치

내일 할일

• requirements.txt 최신 버전으로 다시 한 번 freeze 하기
• .gitignore 설정
• .env 작성
• 가상 환경 폴더 제외하기
• dj_rest_auth library accounts/user url 주석처리하기
• 포트 열기는 보안-보안 그룹-인바운드 규칙에서 편집
• django ALLOWED_HOSTS 설정하기
• 정적 파일 모으기? (해야 되는지 모르겠음)
• Nginx 설정하기
• gunicorn 설정하기
• 개발 모드 종료하기
• postman으로 동작확인
• media 파일(유저가 올리는 이미지, 소설 표지) S3 ? 로 처리하는 방법 알아보기

현재 사용중인 기본적인 로직

변경할 로직

이전 로직은 시놉시스라는 전체적인 줄거리를 생성한 뒤 이를 참고하여 이어지는 내용을 작성했지만 이렇게 할 시 기본적인 사건 등 소설의 주요 갈등이 요약해서 등장하기 때문에 소설의 분기점을 나누려는 해당 프로젝트의 로직으로 사용하기에 맞지 않다고 판단했다.

따라서, 소설의 구성 요소를 생성한 뒤 이를 참고하여 프롤로그를 시작으로 발단, 전개, 위기, 절정, 결말의 순서대로 소설의 구현하는 것이 분기점을 넣는 것, 소설의 일관성을 유지하는데 더 맞다고 판단하여 로직을 변경할 예정이다.

1. README 작성 시, Frontend, Backend 로 나눠 작성되어 있어 내용을 확인하기에 좋았습니다. 지금까지 진행한 프로젝트 현황에 대한 내용 보충이 필요할 거 같습니다.
2. 현재 소설 생성 결과가 영어로만 나오는데, 번역 기능을 추가할 생각할 생각이 있으신지?
3. 웹페이지 시연 중에 페이지 로딩시간이 오래 걸리는 것에 대한 문제
   • CPU 점유율 높아서 생기는 문제로 웹페이지의 문제는 아님.
4. 소설을 생성하는 과정에서 AI prompt 요청했을 때 소설 전체를 생성하는지 레이아웃으로 나눠 생성되는지를 알 수가 없습니다. 어떻게 작업이 진행되는지? 또한 README 내에 어떤 방식으로 나오는지에 대한 추가 설명이 필요합니다.

dj_rest_auth를 사용하면서 profile은 이전에 UserDetailSerializer를 상속하여 만든 CustomUserDetailSerializer를 accounts/user에서 사용했지만 해당 serializer를 LoginSerializer가 같이 사용하는 것을 느꼈다.

Login을 하는 경우 access, refresh, user를 반환하는데 user모델의 필드를 전부 가져오기 때문에 로그인을 했을 때만 보여주고 싶은 user의 field(id, email, nickname)를 따로 구현하는 것이 쉽지 않았다.

LoginSerializer를 상속해서 이를 해결하려했지만 유저를 받아오는 과정에서 settings.py에서 설정한 USER_DETAILS_SERIALIZER를 사용하여 가져오는 듯하다.

{
    "access": "(access_token)",
    "refresh": "(refresh_token)",
    "user": {
        "id": 2,
        "email": "admin@test.com",
        "nickname": ""
          "books": []
    }
}

고민하다가 결국 기존에 존재하는 accounst/user를 profile로 사용하지 않고 ProfileAPIView를 새로 구현하기로 했다.

class ProfileAPIView(APIView):
    permission_classes = [IsAuthenticated]

    def get(self, request):
        user = request.user
        if not user:
            return Response(
                {"message": "해당 유저는 존재하지 않습니다."},
                status=status.HTTP_400_BAD_REQUEST,
            )
        serializer = ProfileSerializer(user)
        return Response(serializer.data, status=status.HTTP_200_OK)

    def put(self, request):
        user = request.user
        serializer = ProfileSerializer(user, data=request.data, partial=True)
        if serializer.is_valid(raise_exception=True):
            serializer.save()
            return Response(serializer.data, status=status.HTTP_200_OK)

    def delete(self, request, *args, **kwargs):
        user = self.request.user

        try:
            refresh_token = request.data.get("refresh_token")
            if refresh_token:
                token = RefreshToken(refresh_token)
                token.blacklist()
            else:
                return Response(
                    {"message": "refresh_token이 제공되지 않았습니다."},
                    status=status.HTTP_400_BAD_REQUEST,
                )
        except Exception as e:
            return Response(status=status.HTTP_400_BAD_REQUEST)

        try:
            # 사용자 비활성화
            # user.is_active=False
            # user.save()
            user.delete()
            return Response(status=status.HTTP_204_NO_CONTENT)
        except Exception as e:
            return Response(status=status.HTTP_400_BAD_REQUEST)

Synopsis

기존에 만든 SynopsisAPIView를 삭제하고 해당 기능을 BookListAPIView의 post method로 조정

Synopsis는 책의 뼈대가 되는 배경과 소설책의 제목을 반환하기 때문에 책의 제목을 저장하는 Book table에 넣는 것이 올바르다고 판단하여 BookListAPIView의 API endpoint를 사용

class BookListAPIView(ListAPIView):
    # 전체 목록 조회
    queryset = Book.objects.all().order_by("-created_at")
    serializer_class = BookSerializer

    # 새 소설 책 생성
    def post(self, request):
        user_prompt = request.data.get("prompt")
        if not user_prompt:
            return Response(
                {"error": "Missing prompt"}, status=status.HTTP_400_BAD_REQUEST
            )

        content = synopsis_generator(user_prompt)  # ai로 title, synopsis 생성
        title = content["title"]
        synopsis = content["synopsis"]
        serializer = BookSerializer(
            data={"title": title, "user_id": request.user.pk}
        )  # db에 title, user_id 저장
        if serializer.is_valid(raise_exception=True):
            serializer.save()
            return Response(
                data={'book_id':serializer.data['id'],"content": synopsis},  # FE에 content 응답
                status=status.HTTP_201_CREATED,
            )

Summary

소설책의 내용을 생성하는 SummaryAPIView는 생성하는 소설의 내용이 Book table의 소설과 같은 book_id를 가져야하기 때문에 이를 url에서 받는 BookDetailView의 post method에 구현하는 것으로 조정

def post(self, request, book_id):
        summary = request.data.get("summary")
        if not summary:
            return Response(
                {"error": "Missing summary prompt"}, status=status.HTTP_400_BAD_REQUEST
            )
        result = summary_generator(summary)
        book=get_object_or_404(Book, id=book_id)
        serializer = ChapterSerializer(
            data={"content": result["final_summary"], "book_id": book.pk}
        )
        if serializer.is_valid(raise_exception=True):
            serializer.save()
            result['book_id']=book.pk
            return Response(data=result, status=status.HTTP_201_CREATED)

기존 Book model의 content를 지우고 해당 테이블에는 id, 책 제목, 작성자, 좋아요, 작성날짜, 수정날짜만을 가진 생성한 소설책을 저장하고 이에 대한 내용은 chapter를 사용하여 저장하는 방법을 사용

위와 같은 형식 chapter_num는 id 처럼 자동으로 증가하되 book_id가 같을 경우에만 자동으로 증가하고 새로운 book_id가 생성되면 1로 초기화

class Chapter(models.Model):
    chapter_num = models.PositiveIntegerField(editable=False)
    content = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)
    book_id = models.ForeignKey(Book, on_delete=models.CASCADE, related_name="chapters")

    def save(self, *args, **kwargs):
        if not self.id:
            last_index = (
                Chapter.objects.filter(book_id=self.book_id).order_by("index").last()
            )
            if last_index:
                self.chapter_num = last_index.chapter_num + 1
            else:
                self.chapter_num = 1
        super(Chapter, self).save(*args, **kwargs)

이전에 구현한 synopsys를 토대로 소설의 줄거리를 구현하고 출력된 소설의 다음 방향성을 결정하는 선택지 3개를 생성하여 프론트엔드에 데이터 넘겨주기

def summary_generator(summary):
    llm=ChatOpenAI(model='gpt-3.5-turbo', api_key=os.getenv('OPENAI_API_KEY'))

    memory=ConversationSummaryBufferMemory(llm=llm, max_token_limit=20000, memory_key='chat_history', return_messages=True)

    summary_template = ChatPromptTemplate.from_messages([
        ("system", "You are an experienced novelist. Write a concise, realistic, and engaging summary based on the provided theme and previous context. Develop the characters, setting, and plot with rich descriptions. Ensure the summary flows smoothly, highlighting both hope and despair. Make the narrative provocative and creative. Avoid explicit reader interaction prompts or suggested paths."),
        MessagesPlaceholder(variable_name="chat_history"),
        ("human", "{prompt}")
    ])

    recommend_template = ChatPromptTemplate.from_messages([
        ("system", "Based on the current summary prompt, provide three compelling recommendations for the next part of the summary. Your recommendations should emphasize hopeful, tragically hopeless, and starkly realistic choices, respectively. Be extremely contextual and realistic with your recommendations. Each recommendation should have 'Title': 'Description'. For example: 'Title': 'The Beginning of a Tragedy','Description': 'The people are kind to the new doctor in town, but under the guise of healing their wounds, the doctor slowly conducts experiments.' The response format is exactly the same as the frames in the example."),
        MessagesPlaceholder(variable_name="chat_history"),
        ("human", "{current_story}")
    ])

    def load_memory():
        return memory.load_memory_variables({})["chat_history"]

    def parse_recommendations(recommendation_text):
        recommendations = []
        try:
            rec_lines = recommendation_text.split('\n')
            title, description = None, None
            for line in rec_lines:
                if line.startswith("Title:"):
                    if title and description:
                        recommendations.append(
                            {"Title": title, "Description": description})
                    title = line.split("Title:", 1)[1].strip()
                    description = None
                elif line.startswith("Description:"):
                    description = line.split("Description:", 1)[1].strip()
                    if title and description:
                        recommendations.append(
                            {"Title": title, "Description": description})
                        title, description = None, None
                if len(recommendations) == 3:
                    break
        except Exception as e:
            logging.error(f"Error parsing recommendations: {e}")

        return recommendations

    def generate_recommendations(chat_history, current_story):
        formatted_recommendation_prompt = recommend_template.format(
            chat_history=chat_history, current_story=current_story)
        recommendation_result = llm.invoke(formatted_recommendation_prompt)
        recommendations = parse_recommendations(recommendation_result.content)
        return recommendations

    def remove_recommendation_paths(final_summary):
        pattern = re.compile(r'Recommended summary paths:.*$', re.DOTALL)
        cleaned_story = re.sub(pattern, '', final_summary).strip()
        return cleaned_story


    chat_history = load_memory()
    prompt = f"""
    Story Prompt: {summary}
    Previous Story: {chat_history}
    Write a concise, realistic, and engaging summary based on the above information. Highlight both hope and despair in the narrative. Make it provocative and creative.
    """

    formatted_final_prompt = summary_template.format(chat_history=chat_history, prompt=prompt)
    result = llm.invoke(formatted_final_prompt)
    memory.save_context({"input": prompt}, {"output": result.content})

    cleaned_story = remove_recommendation_paths(result.content)
    recommendations = generate_recommendations(chat_history, result.content)

    return {"final_summary": cleaned_story, "recommendations": recommendations}

memory를 사용하여 소설의 내용이 이어지도록 다음 summary를 생성하도록 한다. ConversationSummaryBufferMemory를 사용하여 일정 토큰까지는 결과값을 그대로 저장하고 토큰의 값보다 많이 저장되기 시작하면 오래된 데이터를 요약하여 저장하면서 소설의 내용이 뜬금없는 값이 되지 않도록 한다.

AI를 사용하여 소설을 만들기 위해 소설의 기본적인 배경을 생성하고 그에 맞게 소설을 생성하기 위해 시놉시스를 AI가 생성하도록 하려한다.

본인이 평소에 관심이 있는 소설과 원하는 장르를 입력하여 AI가 적당한 시놉시스를 만드는 것을 목표로 한다.

랭체인을 사용하여 example예시를 주고 AI에게 예시에 맞는 대답을 하도록 설정하고 시놉시스를 생성한다.

llm = ChatOpenAI(
    model="gpt-3.5-turbo", api_key=os.getenv("OPENAI_API_KEY"), max_tokens=800
)

examples = [
    {
        "novel": "Harry Potter",
        "genre": "fantasy",
        "answer": """
            (The answer of the AI you want)
        """,
    },
    {
        "novel": "Miracles of the Namiya General Store",
        "genre": "mystery",
        "answer": """
            (The answer of the AI you want)
        """,
    },
]

example_prompt = ChatPromptTemplate.from_messages(
    [
        (
            "human",
            "I'm going to make a new novel by referring to the novel {novel}. I'm going to make the genre {genre}. Please make a synopsis.",
        ),
        ("ai", "{answer}"),
    ]
)

example_prompt = FewShotChatMessagePromptTemplate(
    example_prompt=example_prompt,
    examples=examples,
)

final_prompt = ChatPromptTemplate.from_messages(
    [
        ("system", "You are an expert in fiction"),
        example_prompt,
        (
            "human",
            "I'm going to make a new novel by referring to the novel {novel}. I'm going to make the genre {genre}. Please make a synopsis.",
        ),
    ]
)

chain = final_prompt | llm

chain.invoke({"novel": "twilight", "genre": "Romance"})

In the small town of Moonlight Falls, a new student named Luna arrives at Moonlight High School. Luna is mysterious and keeps to herself, but she captures the attention of the popular and enigmatic student, Blake. As they get to know each other, Luna reveals that she is not entirely human - she is a descendant of a powerful supernatural bloodline that has been kept secret for generations. Blake is drawn to Luna's otherworldly charm and the two develop a deep connection despite the dangers that come with Luna's true identity. However, their forbidden love is put to the test when a rival supernatural clan threatens to expose Luna's secret and tear them apart. Luna and Blake must navigate the treacherous world of supernatural politics and fight for their love against all odds.

Moonlight Falls라는 작은 마을에서 루나라는 이름의 새로운 학생이 Moonlight High School에 도착합니다. 루나는 신비롭고 비밀에 부쳐지지만, 그녀는 인기 있고 수수께끼 같은 학생인 블레이크의 관심을 사로잡습니다. 그들이 서로에 대해 알게 되면서, 루나는 완전히 인간이 아니라는 것을 드러냅니다. 블레이크는 루나의 세속적인 매력에 매료되고, 루나의 진짜 정체성에 따르는 위험에도 불구하고 두 사람은 깊은 관계를 발전시킵니다. 그러나, 그들의 금지된 사랑은 라이벌 초자연적인 일족이 루나의 비밀을 폭로하고 그들을 찢어버리겠다고 위협할 때 시험대에 오릅니다. 루나와 블레이크는 초자연적인 정치의 위험한 세계를 탐색하고 모든 역경에 맞서 그들의 사랑을 위해 싸워야 합니다.```

patch -p1 --dry-run < test.patch

$ patch -p1 < test.patch

패치 적용하기 곧바로 패치를 적용해도 되지만, 문제가 없는지 테스트부터 하기를 권합니다.

$ patch -p1 --dry-run < test.patch 실패하지 않으면 실제로 적용합니다.

$ patch -p1 < test.patch ※ -p1은 패치 파일에 파일명이 등장할 때마다 prefix가 있음을 알려주는 옵션입니다. git diff에서 파일명에 prefix를 붙이는 게 기본값이기 때문입니다. prefix를 안 붙이려면 git diff에 --no-prefix 옵션을 주면 되고요, 이렇게 만든 패치 파일은 적용할 때 -p1이 아니라 -p0 옵션을 쓰면 됩니다.

나중에 정리예정

메모리를 chain에 꽂는 방법 2

langchain express 사용하기(변경작업을 할 때 권장하는 방법)

LLMChain은 메모리를 자동으로 저장해줘서 메모리 저장에 필요한 추가 코드를 작성할 필요가 없는 것이 장점이자 단점(사용자가 필요하지 않은 부분도 저장할 가능성이 있음) (반자동, 자동으로 LLM으로부터 응답값을 가져오고 memory 업데이트, prompt에 기록을 넣는 건 수동)

LCEL은 메모리를 저장하기 위한 코드를 작성해야 하지만 그 외의 다양한 메세지를 전달하는 등의 작업의 자유도가 높아 확장성이 좋음 (수동)

Github

메모리를 chain에 꽂는 방법 1

대화 기록을 추가하는 방식

LLM chain

off-the-shelf chain(일반적인 목적을 가진 chain)

스스로 무언가를 만들 때는 off-the-shelf chain보다는 우리가 직접 커스텀해서 만든 chain을 활용하기를 선호

off-the-shelf chain은 빠르게 시작할 수 있어 좋긴 하지만 off-the-shelf을 커스텀하기보다 직접 만들고 싶을 땐 langchain expression 언어를 활용해서 우리의 것을 만들 수 있음

memory class는 memory를 두가지 방식으로 출력할 수 있다.(문자열 형태, 메세지 형태)

string

string

message

메세지를 기반으로 한 사람과 ai의 대화 기록을 추가하는 방법 message

ConversationKGMemory

Conversation Knowledge Graph Memory 대화 중 entity의 knwoledge graph를 만듬 가장 중요한 것들만 뽑아내는 요약본

knowledge graph에서 히스토리를 가져오지 않고 엔티티를 가져옴

Keeping

• 팀원 간의 불화가 일어나지 않아 좋았다고 생각함
• 기본적인 CRUD, 해당 기능에 대한 권한처리가 잘 되었다고 생각함

Problem

• branch 명을 모두가 알아보기 쉽게 앱 or 기능별로 나눠서 branch명을 지었으면 좋았겠다고 생각함

• 피드백 과정에서 나왔지만 AI News 생성에서 class로 구현한 기능을 파일을 나눠 사용하는 과정에서 함수로 바꾸면서 함수명을 코드 컨벤션에 맞게 “snake_case”로 바꾸지 못한게 아쉬움

• 의사 소통이 더 원활히 됐다면 기능을 더 추가하거나 기존 코드, ERD의 보완을 더 할 수 있었을 거라는 아쉬움이 있음

Try

• Django에서 기본적으로 지원하는 password validation을 custom하여 password validation을 만들어보기

• 다른 AI 모델을 사용해서 AI News 생성 기능 개선하기