Ghi Log LLM Chuẩn Production: 9 Quy Tắc Chúng Tôi Đang Áp Dụng [2026]

Ghi Log LLM Chuẩn Production: 9 Quy Tắc Chúng Tôi Đang Áp Dụng [2026]

Chín best practice ghi log LLM dưới đây là những quy tắc mà stack production của chúng tôi thực sự vận hành: mỗi tháng chúng tôi ghi log 1,2 triệu request LLM trên bốn service, và mọi request đều hạ cánh trong Grafana Loki dưới dạng một dòng JSON duy nhất với model, tokens, latency, cost_usd và trace_id. structlog 25.4.0 viết bản ghi, Presidio che PII trước, và toàn bộ pipeline này là nửa logging trong stack observability của chúng tôi.

Ý chính

• Ghi log mọi request LLM dưới dạng JSON có cấu trúc với 14+ trường định danh, không bao giờ dùng text tự do.
• Che PII trước khi ghi log bằng Presidio hoặc công cụ tương đương, không phải che sau.
• Gắn thuộc tính OpenTelemetry GenAI semantic convention vào mọi trace.
• Ở mức 1 triệu request/ngày, cùng 60GB đó tốn $108/tháng trên Datadog, $30 trên Loki, $1,20 trên ClickHouse.

Ghi Log LLM Thực Chất Là Gì (Và Vì Sao "Cứ Ghi Hết Mọi Thứ" Sẽ Thất Bại)

Ghi log LLM nghĩa là thu thập một bản ghi có cấu trúc cho mọi request và response của model: prompt, completion, số token, latency, chi phí, và trace gắn tất cả những thứ đó với một phiên người dùng. Đây không phải logging hạ tầng. CPU, bộ nhớ và pod restart thuộc về stack metrics của bạn; bài này chỉ nói về bản ghi ở cấp request, thứ giúp bạn debug, tính chi phí và audit hành vi của model.

Thói quen "cứ ghi hết mọi thứ" rất khó bỏ, và nó đắt đỏ. Đầy đủ prompt và completion ở mức 1 triệu request mỗi ngày tạo ra khoảng 60GB text mỗi tháng, và một phần trong số text đó là PII của khách hàng mà bạn đang lưu trữ vô thời hạn. Nguyên tắc tối thiểu hoá dữ liệu trong Điều 5 GDPR yêu cầu dữ liệu cá nhân phải "tương xứng, liên quan và giới hạn ở mức cần thiết", và một bản dump prompt thô trượt bài kiểm tra đó ngay từ ngày đầu tiên. Ghi mọi thứ không phải một chiến lược; đó là một khoản nợ có hoá đơn hàng tháng.

9 Quy Tắc Ghi Log LLM Là Gì?

Chín quy tắc, theo đúng thứ tự mà chúng tôi sẽ triển khai: ghi log đầy đủ prompt và response với định danh đã băm hash, phát ra JSON có cấu trúc, nắm bắt số token và chi phí trên mỗi request, gắn ngữ cảnh trace OpenTelemetry, che PII trước khi ghi, sampling khi lưu lượng lớn, đặt các tầng lưu trữ, tách riêng sự kiện an toàn, và làm cho kết quả truy vấn được. Mỗi quy tắc bên dưới đều đi kèm code hoặc bảng biểu để thực thi nó.

Quy Tắc 1: Ghi Log Đầy Đủ Prompt Và Response (Dùng Hash, Không Dùng PII Thô)

Ghi log toàn bộ prompt và toàn bộ completion cho mọi request, vì log thiếu sót chính là cách bạn kết thúc bằng việc ngồi nhìn một sự cố mà không có bản ghi nào về những gì model thực sự nhìn thấy. Ngoại lệ duy nhất là danh tính: không bao giờ ghi user ID, email hay tên thật vào bản ghi. Thay vào đó, lưu một hash SHA-256 của user ID. Hash vẫn cho bạn dựng lại toàn bộ lịch sử phiên của một người dùng bằng một tra cứu offline, trong khi bản thân dòng log hoàn toàn vô dụng với bất kỳ ai không được phép đọc. Logic tương tự với system prompt: băm hash, ghi log cái hash, và giữ plaintext trong prompt registry, nơi nó vốn đã được version-control.

Quy Tắc 2: Dùng JSON Có Cấu Trúc: Mọi Trường Đều Có Tên, Không Có Text Tự Do

Với best practice ghi log LLM trong Python hay bất kỳ ngôn ngữ nào khác, structured logging bằng JSON là điều không thể thoả hiệp: mọi trường đều có tên, có kiểu và truy vấn được, không có gì được đổ ra dưới dạng chuỗi format. Một dòng text tự do kiểu INFO called gpt-4o, took 812ms chỉ có thể grep. Một bản ghi JSON có thể được tổng hợp theo model, cộng dồn theo chi phí, và join với trace. Chính best practice production của OpenAI cũng thúc đẩy cùng một ý tưởng: thu thập metadata có cấu trúc ở tầng SDK thay vì dùng lệnh print.

Đây là schema mà mọi service của Techsy phát ra, mười bốn trường:

{
  "request_id": "req_01J9XK4M7Q",
  "timestamp": "2026-07-18T09:24:31.482Z",
  "environment": "production",
  "model": "claude-sonnet-4-20250514",
  "prompt_tokens": 1284,
  "completion_tokens": 396,
  "latency_ms": 812,
  "cost_usd": 0.0098,
  "system_prompt_hash": "sha256:9f2c1a4e...",
  "user_id_hash": "sha256:b7e4d831...",
  "rag_sources": ["kb/pricing-2026.md", "kb/refund-policy.md"],
  "guardrail_result": "pass",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7"
}

Ba trường cần một lời giải thích. cost_usd được tính tại thời điểm request từ số token và mức giá công bố của model, không bao giờ được điền sau bằng một job chạy đêm. Hai trường hash là sự thoả hiệp của Quy Tắc 1: tương quan được offline, mờ đục trong log. Còn trace_id và span_id là các giá trị W3C trace-context, cũng chính là nội dung của Quy Tắc 4.

Nếu bốn service gọi provider trực tiếp nghe như bốn nơi phải instrument, thì một proxy LiteLLM sẽ tập trung hoá việc đó: một hook logging duy nhất đứng trước mọi provider.

Quy Tắc 3: Nắm Bắt Số Token Và Chi Phí Trên Mỗi Request

Theo dõi token usage thuộc về chính dòng log, không phải trong một job kho dữ liệu chạy vào ngày mai. Mọi provider trả về số token input và output trong response; nhân với mức giá trên mỗi token của model tại đúng thời điểm đó và viết cost_usd vào bản ghi. Giá thay đổi, và khác nhau giữa token input được cache với token mới, nên tính chi phí sau này bằng một bảng giá tĩnh sẽ âm thầm viết lại lịch sử. Khi mọi dòng đều có chi phí, "feature nào đang đắt?" trở thành một truy vấn một dòng thay vì một dự án tài chính, và nó nuôi trực tiếp vào việc giảm chi tiêu API LLM.

Quy Tắc 4: Gắn Ngữ Cảnh Trace (OpenTelemetry GenAI Semconv)

Một dòng log không có trace ID là một đứa trẻ mồ côi: bạn đọc được nó, nhưng không thể biết lần retry nào, bước RAG nào, hay lượt hội thoại nào của người dùng đã sinh ra nó. Cách sửa là GenAI semantic conventions của OpenTelemetry, bộ tên thuộc tính chuẩn để instrument các lời gọi model. Phát ra log bên trong một span đang hoạt động và trace_id cùng span_id sẽ tự gắn vào, để một cú click trong Grafana đưa bạn từ thác trace thẳng tới bản ghi thô.

Những thuộc tính đáng để đặt trên mọi span gen_ai:

from opentelemetry import trace

tracer = trace.get_tracer("ai-sdr")

with tracer.start_as_current_span("chat.completion") as span:
    span.set_attribute("gen_ai.system", "anthropic")
    span.set_attribute("gen_ai.request.model", "claude-sonnet-4-20250514")
    response = client.messages.create(**payload)
    span.set_attribute("gen_ai.usage.input_tokens", response.usage.input_tokens)
    span.set_attribute("gen_ai.usage.output_tokens", response.usage.output_tokens)
    span.set_attribute("gen_ai.response.finish_reasons", [response.stop_reason])
    log.info("llm.request", cost_usd=cost)  # Rule 2 record, trace IDs auto-attached

Quy Tắc 5: Che PII Trước Khi Ghi Log

Che PII phải diễn ra trước khi bản ghi được viết, không phải xoá sau. Một khi địa chỉ email đã nằm trong Loki, nó cũng nằm luôn trong các bản backup object-storage của bạn, và "chúng tôi xoá sau" không phải câu trả lời GDPR chấp nhận được. Trong thiết lập của chúng tôi, Microsoft Presidio chạy như một processor của structlog và chặn được 94% email và số điện thoại trước khi chúng chạm Loki; những ca lọt lưới gần như đều do định dạng lạ, và chúng tôi vá thành các recognizer tuỳ chỉnh mỗi khi phát hiện.

Toàn bộ hook chỉ có mười lăm dòng:

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

PII_ENTITIES = ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER", "CREDIT_CARD", "IBAN_CODE"]

def redact_pii(text: str) -> str:
    results = analyzer.analyze(text=text, language="en", entities=PII_ENTITIES)
    return anonymizer.anonymize(text=text, analyzer_results=results).text

# In the structlog processor chain, before JSONRenderer:
# event_dict["prompt"] = redact_pii(event_dict["prompt"])

Khâu che PII nằm cùng tầng pipeline với các bộ lọc input và output của bạn, và nó phải được kiểm thử theo cùng cách. Pipeline guardrail của chúng tôi coi một email rò rỉ trong log là một eval thất bại, không phải một chú thích vận hành.

Quy Tắc 6: Sampling Thông Minh Khi Lưu Lượng Lớn

Dưới khoảng 100K request mỗi ngày, ghi log mọi thứ. Trên mức đó, ghi log toàn bộ lưu lượng là một thứ thuế lưu trữ đánh vào dữ liệu bạn sẽ không bao giờ đọc, và sampling là cách bạn giữ lại những bản ghi quan trọng. Cái bẫy: random sampling là lựa chọn tệ nhất cho traffic LLM, vì lỗi, lời từ chối và những request năm đô la hiếm gặp theo định nghĩa, nên một tỷ lệ đồng nhất 10% sẽ vứt bỏ chính xác những sự kiện mà bạn cần debug. Sample theo kết quả, không phải theo tung đồng xu.

Một thiết lập phổ biến là theo luật ở hai biên (production và tenant doanh nghiệp: luôn ghi log) cộng với tail-based ở giữa. Góc nhìn riêng của logging cho framework này: các trường guardrail_result và cost_usd chính là tín hiệu sampling, và chúng đã có sẵn nếu bạn tuân theo Quy Tắc 2 và 8.

Quy Tắc 7: Đặt Chính Sách Lưu Trữ Trước Khi Bạn Cần Tới Nó

Chính sách lưu trữ log là quyết định bạn đưa ra khi đang bình tĩnh, vì phương án còn lại là đưa ra nó trong một buổi rà soát chi phí với lưu lượng gấp đôi. Nguyên tắc giới hạn lưu trữ trong Điều 5 GDPR nói rằng dữ liệu cá nhân không nên được giữ "lâu hơn mức cần thiết", và trong thực tế điều đó có nghĩa là lưu trữ phân tầng:

Hot trả lời "chuyện gì xảy ra mười phút trước?" nhanh và đắt; cold trả lời "chúng tôi đã nói gì với khách hàng này vào tháng Ba?" chậm và rẻ. Xoá đúng lịch, tự động, nếu không các tầng chỉ là một hình vẽ.

Quy Tắc 8: Ghi Log Sự Kiện Guardrail Và An Toàn Riêng Biệt

Sự kiện an toàn (guardrail chặn, từ chối, vi phạm chính sách) không phải telemetry; chúng là bản ghi audit, và chúng thuộc về một luồng riêng. Ba lý do. Cảnh báo: một đợt tăng vọt prompt injection bị chặn phải page ai đó, và bạn không thể tinh chỉnh cảnh báo đó giữa 1 triệu dòng thường nhật. Lưu trữ: compliance có thể yêu cầu bản ghi an toàn sống lâu hơn log debug nhiều năm. Truy cập: auditor nhận luồng an toàn, không phải toàn bộ firehose của bạn. Gắn nhãn phán quyết trong bản ghi chính (guardrail_result: "block") và định tuyến toàn bộ bản ghi sang luồng riêng. Những gì được tính là sự kiện an toàn nằm trong hướng dẫn của chúng tôi về sự kiện guardrail.

Quy Tắc 9: Làm Cho Log Truy Vấn Được, Chứ Không Chỉ Được Lưu

Một log mà bạn không thể truy vấn trong vòng chưa đầy một phút là một bản backup, không phải tín hiệu observability. Truy vấn được nghĩa là các trường được index, một ngôn ngữ truy vấn mà người on-call của bạn thực sự biết, và dashboard được dựng trước khi sự cố xảy ra. Chúng tôi chạy Loki và truy vấn nó hơn 30 lần mỗi tuần cho các bất thường chi phí, suy giảm latency, và "cho tôi xem mọi lời từ chối của tenant X ngày hôm qua." Tài liệu Grafana Loki là tham chiếu cho cú pháp; pattern đáng đồng tiền là lọc trực tiếp trên các trường JSON đã parse:

{service="ai-sdr"} |= "llm.request" | json
  | model = "claude-sonnet-4-20250514"
  | cost_usd > 0.05
  | line_format "{{.timestamp}} {{.request_id}} ${{.cost_usd}} {{.latency_ms}}ms"

Năm dòng, không cần export sang notebook. Nếu store hiện tại của bạn không làm được điều đó, thì nó chính là vấn đề cần sửa trước tiên.

Chúng Tôi Thực Sự Ghi Log Gì Trong Production

Đủ lý thuyết rồi. Đây là cấu hình đã lược bỏ thông tin nhạy cảm từ pipeline AI SDR của chúng tôi, service đứng sau con số 1,2 triệu request mỗi tháng ở phần mở đầu. Nó chạy structlog 25.4.0 render JSON, chuyển tới Grafana Cloud Loki qua Promtail. Model trên pipeline này là claude-sonnet-4-20250514, và mọi lời gọi đều đi qua đúng chuỗi processor của Quy Tắc 2 và 5:

import structlog

structlog.configure(
    processors=[
        structlog.contextvars.merge_contextvars,
        structlog.processors.add_log_level,
        structlog.processors.TimeStamper(fmt="iso"),
        redact_pii,          # Rule 5: Presidio, before serialization
        add_otel_trace_ids,  # Rule 4: trace_id + span_id from the active span
        structlog.processors.JSONRenderer(),
    ],
)
log = structlog.get_logger()

Hai con số từ quý đầu tiên với thiết lập này. Lượng ingest hàng tháng ổn định ở 47GB trên bốn service, và latency ghi log p95 là 3ms, nghĩa là pipeline không thêm gì đáng kể vào thời gian request.

Thay đổi cấu hình tự hoàn vốn: chúng tôi thêm cost_usd vào mọi bản ghi log trong tháng 3 năm 2026. Trong vòng một tuần, chúng tôi phát hiện một prompt template đang đốt $340/tháng trong các vòng lặp retry. Một lỗi API thoáng qua kích hoạt ba lần retry, mỗi lần gửi lại toàn bộ ngữ cảnh 4.000 token. Log biến nó thành một truy vấn một dòng; nếu không có chi phí trên mỗi request, nó sẽ chỉ lộ diện như một khoản mục không lời giải thích trong buổi rà soát ngân sách quý sau.

Lưu Trữ Log LLM Tốn Bao Nhiêu Ở Quy Mô Lớn?

Ở mức 1 triệu request mỗi ngày, lưu trữ log LLM tốn khoảng $1,20 đến $108 mỗi tháng cho cùng một lượng dữ liệu, tuỳ thuộc vào store. Bài toán: một bản ghi có cấu trúc đầy đủ trung bình khoảng 2KB, vậy 1 triệu request mỗi ngày là 2GB mỗi ngày, hay 60GB mỗi tháng. Mức giá do nhà cung cấp công bố dưới đây (tháng 7 năm 2026) là chi phí của 60GB đó trên ba backend phổ biến.

Nguồn: giá Datadog, Grafana Loki, và tài liệu observability của ClickHouse.

Hai lưu ý, vì đây là tính toán của chúng tôi từ mức giá của nhà cung cấp, không phải benchmark chúng tôi tự chạy. Thứ nhất, con số của Datadog giả định bạn index mọi thứ; hầu hết các team chỉ index một tập con và trả ít hơn nhiều, trong khi Loki và ClickHouse chủ yếu tính phí cho những gì bạn lưu. Thứ hai, mức $1,20 của ClickHouse self-host giấu một hoá đơn thật: compute để chạy cluster và giờ công kỹ sư để vận hành nó. Ở mức 60GB mỗi tháng, một dịch vụ managed gần như luôn là câu trả lời rẻ hơn xét trên tổng chi phí. Self-host bắt đầu hợp lý từ khoảng 1TB mỗi tháng trở lên, nơi khoảng cách trên mỗi GB lấn át chi phí vận hành.

Khoảng cách mới là bài học. Ở mức 1 triệu request mỗi ngày, chênh lệch giữa Datadog có index và ClickHouse self-host là khoảng 90 lần: $108 so với $1,20 cho cùng 60GB. Hãy chọn store ở thời điểm thiết kế kiến trúc, không phải sau khi hoá đơn tới.

Nên Chọn Công Cụ Ghi Log Nào?

Với hầu hết các team, lựa chọn quy về bốn phương án: một nền tảng bản địa cho LLM (Langfuse hoặc LangSmith), một công cụ ở tầng proxy (Helicone), hoặc một pipeline OpenTelemetry thuần chạy trên hạ tầng bạn đã có. Bảng dưới bao quát các điểm quyết định thực sự khác nhau; dashboard, playback và versioning prompt là tiêu chuẩn mặc định ở cả bốn.

Quan điểm của chúng tôi, nói thẳng: chúng tôi chạy OTel bản địa cộng Loki vì chúng tôi đã có sẵn stack Grafana cho mọi thứ khác, và thêm một nguồn dữ liệu nữa vẫn hơn là nhận thêm một vendor thứ tư. Nếu bạn bắt đầu từ số không, chưa có stack observability nào, thì mô hình tracing của Langfuse cùng gói miễn phí của nó là con đường nhanh nhất để có ích, và lựa chọn self-host giữ cho cánh cửa rút lui luôn mở. Nếu bạn đang chọn giữa hai nền tảng bản địa cho LLM hàng đầu, bài so sánh Langfuse và LangSmith của chúng tôi chạy toàn bộ phép so sánh. Và nếu ghi log chỉ là một mảnh của một quyết định monitoring lớn hơn, bài so sánh toàn bộ nền tảng bao quát trường rộng hơn.

Những Lỗi Ghi Log LLM Phổ Biến Nhất Là Gì?

Sáu lỗi chiếm phần lớn các thiết lập ghi log LLM hỏng hóc mà chúng tôi từng xem qua. Mỗi lỗi đều rẻ để tránh nếu bạn bắt được nó trước khi lưu lượng log bắt được bạn:

• Ghi log PII thô không che. Phổ biến nhất và đắt đỏ nhất. Một bản export hỗ trợ khách hàng hoặc một bucket bị lộ biến log prompt thành một sự cố bảo vệ dữ liệu. Che trước khi ghi (Quy Tắc 5), không phải khi đọc.
• Không có chính sách lưu trữ. Lưu trữ vô thời hạn là mặc định ở khắp nơi, và nó âm thầm nhân đôi hoá đơn của bạn mỗi năm. Nếu bạn không bao giờ xoá, bạn không có một hệ thống ghi log; bạn có một kho lưu trữ mắc bệnh vĩ cuồng.
• Log text không cấu trúc. Output print mà bạn chỉ có thể grep hoạt động ở quy mô demo và sụp đổ ở mức 100K request mỗi ngày, khi "tìm mọi request thất bại của model X" trở thành một buổi chiều viết shell script thay vì một truy vấn.
• Chỉ ghi log lỗi. Request thành công là đường cơ sở để bạn phát hiện trôi dạt, và chúng là nguyên liệu thô của pipeline evaluation. Ghi log cả những lần thành công, sample nếu lưu lượng buộc phải thế.
• Bỏ qua trường chi phí. Không có cost_usd trên mỗi request nghĩa là không có cảnh báo chi phí, không có quy kết theo từng feature, và vòng lặp retry $340/tháng từ phần production ở trên vẫn vô hình cho tới hoá đơn hàng quý.
• Không có tương quan trace. Log không kết nối với span biến việc debug agent đa bước thành trò đoán mò. Nếu dòng log của bạn thiếu trace_id, Quy Tắc 4 là cách sửa.

Về Tác Giả

Mert Batur là Co-Founder của Techsy.io, nơi team xây dựng AI agent, hệ thống automation và pipeline voice/SDR cho khách hàng B2B. Anh viết về stack công cụ LLM mà team Techsy thực sự dùng trong production. Kết nối trên LinkedIn.

Câu Hỏi Thường Gặp

Mỗi Request LLM Cần Ghi Log Những Gì?

Tối thiểu: toàn bộ prompt và completion với PII đã che, tên model, số token input và output, latency, chi phí tính bằng USD, định danh người dùng đã băm hash, và trace ID cùng span ID của OpenTelemetry. Thêm ID nguồn RAG và phán quyết guardrail nếu pipeline của bạn có những giai đoạn đó. Mười bốn trường có tên, một dòng JSON cho mỗi request.

Định Dạng Tốt Nhất Cho Log LLM Là Gì?

JSON có cấu trúc, một object cho mỗi request, với mọi trường được đặt tên rõ ràng. Log text tự do chỉ có thể grep; bản ghi JSON có thể được tổng hợp theo model, cộng dồn theo chi phí và join với trace. Phát ra bản ghi bằng một structured logger như structlog trong Python hoặc pino trong Node, và render nó bằng một JSON serializer, không bao giờ bằng string formatting.

Xử Lý PII Trong Log LLM Như Thế Nào?

Che trước khi ghi log, không phải sau. Chạy prompt và completion qua một detector như Microsoft Presidio bên trong pipeline ghi log của bạn, thay tên, email và số điện thoại bằng các token như <EMAIL_ADDRESS>. Một khi PII thô chạm tới log store của bạn, nó cũng nằm trong backup, và việc xoá hồi tố hiếm khi thoả mãn bài kiểm tra tối thiểu hoá của GDPR.

Lưu Trữ Log LLM Tốn Bao Nhiêu Ở Quy Mô Lớn?

Với 1 triệu request mỗi ngày, khoảng 60GB mỗi tháng ở mức 2KB mỗi bản ghi, hãy tính khoảng $108/tháng theo mức giá LLM Observability có index của Datadog, $30/tháng trên Grafana Cloud Loki, hoặc khoảng $1,20/tháng lưu trữ S3 nén cho ClickHouse self-host cộng compute. Đó là mức giá do nhà cung cấp công bố tính đến tháng 7 năm 2026; self-host cộng thêm thời gian kỹ sư.

OpenTelemetry GenAI Semantic Conventions Là Gì?

Đó là bộ tên thuộc tính chuẩn của OpenTelemetry để instrument các lời gọi LLM: gen_ai.system cho provider, gen_ai.request.model cho model, gen_ai.usage.input_tokens và output_tokens cho số token, và gen_ai.response.finish_reasons cho lý do dừng sinh. Dùng chúng nghĩa là mọi backend tương thích OTel, từ Jaeger tới Tempo tới Langfuse, đều đọc được trace của bạn mà không cần parser tuỳ chỉnh.

Sample Log LLM Như Thế Nào Khi Traffic Cao?

Giữ lại mọi lỗi, mọi lần guardrail chặn, và mọi request trên một ngưỡng chi phí, rồi sample phần còn lại. Cách tiếp cận tail-based này bảo toàn những sự kiện hiếm mà bạn thực sự debug, trong khi random sampling đồng nhất vứt bỏ chúng với cùng tỷ lệ như traffic nhàm chán. Dưới 100K request mỗi ngày, bỏ qua sampling hoàn toàn và ghi log mọi thứ.

Nên Lưu Trữ Log LLM Bao Lâu?

Phân tầng: 7 ngày hot cho debug trực tiếp, 30 ngày warm cho rà soát sự cố và phân tích chi phí, và tối đa 1 năm cold trong object storage nén cho compliance và audit. Nguyên tắc giới hạn lưu trữ của GDPR cấm giữ dữ liệu cá nhân lâu hơn mức cần thiết, nên ghép mỗi tầng với việc xoá tự động thay vì dọn dẹp thủ công.

Khác Nhau Giữa Ghi Log LLM Và Tracing LLM Là Gì?

Log là một bản ghi phẳng của một sự kiện: request này đã xảy ra, với những trường này. Trace là một cây quan hệ nhân quả của các span trên toàn bộ đường đi của request, chẳng hạn retrieval, rồi lời gọi model, rồi hai lời gọi tool. Log cho bạn biết chuyện gì; trace cho bạn biết ở đâu và vì sao. Thiết lập production phát ra cả hai, nối với nhau bằng trace_id.

Kết Luận

Tóm lại: ghi log mọi request dưới dạng JSON có trường định danh, tính chi phí tại thời điểm request, gắn ngữ cảnh trace OTel, che PII trước khi ghi, sample theo kết quả khi bạn vượt 100K request mỗi ngày, và chọn một store mà bạn thực sự truy vấn được. Chín quy tắc được sắp thứ tự để bạn có thể áp dụng mỗi quy tắc một sprint, và Quy Tắc 2, 4 và 5 là ba quy tắc hoàn vốn nhanh nhất. Nếu bạn đang chọn cả stack monitoring rộng hơn quanh các log này, hãy bắt đầu với bài tổng hợp của chúng tôi về các nền tảng observability AI tốt nhất. Và nếu bạn cần trợ giúp để nối structured logging cho stack LLM của mình, hãy nhận tư vấn miễn phí.