Skip to content

Conversation

@martinsaieh96
Copy link

Solution by Martin Saieh

⚙️ How to Run the Project

1. Clone the repository

2. Set up your environment

Make sure you have Docker and Docker Compose installed.

3. Build and start the backend and database

docker compose up --build

The API will be available at:
http://localhost:8000/docs

4. Run Alembic migrations

Generate and apply migrations:

./makemigrations.sh "feat: initial migration"

5. (Optional) Generate artificial data

Inside the container, run:

docker compose exec web python3 -m app.ml.fake_data

6. Run automated tests

./runtests.sh

🤖 Data Model Overview

  • Demand
    • id, elevator_id, floor, destination_floor, timestamp_called
  • RestingPeriod
    • id, elevator_id, floor, resting_start, resting_end

All main schema definitions are in app/db/models.py and app/schemas/.


🔬 ML Development (Optional)

If you want to experiment with the ML training pipeline outside of Docker, it's recommended to create a Python virtual environment.

1. Create and activate a virtual environment

# Create venv
python3 -m venv .env_dev

# Activate venv
source .env_dev/bin/activate

🧠 ML Training Workflow

  1. EDA & Aggregation:
    Use Jupyter notebooks to aggregate hourly demand patterns.

  2. Feature Engineering:
    Features include:

    • hour
    • weekday
    • is_weekend
    • demand_count
    • avg_floor
    • most_common_floor
    • avg_direction
    • peak_hours
  3. Label Calculation:
    For each hour, compute the "best resting floor" that minimizes expected distance to future demand.

  4. Training:
    Trained with a RandomForest model (scikit-learn).

  5. Output:
    Model saved as "/ml/models/best_resting_floor_model.joblib". Data exported as CSV.


🚀 API Endpoints

  • POST /demands/ → Create a demand entry
  • POST /resting_periods/ → Create a resting period entry
  • GET /demands/, GET /resting_periods/ → List all
  • POST /predict_resting_floor/ → Get optimal floor prediction from trained model

📦 Requirements

  • Python 3.12 (via Docker)
  • FastAPI, SQLAlchemy, Alembic
  • scikit-learn, pandas, matplotlib, seaborn (for ML)
  • PostgreSQL (in Docker)

Files:

  • requirements.txt
  • requirements-ml.txt

💡 Optimization Approach

I define the "best floor" to rest as the one that minimizes:

Expected Distance = Σ P(floor p is next) * |resting_floor - p|

The model learns the probability distribution of demand conditioned on time and past activity.


@github-actions
Copy link

AI Detection Analysis 🔍

Confidence Score: 30%

Reasoning: This pull request reflects a high degree of domain understanding, integration between multiple components (Docker, FastAPI, SQLAlchemy, Alembic, ML model training), and thoughtful commentary and structure that suggests a careful and iterative manual development process. The author has included contextually accurate Spanish in comments/documentation, proper test coverage with specific edge and domain validation cases, and optional ML considerations. All of these demonstrate a style of software design and development that is more indicative of a human author with engineering experience, rather than an AI-generated submission.

Key Indicators:

  • Consistent use of Spanish in code comments with culturally contextual phrasing ("pensado para debug", "caso borde", "patrones normales") is highly unlikely to be AI-generated unless explicitly prompted.
  • Commentary in code files aligns with realistic domain concerns: closing resting periods with demand initiation, elevator logic edge cases, realistic ML feature engineering for elevator usage.
  • The ML infrastructure includes realistic data simulation (e.g., simulate weekend demand with exponential inter-arrival times), which suggests empirical reasoning rather than synthetic or generic patterns commonly seen in AI code generations.
  • The test suite accounts for domain-specific edge case validations (e.g. destination out-of-range, negative floors, validating auto-closing of idle states).
  • The shell scripts and Docker instructions make use of practical DevOps knowledge such as test automation and parameter validation (“❌ Pass a migration message…”).
  • There’s an articulation of an optimization objective in markdown: a verbalized explanation of the expected distance minimization function, which exhibits theory-to-practice translation—uncommon in AI-generated content by default.
  • While the PR content is well-organized and uses structured Markdown (something LLMs can generate well), it lacks hallmarks of AI-generated verbosity, redundancy, or excessively templated prose.

In summary, the pull request appears to originate from a developer with strong backend/ML understanding, and while an AI could have contributed to specific file generation (e.g., notebook boilerplate), the overall integration and precise alignment with domain reasonable behavior strongly suggest human authorship.

✅ No strong indicators of AI generation detected

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant