Part 3 – Current Progress Summary

[RayZYunYan]

✅ Completed

• Implemented semantic matching between keywords / job requirements and resume sentences using the pre-trained sentence embedding model all-MiniLM-L6-v2.
• Resume input is currently provided in plain text (TXT) format, which is manually converted from a DOC file prior to processing. The code itself does not include automatic document format conversion.
• The resume text is split into sentence-level units and encoded using SentenceTransformer.
• For each job requirement listed in jd_requirements.txt, cosine similarity is computed against all resume sentence embeddings.
• The Top-K (currently Top-2) most relevant resume sentences are retrieved for each requirement and printed in the terminal along with similarity scores as matching evidence.
• Input data files prepared:
  • jd_requirements.txt: sentence-level job requirements (manually curated)
  • jd_skills.txt: keyword / skill list (currently reserved for future use)
• Core implementation is located in resume_match/compare_resume.py.
• Engineering and environment management completed:
  • A dedicated Conda virtual environment is used for Part 3 to avoid polluting the main environment
  • .gitignore added to exclude virtual environments and IDE configuration files
  • Resume text is used for local testing only and is not committed to the repository

---

⚠️ Known Limitations

• Since the resume text is manually converted from DOC to TXT, structural information (e.g., section hierarchy) may be lost, causing some section headers (such as SKILLS or EXPERIENCE) to appear as candidate sentences during matching.
• Matching results are currently displayed via terminal output only; no structured output (e.g., JSON) is generated to explicitly represent “marked” resume sentences.
• The current Job Description (JD) input is also provided as a manually cleaned and pre-split TXT file, rather than being processed directly from raw JD text.

---

🔜 Next Steps (Part 3 Scope Only)

• Extend resume input handling (CV reading module):

  • Support direct parsing of DOC / DOCX resume files without requiring manual conversion to TXT.
  • Support parsing of text-based PDF resumes (scanned PDFs are out of scope).
  • Encapsulate document format conversion (DOC/PDF → TXT) as a dedicated resume preprocessing step, decoupled from the semantic matching logic.

• Improve resume text preprocessing:

  • Apply unified text cleaning and normalization after automatic document parsing.
  • Filter section headers, empty lines, and non-informative content.
  • Refine sentence segmentation so that matching candidates focus on descriptive work and project experience.

• Add preprocessing support for raw Job Description (JD) text:

  • Allow direct input of raw JD text (e.g., copy-pasted job descriptions) instead of relying on manually prepared jd_requirements.txt.
  • Automatically clean and split JD text, including:
    • Removing non-requirement content such as company introductions and benefits
    • Converting JD text into keyword lists or requirement-level sentences suitable for semantic matching
  • Clearly separate the “JD text preprocessing” stage from the “JD–CV semantic matching” stage.

• (Optional) Add structured output format:

  • Output matching results in a structured form (e.g., JSON) to explicitly represent identified/marked resume sentences and their corresponding similarity scores.

---

[RayZYunYan]

Completed

• Implemented semantic matching between keywords / job requirements and resume sentences using the pre-trained sentence embedding model all-MiniLM-L6-v2.
• Resume input now supports direct parsing of multiple document formats:
  • Plain text resumes (.txt)
  • Microsoft Word resumes (.docx, limited support for legacy .doc)
  • Text-based PDF resumes (.pdf). Scanned or image-only PDFs are explicitly rejected.
• A unified resume extraction interface automatically detects the file type and applies the appropriate parsing logic, followed by common text normalization.
• Resume text is split into sentence-level candidate units, filtered to remove likely section headers and noise, and encoded using SentenceTransformer.
• For each job requirement listed in jd_requirements.txt, cosine similarity is computed against all resume sentence embeddings.
• The Top-K (currently Top-2) most relevant resume sentences are retrieved for each requirement and printed in the terminal as matching evidence.
• Added keyword-based exact matching and highlighting:
  • Skills and keywords are loaded from jd_skills.txt and/or extracted from JD text
  • Resume sentences containing matched keywords are highlighted using Markdown-style emphasis
  • Keyword coverage statistics (matched vs. missing skills) are reported
• Improved document parsing robustness, especially for DOCX and PDF inputs:
  • PDF-specific artifact cleanup (hyphenation removal, smart line merging)
  • Generic suppression of incorrect line merging for "Field: value" list-style lines
  • Bullet symbol normalization to improve sentence segmentation consistency across formats
• Input data files prepared:
  • jd_requirements.txt: sentence-level job requirements (manually curated)
  • jd_skills.txt: keyword / skill list used for exact matching and coverage analysis
• Core implementation files:
  • resume_match/compare_resume.py: semantic matching logic
  • resume_match/text_extract.py: multi-format resume parsing and normalization
  • resume_match/keyword_highlight.py: keyword matching, highlighting, and reporting
• Engineering and environment management completed:
  • A dedicated Conda virtual environment is used to isolate dependencies
  • .gitignore configured to exclude virtual environments and IDE configuration files
  • Sample resume files are used for local testing only and are not committed to the repository

Known Limitations

• PDF parsing relies on text-based PDFs only. Scanned or image-only PDFs are not supported.
• Sentence indices may differ across TXT, DOCX, and PDF inputs due to layout and formatting differences, although semantic and keyword matching results remain consistent.
• Keyword matching is rule-based and may miss variants or synonyms that are not explicitly listed.
• Matching results are currently displayed via terminal output only. No structured output format such as JSON is generated.
• Job Description inputs are still provided as manually cleaned TXT files rather than raw, unprocessed JD text.

Next Steps (Current Scope Only)

• Further improve resume sentence segmentation to better isolate experience- and project-level descriptions.
• Expand keyword variant handling for common engineering terms, including symbol-based and abbreviated forms.
• Add optional structured output, such as JSON, to explicitly represent matched resume sentences, associated job requirements or keywords, similarity scores, and coverage metrics.