# Tóm tắt nghiên cứu về sinh hồ sơ thiếu trong DSCons

## 1. Mục tiêu

Tài liệu này tóm tắt những gì DSCons đã có và còn thiếu cho bài toán sinh hồ sơ thiếu từ dữ liệu hiện có, với trọng tâm là `bien_ban_ban_giao_mat_bang`.

Tài liệu trả lời 4 câu hỏi:

- hiện hệ thống đã có nền gì liên quan đến hồ sơ và tái sử dụng tri thức
- dữ liệu đầu vào tối thiểu để sinh bản nháp là gì
- khoảng trống kỹ thuật và vận hành đang ở đâu
- bước tiếp theo nên ưu tiên như thế nào

## 2. DSCons hiện đã có gì

### 2.1. Có taxonomy hồ sơ theo vòng đời

Từ bộ tài liệu hồ sơ trong `docs/`, DSCons đã phân loại hồ sơ theo các stage như:

- `pre_award`
- `contracting`
- `execution`
- `payment`
- `finalization`
- `safety_quality`

Ý nghĩa:

- tài liệu được đặt trong bối cảnh nghiệp vụ rõ ràng
- có nền để biết một loại hồ sơ phục vụ bước nào trong dự án
- `bien_ban_ban_giao_mat_bang` đã nằm đúng nhóm `execution`

### 2.2. Có rule kiểm tra hồ sơ thiếu và readiness

Trong codebase đã có lớp rule/checklist cho hồ sơ theo stage, gồm:

- checklist loại tài liệu cần có
- đánh giá thiếu/đủ theo từng stage
- tính readiness phục vụ dossier report

Ý nghĩa:

- hệ thống đã biết công trình đang có gì
- đã biết còn thiếu loại hồ sơ nào
- đã có nền cho bước “phát hiện thiếu trước, sinh sau”

### 2.3. Có service báo cáo gap từ metadata đã ingest

DSCons đã có hướng xử lý:

- đọc tài liệu từ Qdrant theo `project_code`
- gom theo `doc_stage`
- nhận diện `document_type`
- xác định hồ sơ còn thiếu
- hỗ trợ readiness ở mức nghiệp vụ

Điểm mạnh:

- tốt cho tra cứu, gap analysis và readiness

Điểm còn thiếu:

- chưa có lớp chọn template cũ tương tự
- chưa có mapping field-level để sinh tài liệu mới
- chưa có workflow draft/review riêng cho generation

### 2.4. Có schema nghiệp vụ nhưng chưa đủ cho execution document generation

Repo đã có một số business object về hồ sơ, hợp đồng, thanh toán, quyết toán, participant, approval.

Tuy nhiên vẫn thiếu schema riêng cho nhóm hồ sơ thi công như:

- `bien_ban_ban_giao_mat_bang`
- `nhat_ky_thi_cong`
- `bien_ban_nghiem_thu_hien_truong`
- hồ sơ quản lý chất lượng
- hồ sơ đưa vào sử dụng

Khoảng trống chính:

- đại diện ký theo từng bên
- thời điểm và địa điểm lập biên bản
- phạm vi bàn giao
- hiện trạng thực địa
- khối chữ ký và thứ tự ký

### 2.5. Có manifest và SOP phù hợp với vận hành thật

DSCons đã có:

- manifest công trình để theo dõi hồ sơ đã có / còn thiếu / cần cập nhật
- SOP cho nhân viên dùng AI + RAG theo hướng phải kiểm tra file nguồn

Ý nghĩa:

- AI chỉ nên hỗ trợ gợi ý và tạo nháp
- nhân viên vẫn là người xác nhận dữ liệu
- phù hợp với mô hình review bắt buộc trước phát hành

### 2.6. Có metadata sâu cho retrieval và liên kết tài liệu

Metadata hiện có đã khá tốt cho:

- nhận diện công trình, gói thầu, hợp đồng
- phân loại tài liệu theo `doc_stage`, `doc_family`, `document_type`
- truy vết nguồn file
- liên kết tài liệu liên quan
- hỗ trợ readiness ở mức hồ sơ

Nhưng metadata hiện vẫn thiên về câu hỏi:

- “tài liệu này là gì”
- “tài liệu này liên quan gì”

Chưa đủ mạnh cho câu hỏi:

- “tài liệu mới cần field nào để sinh ra”

## 3. Dữ liệu đầu vào tối thiểu cho `bien_ban_ban_giao_mat_bang`

Để sinh một bản nháp dùng được, cần ít nhất 5 nhóm dữ liệu.

### 3.1. Nhận diện công trình / gói thầu / hợp đồng

Cần có tối thiểu:

- `project_name`
- `project_code` nếu có
- `package_code`
- `package_name`
- `contract_code`
- `contract_name`
- `location`

Nguồn khả dụng trong repo:

- metadata đã ingest
- manifest công trình
- schema hồ sơ/contract hiện có

### 3.2. Thông tin các bên tham gia

Tối thiểu phải có:

- bên giao
- bên nhận
- vai trò của từng bên
- người đại diện ký
- chức danh người ký

Có thể mở rộng thêm:

- tư vấn giám sát
- tư vấn thiết kế
- đại diện địa phương nếu mẫu yêu cầu

Đây là nhóm dữ liệu chưa được chuẩn hóa đầy đủ trong schema hiện tại.

### 3.3. Căn cứ pháp lý nền

Một biên bản bàn giao thường cần bám vào hồ sơ đã có, ví dụ:

- hợp đồng thi công
- quyết định lựa chọn nhà thầu
- các văn bản phê duyệt liên quan

Field tối thiểu nên có:

- số hợp đồng, ngày ký
- số quyết định, ngày ban hành
- cơ quan ban hành hoặc chủ đầu tư

### 3.4. Thông tin cuộc bàn giao

Đây là nhóm bắt buộc nhưng hiện ít thấy được chuẩn hóa:

- ngày bàn giao
- địa điểm lập biên bản
- phạm vi bàn giao
- mô tả tuyến/hạng mục/khu vực
- hiện trạng mặt bằng
- tồn tại hoặc vướng mắc nếu có
- cam kết của các bên

### 3.5. Khối chữ ký

Bản nháp tối thiểu cần:

- tên người ký
- chức danh
- đơn vị ký
- nhãn khối ký
- thứ tự ký

Nếu chưa chắc chắn người ký, hệ thống chỉ nên:

- để placeholder rõ ràng
- hoặc gợi ý từ hồ sơ tương tự với trạng thái cần xác nhận

## 4. Nguồn dữ liệu có thể tái sử dụng ngay

### Từ hợp đồng thi công

Có thể lấy:

- tên công trình
- tên gói thầu
- số và ngày hợp đồng
- nhà thầu
- chủ đầu tư
- đôi khi có đại diện ký

### Từ quyết định lựa chọn nhà thầu hoặc văn bản pháp lý liên quan

Có thể lấy:

- căn cứ lựa chọn nhà thầu
- tên nhà thầu
- chủ đầu tư hoặc đơn vị ban hành
- thông tin phục vụ phần mở đầu biên bản

### Từ manifest công trình

Có thể lấy hoặc dùng để điều phối:

- trạng thái hồ sơ thiếu
- người phụ trách
- vị trí lưu hồ sơ cũ
- ghi chú nguồn mẫu

### Từ metadata đã ingest

Có thể lấy:

- `project_code`
- `project_name`
- `package_code`
- `contract_code`
- `document_type`
- `doc_stage`
- `related_docs`

### Từ hồ sơ cũ tương tự

Có thể tái sử dụng:

- bố cục biên bản
- boilerplate
- khối chữ ký thường dùng
- cách diễn đạt quen thuộc theo từng chủ đầu tư/đơn vị

Lưu ý:

- đây là nguồn tốt cho template và gợi ý
- không nên mặc định coi mọi field lấy từ hồ sơ cũ là dữ liệu đã xác minh

## 5. Khoảng trống hiện tại

### 5.1. Mạnh ở gap analysis, chưa có generation workflow hoàn chỉnh

Hiện DSCons mạnh ở:

- phát hiện hồ sơ thiếu
- tra cứu hồ sơ đã có
- readiness ở mức stage

Nhưng còn thiếu:

- chọn template cũ tương tự
- mapping field -> placeholder
- object field status với confidence
- workflow draft/review/issue cho tài liệu sinh ra

### 5.2. Chưa có schema riêng cho nhóm execution document

Thiếu mô hình chuẩn cho các field như:

- đại diện ký
- thành phần tham dự
- thời điểm lập biên bản
- nội dung thực địa
- phạm vi bàn giao
- ghi chú tồn tại
- khối chữ ký

### 5.3. Metadata hiện tại thiên về retrieval hơn generation

Metadata hiện rất hữu ích cho tìm kiếm và readiness, nhưng chưa mô tả tốt các field phục vụ template filling như:

- `representatives`
- `meeting_date`
- `meeting_location`
- `handover_scope`
- `signing_parties`
- `template_source_doc`

### 5.4. Chưa có readiness riêng cho “đủ dữ liệu để sinh tài liệu”

Readiness hiện có chủ yếu trả lời:

- stage nào đủ/thiếu hồ sơ

Nhưng chưa trả lời đủ các câu hỏi:

- template nào phù hợp
- field bắt buộc nào còn thiếu
- field nào phải nhập tay
- field nào chỉ là gợi ý
- tài liệu đã đủ để sinh nháp hay đủ để render chưa

### 5.5. Chưa có review workflow rõ cho tài liệu sinh tự động

Theo SOP, nhân viên phải kiểm tra nguồn. Tuy vậy repo chưa thể hiện rõ:

- nơi lưu bản nháp sinh tự động
- ai review
- trạng thái cần sửa / đã duyệt / đã phát hành
- cách tách draft với issued

Đây là khoảng trống vận hành quan trọng.

## 6. Hướng kỹ thuật phù hợp

Hướng phù hợp với DSCons là:

1. phát hiện hồ sơ thiếu từ manifest + rules + metadata
2. chọn loại tài liệu đủ điều kiện để pilot
3. chuẩn hóa template cũ thành template có placeholder
4. dựng payload đầu vào theo loại hồ sơ
5. map dữ liệu hiện có sang placeholder
6. gắn confidence cho từng field
7. tính readiness trước khi render
8. sinh bản nháp có đánh dấu field còn thiếu
9. đưa qua review workflow trước khi phát hành

Nguyên tắc nên giữ:

- không dùng LLM để tự bịa số liệu, ngày tháng, người ký
- field nào không chắc phải đánh dấu `manual_input_required`
- field gợi ý từ hồ sơ cũ chỉ là dữ liệu tham khảo cho bản nháp
- bản sinh ra mặc định là draft cho tới khi có người xác nhận

## 7. Backlog / next steps

Ưu tiên gần hạn:

1. chốt pilot `bien_ban_ban_giao_mat_bang`
2. bổ sung schema dữ liệu đầu vào cho execution document
3. định nghĩa participant/signer model dùng chung
4. chuẩn hóa template registry và bộ placeholder pilot
5. lập bảng mapping field -> nguồn -> confidence
6. định nghĩa readiness riêng cho generation
7. định nghĩa review status riêng cho draft sinh tự động
8. sau khi các lớp trên ổn định mới đánh giá nối DOCX engine

Ưu tiên loại tài liệu tiếp theo sau pilot:

- `bien_ban_nghiem_thu_cong_viec` dạng chuẩn
- `bien_ban_thanh_ly_hop_dong`
- một số công văn/tờ trình có form lặp lại cao

## 8. Rủi ro chính

| Rủi ro | Mô tả ngắn |
| --- | --- |
| copy nhầm từ hồ sơ cũ | dữ liệu cũ bị dùng như dữ liệu hiện hành |
| thiếu field thực địa | hệ thống sinh nháp nhưng phần hiện trạng không đáng tin |
| nhầm draft với bản cuối | người dùng tưởng tài liệu đã đủ điều kiện phát hành |
| template cũ không ổn định | nhiều biến thể, placeholder khó chuẩn hóa |
| dữ liệu nguồn phân tán | cùng một field có nhiều nguồn, khó chọn nguồn chuẩn |

Cách kiểm soát:

- áp confidence theo field
- tách readiness khỏi review
- lưu `source_reference`
- bắt buộc manual/review với field nhạy cảm
- pilot trên một template rõ ràng trước

## 9. Kết luận

DSCons đã có nền khá tốt cho bài toán bổ sung hồ sơ thiếu:

- có taxonomy hồ sơ theo stage
- có rule kiểm tra thiếu hồ sơ
- có readiness ở mức dossier
- có manifest vận hành
- có SOP dùng AI + RAG
- có metadata đủ mạnh cho retrieval và liên kết tài liệu

Tuy nhiên, hệ thống hiện mới mạnh ở phát hiện thiếu và tra cứu, chưa có đầy đủ lớp cho sinh tài liệu thiếu từ hồ sơ cũ.

Bước đi phù hợp là:

- thêm schema đầu vào theo field
- chuẩn hóa template và placeholder
- thêm mapping + confidence + readiness + review
- chỉ sau đó mới nối DOCX engine

Cách làm này phù hợp với hiện trạng repo, ít rủi ro nghiệp vụ hơn và dễ mở rộng sang các loại hồ sơ thiếu khác.