앞 편에서 자를 만들었고, 그 자가 어디를 고쳐야 하는지까지 알려줬다.

1. 먼저 4편의 빚을 갚는다

**「3만원 이하 선물용」**을 벡터로 찾으면 이렇게 나왔다.

처방은 4편에서 이미 말했다 — 조건은 SQL 이 맡는다.

from db import query

# ① 먼저 자른다. 이 조건은 틀리는 법이 없다
allowed = {r[0] for r in query("""
    SELECT product_id FROM products
    WHERE price <= 30000 AND tags LIKE '%선물용%'
""")}

print("조건을 통과한 상품:", len(allowed), "개")

# ② 남은 것 중에서만 뜻으로 고른다.
# argsort 로 전체 순위를 받아놓고, 조건 밖은 건너뛴다
scores = V @ q
count = 0

for i in scores.argsort()[::-1]:
    if pids[i] not in allowed:
        continue
    print(f"  {scores[i]:.4f}  {pids[i]} {names[pids[i]]}")
    count += 1
    if count == 5:
        break

순서를 바꾸면 안 되나

된다. 그런데 다르게 된다.

2. 추천에 붙인다 — 어떤 조건을 걸 것인가

「3만원 이하 선물용」은 사람이 말로 준 조건이었다. 추천에는 그런 말이 없다. 고객이 아무 말도 안 했는데 우리가 조건을 정해야 한다.

코드는 두 단계로 갈라 쓴다. 자르는 쪽과 고르는 쪽이다.

def allowed_for(customer_id):
    """① SQL 로 자른다 — 이력에 있는 카테고리만, 이미 산 것은 빼고."""
    return [r[0] for r in query("""
        SELECT product_id FROM products
        WHERE category IN (
            SELECT products.category FROM purchases
            JOIN products ON purchases.product_id = products.product_id
            WHERE purchases.customer_id = ? AND purchases.is_holdout = 0)
          AND product_id NOT IN (
            SELECT product_id FROM purchases
            WHERE customer_id = ? AND is_holdout = 0)
    """, (customer_id, customer_id))]


def candidates_for(customer_id, index):
    """② 남은 것 중에서 뜻으로 고른다."""
    allowed = allowed_for(customer_id)
    if not allowed:
        return []                          # 조건을 통과한 상품이 하나도 없다

    # 통과한 상품의 벡터만 골라 계산한다. 200개 전부를 볼 필요가 없다
    rows = [index_of[p] for p in allowed]
    scores = V[rows] @ CV[index]

    return [allowed[i] for i in scores.argsort()[::-1][:N_CANDIDATES]]

조건을 바꾸려면 allowed_for 안의 SQL 만 갈아끼운다. 뒤쪽은 한 글자도 안 바뀐다 — 그래서 조건 넷을 만들어 재보는 일이 SQL 네 개를 쓰는 일로 끝난다.

3. 30명으로 재본다

11편에서 만든 자를 그대로 쓴다. 표본도 30명 그대로다.

두 배다. 여기서 끝내고 「카테고리+피부로 간다」고 발표하면 된다.

4. 🔴 300명으로 재면 뒤집힌다

5. 왜 뒤집혔나 — 조건은 정답도 자른다

「SQL 은 틀리는 법이 없다」고 했다. 맞다. 그런데 조건 자체가 틀릴 수 있다.

카테고리+피부는 정답의 70%를 잘라버린다. 그 사람들은 조건을 거는 순간 이미 졌다. 남은 15개 중에서 고르기가 아무리 쉬워져도 거기에 정답이 없다.

6. 고른 것에 모델을 붙인다

이력 카테고리 하나만 걸기로 했다. 11편과 똑같은 30명·똑같은 채점기에 후보 뽑는 방법만 바꿔 끝까지 돌려본다.

후보는 확실히 좋아졌다. 천장이 20%에서 30%로 올랐고, 모델 없이 벡터 상위 5개만 내면 13.3%에서 23.3%가 된다. 300명에서도 10.3%에서 13.7%로 올랐다.

그런데 모델을 얹으면 13.3%로 도로 내려온다.

7. 🔴 모델이 벌어놓은 것을 못 받아먹는다

정답이 후보 열 개 안에 있던 사람은 아홉 명이었다. 그 아홉 명을 하나씩 본다. 모델을 바꿔가며 봤다.

8. 🔴 조건을 통과한 상품이 하나도 없는 사람

조건을 겹쳐보면 새 사고가 나온다.

def allowed_with_fallback(customer_id):
    """조건을 센 것부터 걸어보고, 비면 한 겹씩 떼어낸다."""
    # 튜플의 목록이다. 앞이 셀수록 좋고, 뒤로 갈수록 헐거워진다
    steps = [
        ("카테고리+가격", lambda: by_category(customer_id) & by_price(customer_id)),
        ("카테고리", lambda: by_category(customer_id)),
        ("전체", lambda: all_product_ids),
    ]

    bought = already_bought(customer_id)

    for label, make in steps:
        allowed = make() - bought
        if allowed:
            return list(allowed), label       # 어느 단계에서 나왔는지도 돌려준다

    return [], "없음"

이번 편에 나온 것

미션

from_step = {}
hit = 0

for index in range(300):
    customer_id = customer_ids[index]
    allowed, step = allowed_with_fallback(customer_id)

    # 어느 단계에서 나왔는지 센다. get 은 없으면 0 을 돌려준다
    from_step[step] = from_step.get(step, 0) + 1

    if not allowed:
        continue

    rows = [index_of[p] for p in allowed]
    scores = V[rows] @ CV[index]
    picks = [allowed[i] for i in scores.argsort()[::-1][:5]]

    hit += answers[customer_id] in picks

print(from_step)
print(f"hit@5 {hit / 300 * 100:.1f}%")

정리하면

4편에서 진 빚을 갚았다. 「3만원 이하 선물용」이 이제 제대로 나온다 — 51개로 먼저 자르고 그 안에서 고르니 조건을 어길 방법이 없다. 순서가 핵심이다. 고르고 나서 거르면 남는 게 없을 수 있고, 자르고 나서 고르면 항상 나온다.

추천에도 같은 구조를 붙였다. 조건 후보 넷을 만들어 30명으로 재봤더니 카테고리+피부가 hit@5 26.7% 로 두 배였다. 여기서 끝냈으면 틀린 것을 골랐을 것이다.

300명으로 다시 재니 뒤집혔다. 1등이던 카테고리+피부가 3등이 되고, 2등이던 피부타입은 아무것도 안 한 것(10.3%)보다 나쁜 8.0% 가 됐다. 재는 데 모델이 필요 없어 몇 초면 되는 실험이었다. 싸게 잴 수 있으면 크게 잰다 — 비싼 실험은 작게 여러 번, 싼 실험은 크게 한 번이다.

뒤집힌 이유도 숫자로 나왔다. 조건은 정답도 자른다. 카테고리+피부는 정답의 70%를 잘라내서, 그 사람들은 조건을 거는 순간 이미 진다. 「SQL 은 틀리는 법이 없다」는 말은 SQL 이 시킨 대로 정확히 한다는 뜻이지 우리가 시킨 것이 옳다는 뜻이 아니다.

그래서 이력 카테고리 하나만 걸었다. 천장이 20%에서 30% 로 올랐고, 모델 없이 벡터 상위 다섯 개만 내면 30명 기준 13.3%에서 23.3%, 300명 기준 10.3%에서 13.7% 가 됐다. 후보를 42개로 좁혔는데 모델에게 주는 토큰은 그대로라, 값이 안 드는 개선이었다.

그런데 모델을 얹으니 13.3% 로 도로 내려왔다. 정답이 후보 안에 있던 아홉 명을 하나씩 뜯어보니 이유가 다 적혀 있었다 — 벡터가 다섯 개 안에 넣어둔 일곱 명 중 넷을 모델이 빼버렸고, 대신 9위에 있던 하나를 끌어올렸다. 하나 건지고 넷 떨어뜨렸다.

같은 채점기를 상용 모델로 돌려봤다. 이번에는 일곱 명을 그대로 지켜 23.3% 가 나왔다. 형식도 30명 전원이 다섯 개를 다 냈고 1.5분 만에 끝났다.

그래서 정직한 결론은 이렇게 갈린다.

작은 모델은 망친다. 차려준 것을 빼버린다. 큰 모델은 본전이다. 벡터가 이미 낸 23.3% 를 그대로 낼 뿐, 천장 30% 로는 못 간다. 6위와 9·10위에 있던 세 명은 아무도 못 끌어올렸다.

그럴 거면 모델을 왜 부르나 — 이게 이 편이 남기는 제일 불편한 질문이다. 지금 우리는 모델에게 이력과 후보를 던져놓고 「좋은 순서대로」라고만 했다. 모델이 값을 더할 자리를 우리가 안 만들어준 것일 수 있다.

다음 편에서 그 자리를 만든다. 후보를 몇 개 줄지, 이유를 짧게 시키면 어떻게 되는지, 프롬프트에 「이미 산 것과 비슷한 것 말고 다음에 살 것」을 넣으면 달라지는지 — 전부 hit@5 로 판정한다. 「좋아 보인다」는 금지다.

판정 기준은 이미 정해져 있다. 벡터만으로 23.3% 가 나온다. 무엇을 고치든 그 숫자를 못 넘으면 모델을 부를 이유가 없고, 넘어야 할 곳은 천장 30% 다.