1Đề bài tập lớn2Ví dụ thực hành Kế hoạch và dự án Porto

Dự án mẫu: Phân tích Porto

Một nhóm phân tích muốn giúp đơn vị quản lý du lịch hiểu nguồn cung chỗ ở, lịch còn sẵn và trải nghiệm khách. Dự án chọn Porto, xây một quy trình nhỏ có thể chạy lại, rồi dùng kết quả để kiểm tra từng quyết định xử lý.

Đây là dự án độc lập trên dữ liệu công khai. Mẫu được chọn có seed, không dùng danh sách thành viên, phân công hoặc tập ID của một nhóm học phần. Lịch dưới đây là kế hoạch đề xuất, còn kết quả đã chạy được trình bày riêng ở cuối trang.

Tải mã nguồn dự án · Tải bảng kế hoạch để tự cập nhật

1. Phạm vi và lựa chọn ban đầu

Lựa chọn của dự án	Cách thực hiện
Địa bàn và dữ liệu	Porto, tiền tệ EUR. Bốn mốc 21/09/2025, 25/12/2025, 26/03/2026 và 23/06/2026.
Tập listing	Chọn 120 ID từ giao các listing có ở cả bốn mốc, bằng seed 20261019. Lưu danh sách để chạy lại.
Thời gian trong calendar	Giữ 30 ngày tính từ từng ngày snapshot. Cửa sổ dài bằng nhau nhưng thuộc những thời điểm khác nhau.
Giá	Chỉ phân tích giá chào ở mốc cuối. Không gọi giá chào là doanh thu đã thu hoặc ADR thực thu.
Review cho LLM	Dự kiến tối đa 300 review duy nhất của tập listing. Giữ nguyên văn bản trong đầu vào cục bộ.
Nhãn tham chiếu	Chuẩn bị 160 hàng nhãn trống, dự kiến 40 để điều chỉnh và 120 để đánh giá cuối. Người đọc tự gán trước khi xem dự đoán.
Công cụ	Python và thư viện chuẩn cho tải, xử lý bảng, thống kê, HTTP và sinh SVG. Cấu hình JSON giúp đổi tham số.

Chọn giao ID giúp so cùng một nhóm listing qua các mốc, nhưng loại các listing mới xuất hiện hoặc biến mất. Vì vậy, các kết quả mô tả nhóm tồn tại qua bốn mốc, không đo tăng trưởng nguồn cung toàn thành phố. Đây là giới hạn cần giữ trong báo cáo.

Các con số mẫu và thời gian là lựa chọn của dự án minh họa. Khi làm bài chính thức, phải dùng đầu vào và điều kiện được giao cho nhóm.

2. Kiến trúc và quyết định QA

Đầu vào, hai nhánh xử lý và sản phẩm cuối

Cấu hình điều khiển toàn bộ lần chạy

Thành phố · Snapshot · Mã listing/review · Quy tắc QA · Tham số LLM

1. 01 · BronzeGiữ dữ liệu gốc

   CSV nén và GeoJSON đúng ngày, kèm nguồn và checksum.

   data/raw/→
2. 02 · SilverChuẩn hóa và gắn cờ

   Lọc đúng mã. Kiểm khóa, kiểu dữ liệu và điều kiện dùng dòng.

   data/processed/→
3. 03 · GoldTính chỉ số và sinh hình

   KPI theo khu vực, thời gian và LLM. Xuất hình và báo cáo.

   kpi_*.csv · figures/

Từ review đã chọn ở Silver

Nhãn tay
Baseline + LLM→Đánh giá
trên cùng mẫu→KPI và hình LLM
đưa vào Gold

Nhãn người là dữ liệu tham chiếu. Dự đoán lỗi và phần chưa có kết quả vẫn phải được báo rõ.

Từ cờ QA ở SilverDòng cần xem lại

Giữ nguyên giá trị và lý do. Chỉ giới hạn những phân tích chịu ảnh hưởng.

reports/qa_report.csv

Ba tên Bronze, Silver và Gold chỉ ba trạng thái: Dữ liệu nguyên trạng, dữ liệu đã chuẩn hóa và bảng phục vụ phân tích. Trong dự án này chúng tương ứng với tệp và bước Python, không kéo theo yêu cầu dùng Spark, Databricks hoặc cơ sở dữ liệu.

Những kiểm tra thực sự cần cho mẫu Porto

Mẫu đã được đọc và tính thử trước khi chọn quy tắc. Bốn quyết định dưới đây phục vụ trực tiếp các kết quả đang làm:

Quan sát và câu hỏi cần giải quyết	Quyết định trong bản mẫu
Một listing xuất hiện qua bốn snapshot. Có phải hàng trùng cần xóa?	Không. Khóa là snapshot và listing. Giữ bốn lần quan sát để so sánh đúng đối tượng. Chỉ từ chối khóa lặp trong cùng mốc.
KPI đếm và KPI giá cần cùng số hàng không?	Không. Giữ 120 listing để đếm, dùng 111 giá hợp lệ mốc cuối để tính trung vị. Không xóa listing khỏi toàn bộ phân tích chỉ vì không dùng được giá.
Mỗi hàng calendar có cùng ý nghĩa với một listing không?	Không. Một hàng là một listing tại một ngày. Chọn đúng cửa sổ, đếm ngày có trạng thái hợp lệ và tính theo từng listing trước khi lấy trung bình.
Review lặp trong nhiều snapshot có phải nhiều ý kiến?	Không. Dùng review ID và nội dung để nhận diện, giữ dấu vết xuất hiện nhưng chỉ chọn một lần cho mẫu đánh giá.

Giá hợp lệ mốc cuối trong mẫu nằm từ 43,50 đến 773 EUR/đêm. Mức cao nhất chưa đủ để kết luận dữ liệu sai. Bản mẫu giữ các giá này và xem phân bố, không tự xóa theo ba độ lệch chuẩn hoặc một ngưỡng chưa có lý do.

Bản đồ hiện tổng hợp theo tên khu, không dựa vào điểm tọa độ listing. Vì vậy, ví dụ không thêm một quy trình kiểm tọa độ hay phân vùng mới không phục vụ phép tính đang làm. Khi chuyển sang bản đồ điểm, đó mới là kiểm tra cần bổ sung.

Mã kiểm tra và thời điểm ghi tác động

Cột khóa được kiểm trước khi xử lý. Giá trị không hợp lệ được giữ dấu vết và chỉ loại khỏi KPI chịu ảnh hưởng. Các nhãn ERROR, WARN hoặc INFO không thay cho việc nêu hành động cụ thể.

Số dòng và cờ QA có ngay khi đọc. Phần so sánh KPI trong qa_report.csv được hoàn thiện sau bước tính chỉ số. Vì vậy, báo cáo QA và chặng KPI có thể gối đầu, không phải chờ mọi ô báo cáo QA xong mới được tính chỉ số.

Dữ liệu thô giữ nguyên, mỗi lượt chạy có thư mục riêng. Chỉ cập nhật con trỏ kết quả gần nhất khi lượt chạy đã hoàn thành. Kiểm thử dùng fixture riêng, không có cơ chế tự thay dữ liệu thật bằng fixture.

3. Kế hoạch thực hiện và điều kiện hoàn thành

Kế hoạch gồm tám chặng, mỗi chặng có đầu ra và cách xác nhận. Có thể làm đồng thời phần gán nhãn, baseline và QA sau khi đã chốt mẫu review. Không cần chờ toàn bộ KPI xong mới chuẩn bị nhãn hoặc nối chương trình.

1. 01

   Xác định câu hỏi và dựng khung

   Ngày 1–2

   Có mục tiêu, định nghĩa chỉ số và một lệnh chạy từ đầu.

   3 việc cần làm và cách kiểm tra

   1. P01 Giới hạn phạm vi

      Chọn Porto và câu hỏi về nguồn cung, lịch sẵn có, mức giá chào và trải nghiệm khách. Ghi rõ mẫu độc lập không phải phân công của lớp.

      Bàn giao

      Bản mô tả phạm vi và giới hạn.

      Đạt khi

      Mỗi câu hỏi có dữ liệu để trả lời, không hứa đo doanh thu thật.

      Làm sau

      Có thể bắt đầu ngay

   2. P02 Phác thảo bảng kết quả

      Định nghĩa trước bảy KPI, khóa, đơn vị, mẫu số và hình dự kiến. Kiểm khả năng so sánh qua snapshot.

      Bàn giao

      Danh mục KPI và phác thảo hình.

      Đạt khi

      Giá chỉ dùng mốc cuối, review lặp không được đếm như ý kiến mới.

      Làm sau

      P01

   3. P03 Dựng chương trình điều phối

      Tạo cấu hình, thư mục, môi trường, README nháp và lệnh chạy. Nối bước dần từ đầu thay vì chờ viết xong mới ghép.

      Bàn giao

      Khung repo chạy được và ghi trạng thái từng bước.

      Đạt khi

      Một lệnh đọc cấu hình và báo rõ đầu vào còn thiếu.

      Làm sau

      P01

2. 02

   Tạo đầu vào có thể đối chiếu

   Ngày 2–4

   Có cùng một tập listing qua bốn snapshot, giữ nguyên nguồn.

   3 việc cần làm và cách kiểm tra

   1. P04 Lưu nguồn và dấu vết tải

      Tải CSV nén và GeoJSON, ghi URL, ngày, kích thước, SHA256. Đọc luồng thay vì nạp mọi bảng vào bộ nhớ.

      Bàn giao

      Tệp thô và manifest.

      Đạt khi

      Mọi tệp có dấu vết nguồn, tệp tải dở không được dùng.

      Làm sau

      P03

   2. P05 Chọn mẫu độc lập

      Chọn có seed từ giao các listing ID ở bốn mốc. Lưu tập mã và giải thích thiên lệch của nhóm tồn tại qua mọi mốc.

      Bàn giao

      Danh sách mã mẫu và mô tả cách chọn.

      Đạt khi

      Đổi thứ tự hàng nguồn không đổi mẫu đã lưu.

      Làm sau

      P04

   3. P06 Giữ đúng đơn vị quan sát

      Lọc listings/calendar theo listing ID. Theo dõi review duy nhất riêng với lần xuất hiện ở snapshot. Chuẩn hóa mã dưới dạng chuỗi.

      Bàn giao

      Ba bảng đã chọn và các khóa.

      Đạt khi

      Khóa snapshot–listing, snapshot–listing–ngày và review ID không bị lẫn.

      Làm sau

      P05

3. 03

   Xây QA theo hành động

   Ngày 4–7

   Mỗi vấn đề có cờ, quyết định và bằng chứng.

   3 việc cần làm và cách kiểm tra

   1. P07 Phân mức và hành động

      Tách lỗi làm sai cấu trúc, cảnh báo cần xem và điều kiện dùng dòng cho từng KPI. Chỉ dừng bước chịu ảnh hưởng khi cần.

      Bàn giao

      Danh mục quy tắc QA.

      Đạt khi

      Mỗi quy tắc trả lời được phát hiện gì rồi làm gì.

      Làm sau

      P06

   2. P08 Giữ dữ liệu ngoại lệ

      Giữ giá gốc, cờ chuyển đổi và lý do cách ly. Thiếu giá không làm mất listing khỏi chỉ số đếm.

      Bàn giao

      Bảng chuẩn hóa và tệp ngoại lệ.

      Đạt khi

      Không ghi đè raw, không cắt giá về ngưỡng để che ngoại lai.

      Làm sau

      P07

   3. P09 Ghi ảnh hưởng trước/sau

      Đếm dòng và đối chiếu KPI trên cùng định nghĩa, ghi rõ các quy tắc chồng lấn.

      Bàn giao

      reports/qa_report.csv.

      Đạt khi

      Mỗi thay đổi được giải thích bằng quy tắc và mẫu số.

      Làm sau

      P08, P11

4. 04

   Tính và kiểm chứng KPI

   Ngày 6–9

   Bảng kết quả có thể tính lại độc lập.

   3 việc cần làm và cách kiểm tra

   1. P10 Kiểm một trường hợp nhỏ

      Tạo dữ liệu giả định có thiếu giá, giá lớn và khóa lặp. Tính tay hoặc bằng cách độc lập để đối chiếu.

      Bàn giao

      Bộ kiểm thử công thức và mẫu số.

      Đạt khi

      Số lượng, tỷ lệ và trung vị đúng ngay cả khi mẫu số bằng 0.

      Làm sau

      P02, P07

   2. P11 Tổng hợp theo khu vực

      Tính trực tiếp từ các hàng đủ điều kiện theo thành phố mẫu và neighbourhood_cleansed. Không lấy trung bình các tỷ lệ khu khi mẫu số khác nhau.

      Bàn giao

      kpi_*.csv với giá trị, đơn vị, N và trạng thái.

      Đạt khi

      Tổng và tỷ lệ khớp phép tính độc lập.

      Làm sau

      P08, P10

   3. P12 Đối chiếu cửa sổ lịch

      Dùng cùng 30 ngày tính từ mỗi snapshot. Báo số ngày quan sát và mức đầy đủ.

      Bàn giao

      Chỉ số sẵn có cùng cửa sổ quan sát.

      Đạt khi

      Không gọi không sẵn có là đã được đặt, không gọi đây là occupancy.

      Làm sau

      P06, P10

5. 05

   Chuẩn bị và đánh giá LLM

   Ngày 4–12, làm song song với QA/KPI

   Có nhãn người, baseline và dự đoán cùng cấu trúc để so sánh.

   3 việc cần làm và cách kiểm tra

   1. P13 Viết hướng dẫn nhãn

      Chọn mẫu review duy nhất, tạo cột nhãn trống. Người đọc tự gán sentiment, khía cạnh và ngôn ngữ trước khi xem dự đoán.

      Bàn giao

      Hướng dẫn gán nhãn và nhãn tham chiếu.

      Đạt khi

      Bộ chấm cuối có ít nhất 100 review do người gán, tách tập chỉnh prompt.

      Làm sau

      P06

   2. P14 Viết hai cách dự đoán

      Chạy baseline từ quy tắc, xây adapter Gemini, kiểm cấu trúc, cache theo nội dung/mô hình/prompt và ghi lỗi có thể thử lại.

      Bàn giao

      Baseline, adapter, prompt, cache và log.

      Đạt khi

      Có thể gọi lại bằng khóa môi trường, skip không tạo kết quả giả.

      Làm sau

      P03, P13

   3. P15 Đánh giá cùng nhiệm vụ

      Chấm cả hai trên cùng nhãn người. Báo accuracy/F1, độ phủ, lỗi thiếu và ví dụ sai.

      Bàn giao

      evaluation.json và phân tích lỗi.

      Đạt khi

      Không chỉ chấm phần gọi API thành công, không dùng AI làm nhãn người.

      Làm sau

      P13, P14

6. 06

   Biến kết quả thành hình

   Ngày 10–14

   Tối thiểu năm hình có câu hỏi, đơn vị và phạm vi.

   3 việc cần làm và cách kiểm tra

   1. P16 Vẽ khu vực

      Ghép KPI theo tên khu với GeoJSON, phân biệt không có dữ liệu với giá trị 0.

      Bàn giao

      Bản đồ cùng N và chú giải.

      Đạt khi

      Khóa ghép khớp, không tô vùng thiếu như 0.

      Làm sau

      P11

   2. P17 So sánh thời gian và phân bố

      Vẽ lịch sẵn có, loại phòng, phân bố giá mốc cuối và heatmap review. Dùng nhãn và cùng quy tắc định dạng.

      Bàn giao

      Bộ hình từ chương trình.

      Đạt khi

      Không vẽ chuỗi giá bốn mốc khi chỉ được dùng giá cuối.

      Làm sau

      P11, P12

   3. P18 Tích hợp LLM

      Chỉ sau khi có dự đoán đã đánh giá mới tính KPI và hình theo cảm xúc/khía cạnh.

      Bàn giao

      KPI LLM và hình có độ phủ, mẫu số.

      Đạt khi

      Thiếu dự đoán hoặc nhãn đánh giá thì ghi đang chờ, không bịa tỷ lệ.

      Làm sau

      P15, P11

7. 07

   Viết và kiểm tra bản bàn giao

   Ngày 14–18

   Báo cáo gắn với tệp và mã nguồn cụ thể.

   3 việc cần làm và cách kiểm tra

   1. P19 Viết báo cáo theo bằng chứng

      Giới hạn PDF theo đề. Mỗi kết luận trỏ tới hình/bảng và nêu giới hạn mẫu, QA, LLM.

      Bàn giao

      PDF, từ điển dữ liệu, AI_USAGE.

      Đạt khi

      Không gọi kết quả mẫu là toàn thị trường, không gán độ tin cậy chưa đo.

      Làm sau

      P09, P16, P17, P18

   2. P20 Thử dựng lại từ đầu

      Clone vào thư mục mới, dựng Python/thư viện và chạy một lệnh với cấu hình. Kiểm khóa API, tệp đầu ra và chế độ skip.

      Bàn giao

      Biên bản chạy sạch.

      Đạt khi

      Người khác làm đúng README sẽ tạo lại các tệp đã nêu.

      Làm sau

      P19, P14

   3. P21 Kiểm tra rò rỉ và bản nộp

      Soát dữ liệu thô, bí mật, giấy phép, phiên bản và tag. Ghi commit vào báo cáo.

      Bàn giao

      Danh sách bàn giao và tag.

      Đạt khi

      Không có API key hoặc dữ liệu nhóm trong kho công khai.

      Làm sau

      P20

8. 08

   Tự bảo vệ lựa chọn và giữ thời gian dự phòng

   Ngày 19–21

   Mỗi con số đều có người giải thích được cách tạo.

   3 việc cần làm và cách kiểm tra

   1. P22 Lần theo một con số

      Chọn ngẫu nhiên kết quả, tìm về công thức, dòng đủ điều kiện, QA và snapshot.

      Bàn giao

      Ghi chú diễn giải ngắn.

      Đạt khi

      Giải thích được cả phần không trực tiếp viết.

      Làm sau

      P19

   2. P23 Thử đầu vào thay đổi

      Đổi cấu hình một snapshot hoặc kích thước mẫu để tìm ngày, đường dẫn và ngưỡng còn ghi cứng.

      Bàn giao

      Kết quả thử cấu hình khác.

      Đạt khi

      Lỗi đầu vào được báo rõ, không âm thầm tái dùng nhãn/cache sai.

      Làm sau

      P20

   3. P24 Chỉ mở rộng khi phần chính đạt

      Ưu tiên phân tích độ nhạy QA. Chỉ làm dự báo hoặc mô hình occupancy khi có dữ liệu, giả thiết và đánh giá phù hợp.

      Bàn giao

      Phụ lục tùy chọn hoặc quyết định dừng mở rộng.

      Đạt khi

      Không đánh đổi phần bắt buộc lấy một mô hình chưa có phép chấm.

      Làm sau

      P21, P22, P23

Ngày trong kế hoạch tính từ lúc bắt đầu, không thay các mốc nộp của môn. Với nhóm nhiều người, mỗi việc có người thực hiện và người kiểm tra. Người kiểm tra phải đối chiếu đầu ra với điều kiện đạt, không chỉ xác nhận mã chạy hết.

Một người tự làm có thể thay lượt kiểm tra chéo bằng phép tính độc lập trên mẫu nhỏ, bộ dữ liệu kiểm thử có đáp án biết trước và lần chạy trong thư mục mới. Cách này không thay yêu cầu nhóm 4–5 thành viên của bài nộp chính thức.

4. Thiết kế bảy KPI

Chỉ số	Định nghĩa và phạm vi
Số listing	Đếm ID phân biệt trong mẫu tại một snapshot và khu vực. Với tập giao ID cố định, chỉ số mô tả quy mô mẫu.
Tỷ lệ cho thuê cả chỗ ở	Số listing Entire home/apt chia số listing có loại phòng hợp lệ trong cùng nhóm. Báo mẫu số.
Trung vị số đêm tối thiểu	Trung vị minimum_nights của listing có giá trị hợp lệ, theo snapshot và khu vực. Đơn vị là đêm.
Mức sẵn có 30 ngày tới	Tính tỷ lệ ngày available = t trên các ngày có trạng thái hợp lệ của từng listing, rồi lấy trung bình theo listing. Kèm độ phủ lịch so với cửa sổ 30 ngày.
Trung vị giá chào mốc cuối	Trung vị price đọc được và dương ở mốc cuối, theo EUR cho một đêm như trường nguồn mô tả. Báo số listing đủ điều kiện.
Tỷ lệ listing chưa có review	Số listing có number_of_reviews = 0 chia số listing có số đếm review hợp lệ trong cùng nhóm. Không suy thành tỷ lệ khách hài lòng.
Tỷ lệ review tiêu cực từ LLM	Số review duy nhất có nhãn negative chia số review có dự đoán hợp lệ trong phạm vi xét. Báo độ phủ và chất lượng đánh giá đi kèm.

Chỉ số theo khu vực dùng neighbourhood_cleansed. Dự án công khai này không tự tạo analysis_area từ bảng của nhóm khác. Khi làm theo một bộ phân công có vùng riêng, giữ cả hai hệ vùng và đặt tên kết quả rõ ràng.

Không lấy trung bình các tỷ lệ khu vực để gọi là tỷ lệ toàn mẫu nếu mẫu số khác nhau. Hãy tính từ tổng tử số và tổng mẫu số khi đó là định nghĩa của chỉ số chung. Với trung vị, cần trở về các giá trị gốc đủ điều kiện, không lấy trung vị của các trung vị khu vực.

Đọc thêm về kiến trúc, occupancy và các gợi ý nghiên cứu

Gợi ý	Cách dùng trong dự án
Bronze → Silver → Gold	Giữ cách tách nguyên trạng, chuẩn hóa và tổng hợp. Đây là mẫu thiết kế, không phải điều kiện bắt buộc của đề.
Càng nhiều QA càng tốt	Chọn quy tắc theo hành động khi phát hiện vấn đề. Đo thời gian chạy nếu kiểm tra lớn, gộp cảnh báo có cùng nguyên nhân.
Mọi lỗi Bronze đều dừng	Không áp dụng máy móc. Thiếu tệp bắt buộc có thể chặn bước, còn thay đổi ở cột tùy chọn có thể chỉ cần cảnh báo.
Xóa giá ngoài ba độ lệch chuẩn	Chỉ coi là cách tìm ứng viên cần xem. Phân bố giá có thể lệch, giá cao không tự là lỗi. Giữ giá gốc và so sánh độ nhạy.
Ép occupancy vào đoạn 0–1	Không dùng clip() để che công thức hoặc dữ liệu sai. Tìm nguyên nhân trước khi quyết định loại khỏi chỉ số nào.
Giá chia số đêm tối thiểu	Không dùng để tạo giá theo đêm. minimum_nights là điều kiện lưu trú, không phải số đêm mà giá nguồn đang bao gồm.
Review chia tuổi listing để ước occupancy	Chưa đủ cơ sở. Review không phải toàn bộ lượt đặt, ngày review đầu không chắc là ngày bắt đầu kinh doanh và độ dài lưu trú phải có giả thiết.
RevPAR từ giá chào và lịch không sẵn có	Không gọi là RevPAR thực thu. Thiếu doanh thu và đêm bán thực tế. Chỉ mô hình hóa khi có cơ sở và phân tích độ nhạy riêng.
Bốn snapshot thành mùa vụ theo tháng	Bốn quan sát không tự tạo lịch sử tháng đầy đủ. Cửa sổ lịch ở mỗi mốc nhìn về tương lai, không phải doanh thu tháng đã xảy ra.

Vì sao không tùy tiện nhân hai số trung bình?

Xét hai đơn vị giả định có cùng số đêm cung ứng. Giá mỗi đêm lần lượt là 90 và 110, tỷ lệ bán lần lượt là 0,2 và 0,8. Doanh thu trên mỗi đêm cung ứng chung là trung bình của 18 và 88, bằng 53.

Nếu lấy giá trung bình 100 nhân tỷ lệ trung bình 0,5, ta được 50. Hai kết quả khác nhau vì việc lấy trung bình đã làm mất quan hệ giữa giá và lượng bán. Với dữ liệu giao dịch thật, phải gộp doanh thu và số đêm theo cùng định nghĩa rồi tính chỉ số.

Định nghĩa ADR và RevPAR có thể đối chiếu tại STR/CoStar. Mô hình occupancy của Inside Airbnb cũng nêu các giả thiết riêng về tỷ lệ viết review và độ dài lưu trú, không đồng nhất với dữ liệu đặt phòng quan sát được.

5. Chạy chương trình và đọc trạng thái

Giải nén mã nguồn vào một thư mục mới, đọc README và dùng đúng Python ghi trong .python-version. Lệnh chạy phần dữ liệu và baseline mà chưa gọi dịch vụ LLM là:

python run_pipeline.py --config configs/porto.json --skip-llm

Các tệp nguồn tải về được giữ cục bộ và bỏ qua khi commit. Lần đầu cần mạng và dung lượng đĩa cho các bộ đầy đủ của thành phố, dù chỉ giữ một mẫu nhỏ trong bảng xử lý. Lần chạy lại dùng tệp đã tải nếu chúng vẫn vượt qua kiểm tra.

Chế độ --skip-llm không có nghĩa hoàn thành phần LLM. Để chạy thật, làm theo README để đặt khóa API trong biến môi trường, chọn mô hình còn khả dụng, kiểm hạn mức và gọi chế độ LLM. Tệp nhãn tay vẫn cần người đọc hoàn thành trước khi có bảng accuracy/F1 đáng tin.

Những đầu ra cần tìm sau khi chạy

• Manifest: Từng URL, snapshot, số byte và checksum của nguồn.
• Bảng chuẩn hóa: Listing theo snapshot, calendar theo ngày và review duy nhất, kèm các cột khóa.
• Báo cáo QA: Quy tắc, điều kiện, hành động, số dòng và ảnh hưởng KPI.
• Bảng KPI: Giá trị, đơn vị, mẫu số, snapshot và trạng thái sẵn sàng.
• Hình SVG: Sinh từ bảng kết quả, có tên trục, chú giải và phạm vi mẫu.
• Tệp nhãn tay: Các cột nhãn trống, tách khỏi dự đoán baseline/LLM.
• Báo cáo đánh giá: Có kết quả khi đủ nhãn người và dự đoán. Nếu chưa đủ, ghi đang chờ cùng lý do.

6. Kết quả thực hành trên Porto

Lượt chạy ngày 19/10/2026 đã đọc đủ bốn snapshot, chọn 120 listing, tạo 480 hàng listing theo mốc và xử lý 13.842 hàng lịch trong các cửa sổ đã chọn. Baseline đã chạy trên 300 review duy nhất.

Ở mốc 23/06/2026, mẫu có 101 listing cho thuê cả chỗ ở, tương ứng 84,17%. Trung vị giá chào là 109,55 EUR/đêm, tính trên 111 listing đủ điều kiện. Đây là kết quả của mẫu, không phải số đo toàn thị trường Porto.

Tải bảng KPI · Xem URL và checksum nguồn · Tải báo cáo PDF

Bắt đầu từ hai hình để đọc kết quả

Hình 3: Số listing trong mẫu theo khu vực Porto tại mốc cuối.

Hình 4: Mức sẵn có trong cửa sổ 30 ngày tới tại mỗi snapshot.

Bản đồ cho biết mẫu phân bố ở đâu. Hình lịch cho biết lượng ngày còn sẵn trong những cửa sổ tương lai khác nhau. Không đọc đường nối bốn điểm thành mùa vụ đã được chứng minh hoặc tỷ lệ đặt phòng thực tế.

Ba hình còn lại để đối chiếu loại chỗ ở, giá và review

Hình 5: Cơ cấu loại chỗ ở của mẫu tại mốc 23/06/2026.

Hình 6: Số listing theo khoảng giá chào ở mốc cuối, đơn vị EUR mỗi đêm.

Hình 7: Tỷ lệ listing chưa có review theo khu vực và snapshot.

Từ kết quả trở lại cách làm

Giữ cùng 120 listing qua bốn mốc giúp so sánh cùng đối tượng. Số listing cố định bằng 120 là hệ quả thiết kế mẫu, không chứng minh nguồn cung thành phố đứng yên. Tỷ lệ chưa có review giảm từ 14,17% xuống 9,17% trong mẫu, nhưng cũng không tự chứng minh khách hài lòng hơn.

QA của lượt chạy giữ các listing khi chúng còn dùng được cho phép đếm. Tính giá dùng riêng tập giá hợp lệ và công bố N. Chương trình không cần xóa giá cao, không bù ngày lịch và không nhân review lặp thành nhiều ý kiến mới.

Phạm vi của lần chạy và cách hoàn thiện nhánh LLM

Lượt công bố này chạy dữ liệu, KPI, năm hình và baseline, chưa gọi API LLM. Mẫu nhãn người vẫn để trống, nên không công bố accuracy/F1 hoặc tỷ lệ cảm xúc của LLM. Mã gọi API, kiểm phản hồi, cache và chấm nhãn đã được chuẩn bị để chạy theo README sau khi có đầu vào tương ứng.

Mức sẵn có tính trên các ngày có trạng thái hợp lệ của từng listing. Độ phủ từng cửa sổ được ghi trong bảng KPI. Những số này mô tả lịch công khai quan sát được, không phải giao dịch thuê phòng.

Tài liệu tham khảo

• Đề bài tập lớn Inside Airbnb.
• Inside Airbnb: Tải dữ liệu.
• Inside Airbnb: Giới hạn và mô hình occupancy.
• Microsoft Learn: Kiến trúc Medallion.
• STR/CoStar: Định nghĩa các chỉ số khách sạn.