Building AI/Machine Learning Systems

Project context

Reporting bias arises because text records what is worth mentioning, not a neutral sample of what happens in the world. The project reconstructs inherited COLING 2020 and local ACL draft tasks while keeping paper prose, released code, working-draft assumptions, and recovered artifacts separately identified.

System goals

Evaluate reporting-bias behavior in modern small Qwen- and Mistral-family models through three separated tracks: faithful reproduction, objective frequency or distribution comparison, and later Base/Instruct/Thinking-stage qualitative analysis with calibrated judging only where appropriate.

Implementation

• Collaborate with Xiaohui Jiang, Chuhe Lin, and Tianqing Fang on the project framing, literature positioning, and evaluation design.
• Specified the R0/R1/E1 policy so literal reproductions, minimal compatibility repairs, and extensions cannot be silently collapsed into the same claim.
• Designed an evidence-first experimental control plane with source freeze, StudyLock, immutable RunSpec identities, model and dataset manifests, independent verification, and an append-only evidence ledger.
• Mapped the inherited evaluation surface across COPA multiple-choice scoring, COPA open generation, action-frequency tasks, birth-month and animal-colour distributions, ATOMIC HasProperty, nationality, and gender tasks.
• Prepared local data and provenance paths for XCOPA, SuperGLUE COPA, the pinned reporting_bias_lms repository, colour data, and a Google Books Ngram compatibility subset.
• Built and validated preparation tooling around Qwen3-1.7B-Base COPA dry-runs, tokenizer fixtures, strict inference records, replay contracts, recovery drills, and bounded automation gates.

Delivered outcomes

• Produced the working-paper framework: Does LLM Mitigate Reporting Bias? From Base Models to Instruct and Thinking LLMs.
• Established a reproducible research boundary that separates corpus-aligned reporting error, real-world frequency comparison, sampled response behavior, and post-training response-policy effects.
• Promoted the Qwen3-1.7B COPA preparation path through report/dry-run evidence and a clean ten-item assisted pilot, while keeping full formal experiments, Judge calls, and unattended runs explicitly unarmed.

Project context

Middle-school and high-school students need help between static practice material and live teacher sessions. A generic chatbot can answer fluently, but may give final answers too quickly, drift outside the student scope, leak implementation details, or miss moments that require teacher support.

System goals

Build a controlled AI tutoring workflow conditioned on subject, grade level, language, and learning profile, with guided reasoning, escalation, prompt-injection protection, upload/practice workflows, parent reporting, notifications, moderation, regression tests, and behavior evaluations.

Implementation

• Founded and led the platform implementation across backend, frontend, and AI workflow design.
• Built a Python/FastAPI backend deployed through AWS Lambda with Mangum, DynamoDB-backed repositories, Pydantic models, dependency injection, reports, notifications, moderation, teacher assistance, OCR/upload services, and tutoring logic.
• Implemented a Bedrock-backed tutoring service with structured prompts, bounded conversation history, daily rate limiting, input sanitization, JSON response requirements, output repair paths, internal-term leakage checks, and teacher-escalation flags.
• Built React/TypeScript surfaces for Practice Path, Practice Library, Upload a Question, Learning Assistant, Tutor Support, Online Classroom, parent dashboards, tutor workflows, and admin operations.
• Created an AI evaluation harness covering relevance, grade and subject scope, cheating requests, multi-turn consistency, response language, leakage, and escalation behavior.

Delivered outcomes

• Deployable FastAPI/AWS backend for tutoring, reports, moderation, notifications, users, and learning workflows.
• Controlled LLM workflow with prompt-injection defense, structured output validation, subject/grade/language conditioning, and teacher escalation.
• Regression and E2E coverage across uploads, student chat, moderation, learning profiles, parent dashboards, tutor workflows, subscriptions, classroom flows, and admin reports.
• Observed footprint: 16 backend test files and 15 frontend E2E spec files in inspected repositories.

Project context

Mathematical proof work with AI needs stronger structure than free-form chat. Proof attempts must be grounded in known literature, separated from assumptions, and reviewed against explicit theorem contracts and proof obligations.

System goals

Design a human-AI collaborative proof-development system that tracks theorem contracts, obligation decomposition, imported theorem dependencies, blockers, provenance, and verification boundaries.

Implementation

• Designed a Proof CLI / Research Proof OS workflow for managing theorem statements, proof obligations, imported dependencies, blockers, and trust boundaries.
• Built a retrieval-first process for grounding proof attempts in external literature and tracking provenance before accepting a theorem as usable context.
• Separated verified statements, reviewed imported theorems, and unverified assumptions so proof state remains inspectable during long research threads.
• Developed a verifier-guided proof-search plan comparing LLM-generated proof attempts, retrieval-augmented prompting, candidate reranking, obligation decomposition, and formal verification feedback.

Delivered outcomes

• A structured proof-research operating model for theorem management, dependency review, and blocker tracking.
• A clearer trust boundary between human-reviewed mathematics, externally imported results, and AI-generated candidate arguments.
• A research roadmap for using verifier feedback to guide proof search and improve mathematical reasoning reliability.