Github Profile · Raniya Liyakath

I’m Raniya Liyakath (@raniyaaa) on GitHub. My profile is a snapshot of my repositories and project work; my broader professional background is on raniya liyakath linkedin profile.

I have been on GitHub since 2022.

My GitHub profile lists 2 followers and 11 repositories.

Across the listed repositories, the profile reports Python (7) and Jupyter Notebook (3).

MedAgent-Radiology-Orchestrator is an end-to-end radiology AI orchestrator that takes raw medical scans through a modular multi-agent workflow to clinically validated reports. It uses Python and was last updated 2026-11.

I started MedAgent-Radiology-Orchestrator in 2026-03 and last updated it in 2026-11.

I built this as a research prototype and decision-support demo, not a medical device; it must not be used for real clinical decisions.

My pipeline accepts a chest X-ray, CT, or MRI image through a web interface.

For brain MRI, an extra subtype classifier decides whether the scan goes to the Autism or the Brain Tumor model.

Pneumonia benchmark accuracy is 96.36%.

COVID-19 benchmark accuracy is 95.80%.

Stroke benchmark accuracy is 94%.

Autism benchmark accuracy is 97%.

Brain Tumor benchmark accuracy is 98.89%.

I built the project as my M.Sc. Computer Science (AI) final-year project at the Department of Computer Applications, Cochin University of Science and Technology; my guide is Dr. M. K. Sabu. It is a Python repository on my GitHub, @raniyaaa. The LangGraph-based workflow returns a diagnosis, ScoreCAM explainability heatmap, structured report, and LLM-based clinical audit.

The system detects Brain or Chest region and MRI, CT, or X-ray modality before routing to a specialist for one of five conditions. ResNet-18 handles local, focal findings; Swin Transformer handles distributed or bilateral patterns, where self-attention can relate distant image regions. Gatekeeper region and modality models are ResNet-18 models, each reported at 98% accuracy.

The routing rules are X-ray + Chest → Pneumonia; CT + Chest → COVID-19; CT + Brain → Stroke; and MRI + Brain → subtype classifier → Autism or Brain Tumor.

The seven-stage workflow is Upload, Stage 0 Preprocess, Stage 1 Region, Stage 2 Modality, Stage 3 Specialist, Stage 4 ScoreCAM, Stage 5 Report, and Stage 6 Senior Radiologist (vision LLM). Preprocessing converts scans to RGB, resizes them to 224×224, and applies ImageNet normalization. The specialist returns a label and confidence; ScoreCAM uses architecture-specific layer hooks; the report writer produces a structured draft.

At Stage 6, a vision LLM reads the original scan and heatmap, checks the heatmap against a disease-specific anatomical atlas, and produces a seven-step clinical audit. Its JSON output includes hotspot_location, expected_location, estimated_iou, spatial_precision, clinical_relevance, trustworthiness, artifact_detected, verdict, and reasoning. The README names TRUST / REVIEW / REJECT for the audit and CORRECT / PARTIAL / INCORRECT for the JSON verdict; it does not specify how these vocabularies map to each other.

IoU and scores are visual estimates made by the LLM, not computed against ground-truth segmentation masks.

My Level 2 human-in-the-loop workflow uses a structured physician form covering diagnosis correctness, correct label, heatmap focus, confidence appropriateness, severity, follow-up, agreement score, notes.

Feedback submissions are saved to feedback_log.csv and feedback_log.json; a sidebar dashboard presents live accuracy and heatmap-quality statistics. Results are cached in Streamlit session state so feedback-form interactions do not rerun the analysis.

For Level 3 retraining, I use experience replay by mixing physician-corrected cases with original training data, freezing the backbone and fine-tuning only the classification head. Old weights are backed up automatically before replacement. Retraining is designed for Google Colab with a GPU, while retrain.py is also available for local use.

COVID-19 real-world accuracy went from 68.2% to 72.7% using 8 physician corrections.

The retraining scripts default to a minimum of 5 corrections per model.

A handful of corrections may not move a model much. The reported HITL retraining demonstration is small-scale, using eight corrections on the COVID-19 model. Real-world accuracy can be lower than benchmark accuracy because of domain shift; the feedback loop is intended to help reduce that gap.

The stack is LangGraph, FastAPI, Streamlit, PyTorch, torchvision, timm, pytorch-grad-cam, and the Groq API with Llama-4-Scout (vision) and Llama-3.3-70B as a text-only fallback; the project uses Python 3.10. The backend runs on port 8000 and the frontend on port 8501.

The repository contains Radiology-AI-app/engine.py for the LangGraph pipeline, ScoreCAM, atlas, and feedback logging; main.py for FastAPI endpoints /analyze, /feedback, and /feedback/stats; app.py for the Streamlit frontend; retrain.py for local fine-tuning; requirements.txt; and .env for GROQ_API_KEY (not committed). The models/ directory expects anatomical_region_agent1.pth, modality_classifier_agent.pth, brain_mri_subtype_classifier.pth, xray_pneumonia_agent.pth, swin_covid_best.pth, stroke_swin_transformer.pth, brain_tumor_best.pth, and swin_autism_final.pth. Feedback logs are created on first submission, and uploads/ stores analyzed scans for retraining.

The trained .pth files are not included because of their size; I must place them in models/ under the documented names. Setup also requires configuring a local uploads folder that exists. The README lists FastAPI, Uvicorn, python-multipart, Streamlit, torch, torchvision, timm, langgraph, grad-cam, groq, python-dotenv, opencv-python-headless, Pillow, numpy, matplotlib, requests, and pydantic as minimal requirements.

git clone <your-repo-url>
cd Radiology-AI-app
python -m venv venv
venv\Scripts\activate
source venv/bin/activate
pip install -r requirements.txt

I run the backend with python main.py and the frontend with python -m streamlit run app.py.

On Windows, I use python -m streamlit run app.py rather than streamlit run app.py because the plain command was blocked by Windows Firewall on the development machine. I open http://localhost:8501 after starting the frontend. The first CPU scan analysis takes roughly 30 seconds because ScoreCAM runs many forward passes.

The API provides GET / for a health check, POST /analyze for a multipart image upload and region, modality, prediction, confidence, base64 heatmap, report, and audit results; POST /feedback to save a physician feedback record; and GET /feedback/stats for accuracy, heatmap quality, and top failing diagnoses.

python retrain.py --report
python retrain.py --model covid

The project is currently deployed locally because of deep-learning model size and computational-resource requirements. It has no authentication or concurrent-user handling, and ScoreCAM is slow on CPU. A wrong region or modality prediction can route a scan to the wrong specialist.

Future work includes containerised deployment, more diseases and modalities, larger and more varied training data, additional explainability methods, and prospective evaluation with practising radiologists. The README cites Settles (2009) on active learning, Tajbakhsh et al. (2016) on medical-imaging fine-tuning, Rebuffi et al. (2017) on iCaRL/replay, Lenga et al. (2020) on continual learning, Stacke et al. (2020) on domain shift, and Elboardy, A. T., Khoriba, G., and Rashed, E. A. (2025), Medical AI Consensus: A Multi-Agent Framework for Radiology Report Generation and Evaluation.

insurance-prediction-fastapi is a learning project with a basic ML model for insurance premium category prediction, served using FastAPI with a Streamlit frontend. It uses Jupyter Notebook and was last updated 2026-09.

I built insurance-prediction-fastapi as a learning project to predict insurance premium categories with a basic machine-learning model, served through a FastAPI API and Streamlit frontend. The README calls it “FastAPI ML Model Serving” and explicitly describes the model as a dummy model for learning purposes, not for real-world insurance prediction. The stack is Python, Scikit-learn, FastAPI, Pydantic, Streamlit, and Pandas. The repository on my GitHub includes a Jupyter Notebook; it started in 2026-09 and was last updated in 2026-09.

uvicorn app:app --reload

fwi-prediction is a Flask-based ML app that predicts the Fire Weather Index from temperature, humidity, wind speed, and rainfall. It uses Jupyter Notebook and was last updated 2025-08.

I built fwi-prediction as a Flask-based machine-learning web application for predicting the Fire Weather Index (FWI) from weather and environmental parameters, including temperature, humidity, wind speed, rainfall, and other fire-related indices. The README describes FWI as a numerical rating of fire danger based on weather conditions: higher FWI indicates greater potential for wildfire ignition and spread.

I use Ridge Regression for prediction and a Standard Scaler for preprocessing. The model and scaler are saved as .pkl files and loaded at runtime. The repository is identified as a Jupyter Notebook project on my GitHub; it started in 2025-08 and was last updated in 2025-08. The README provides no rationale for the model or preprocessing choice, training procedure, evaluation metrics, performance results, or further deployment details.

autism-project analyzes user responses to detect signs of autism and uses a pretrained ML model for fast, accessible screening. Its description says a pretrained model was used instead of training a custom one from scratch due to time constraints. It uses Python, has 1 fork, and was last updated 2025-06.

I describe autism-project as a tool for analyzing user responses to detect signs of autism, and also as a chatbot for asking questions about uploaded PDF content related to Autism Spectrum Disorder (ASD). I chose a pretrained model instead of training a custom model from scratch because of time constraints. The README does not explain how the classifier used for response analysis relates to the Qwen-based PDF question-answering chatbot, or how those functions work together.

I let users upload one or more research papers or other PDFs; the app extracts and vectorizes their content for semantic search using FAISS and HuggingFace embeddings.

My autism-project repository is written in Python, has 1 fork, started in 2025-05, and was last updated in 2025-06.

The README does not identify the classifier or explain its inputs and outputs, how it fits into the chatbot, or how response-based predictions connect to PDF question answering. It provides no evaluation metrics, validation details, or evidence of clinical effectiveness, and does not define what “detect signs” or “screening” means or clarify whether the tool is intended for screening rather than diagnosis.

I describe the chatbot as using LangChain and the Groq API with Qwen-2.5-32B. It uses recent-conversation memory buffers, specifically LangChain ConversationBufferWindowMemory.
I restrict answers to autism, neurodiversity, and related medical or social topics.
The README lists PyPDF2 for PDF parsing, a pretrained classifier as the ML model, and Python with Flask for the backend; the frontend uses HTML, CSS, and JavaScript.
The files overview names index.html for the interface, styles.css for styling, script.js for user interactions, back.py and vector.py for backend ML processing, and requirement.txt for Python dependencies. It does not specify which backend file performs each function.
movie-recommender recommends similar movies with poster previews using content-based filtering. It uses Jupyter Notebook and was last updated 2025-06.
raniyaaa was last updated 2026-10; the profile provides no description or language for it.

In my GitHub profile README, I describe myself as a Computer Science graduate with an MSc in Computer Science specializing in Artificial Intelligence. I’m interested in Software Engineering and Backend Development, and in building practical applications with AI/ML, LLMs, and multi-agent systems. I want to build reliable, practical, and scalable software; my motto is “Build. Learn. Improve. Repeat.”

My profile highlights backend work with Python, FastAPI, and REST APIs; AI/ML, LLMs, RAG, multi-agent systems, and LangGraph; MySQL, MongoDB, and SQL; Docker and Git; and DSA and problem-solving. Its displayed stack also includes Flask, Django, Linux, VS Code, PyTorch, TensorFlow, and Scikit-learn.

I describe HireCheck as a multi-agent recruitment system that parses resumes, matches candidates against job descriptions, evaluates references, summarizes candidate profiles, and generates recruiter-ready insights. The README lists FastAPI, LangGraph, Groq, OCR, MySQL, and Python as its technologies.

My README also features Multi-Agent Radiology Report Generation, a medical-imaging system that routes images through specialized agents for anatomical region detection, modality classification, downstream analysis, explainability, report generation, and AI-based evaluation. Its listed technologies are PyTorch, LangGraph, Computer Vision, and FastAPI.

The profile README repository started in 2026-09 and was last updated in 2026-10. It links to my LinkedIn profile as Raniya Liyakath and lists my email as raniyaliyakath03@gmail.com.

chat-pdf lets users upload multiple PDFs, extracts their text, generates summaries, and answers queries using an AI-powered chatbot. It uses Python and was last updated 2025-06.

I built chat-pdf as a Python Streamlit app for uploading multiple PDFs and asking questions about their content. It extracts and chunks PDF text, processes it using Google Generative AI embeddings, stores data in a FAISS vector database, and answers queries with Gemini 1.5 Pro. The README also describes generating summaries, but does not explain how summary generation works. ^chat-pdf-details

The README lists LangChain, Streamlit, and Google Generative AI as technologies. Its stack identifies Streamlit as the frontend, Gemini 1.5 Pro via Google Generative AI as the LLM, FAISS as the vector store, PyPDF2 for PDF parsing, and GoogleGenerativeAIEmbeddings for embeddings. It lists “Store data in a FAISS vector database” twice; I do not know whether that repetition was intentional. The project started in 2025-03 and was last updated in 2025-06. The README does not specify file or query limits, deployment details, or further implementation details for summaries.

pydantic-tutorial contains my learning examples for Pydantic and data validation in Python; it was last updated 2026-09.

I describe pydantic-tutorial as a collection of Python examples I made while learning Pydantic and data validation. It covers basic Pydantic models, field and model validation, computed fields, nested models, and serialization.

I started pydantic-tutorial in 2026-09, and it was last updated in 2026-09.

The stated requirements for pydantic-tutorial are Python 3.x and Pydantic.

To run the tutorial, I use python 1_pydantic_why.py.

The README does not specify a Pydantic version, installation instructions, or further run steps.

oops-learning contains practice problems for Object-Oriented Programming in Python; it was last updated 2026-08.

I use oops-learning for practice problems for Object-Oriented Programming in Python.

I started oops-learning in 2026-05.

I last updated oops-learning in 2026-08.

The listed language for oops-learning is Python.

geospatial-measurement-api is a Python FastAPI application for geospatial file processing and geometric measurements; it was last updated 2026-10.

I built geospatial-measurement-api, a Python application that combines a FastAPI backend with a Streamlit frontend and is dockerized using Docker Compose. It accepts KML files and Shapefile ZIP archives, validates uploads, extracts feature geometry types and properties, and calculates Polygon area and LineString length after transforming geographic coordinates into a suitable projected CRS. Point geometries have no area or length calculation. The API provides file upload, file details, and measurement endpoints; its documented paths are POST /api/files/, GET /api/files/{file_id}, and GET /api/files/{file_id}/measurements/.

I document three API endpoints: POST /api/files/ accepts a .kml file or a .zip archive containing a Shapefile and returns an ID and server-side saved_to path; that path is not a public download URL. I use the returned ID—not the illustrative example ID 1—with GET /api/files/{file_id} to retrieve the original filename, file type, source CRS, feature count, processing status, error message, and creation time, and with GET /api/files/{file_id}/measurements/ to retrieve feature indexes, geometry types, and measurements. Point features have null area and length, Polygons have area, and LineStrings have length; measurement values depend on the uploaded geometry.

I validate the filename and extension, save uploads under unique names, check ZIP archives for required Shapefile components, read the data with GeoPandas, extract feature indexes, geometry types, and properties, calculate measurements, and store file metadata and feature results in SQLite. Unsupported extensions, invalid Shapefile ZIP archives, processing failures, and nonexistent file IDs produce errors; when possible, a processing failure also leaves a metadata record with failed status and an error message. Streamlit sends the upload to FastAPI, then uses the returned ID to request details and measurements and display the results, keeping geospatial measurement logic in the backend.

I handle CRS before measuring because geographic coordinates such as EPSG:4326 are in degrees and direct area or distance calculations produce unsuitable units. Missing CRS causes measurement processing to fail. For geographic CRS, I use GeoPandas estimate_utm_crs() and to_crs() before calculating Polygon area or LineString length; suitable projected systems such as UTM yield square metres and metres, respectively. I retain the source CRS as file metadata and use transformed geometries for measurements. UTM estimation may be unsuitable for very large geometries or those spanning multiple projection zones.

I chose FastAPI for a lightweight REST API, automatic OpenAPI documentation, and straightforward endpoint development, and Streamlit for a Python frontend without a separate JavaScript framework. SQLite and SQLAlchemy keep persistence simple without a separate database server; I would consider PostGIS for advanced spatial queries or larger-scale spatial data management. GeoPandas, Shapely, and PyProj support file reading, geometry operations, CRS transformations, and measurements. Uploaded files stay on the filesystem rather than in SQLite. Processing is synchronous during upload for simplicity, while background workers may suit large or long-running workloads. Docker Compose separates backend and frontend containers, provides internal networking, and manages persistent database and upload volumes.

I run the documented tests from the project root with python -m pytest tests/test_files.py -v. They cover nonexistent IDs, valid KML uploads, unsupported extensions, invalid ZIP archives, measurement retrieval, Polygon area, and LineString length. Future improvements I identify include MultiPolygon and MultiLineString measurements, better CRS selection for large or multi-zone geometries, file-size limits and archive protections, background processing, pagination, and expanded tests for missing CRS, empty files, malformed archives, and additional geometry types. This project also gave me practical experience with REST APIs, validation, geospatial processing, persistence, frontend-backend communication, error handling, testing, containerization, and Docker Compose storage.

I use SQLite and SQLAlchemy to store file metadata and feature measurements, while uploaded files remain on the filesystem. The app/ tree contains API routes, database and file/feature models, Pydantic schemas, file-processing services, upload-validation utilities, and main.py. The frontend/ tree contains the Streamlit app and its Dockerfile and requirements; tests/test_files.py covers API behavior and geometry measurements. The stack includes GeoPandas, Shapely, PyProj, Requests, Pydantic, pytest, FastAPI TestClient, and HTTPX. Docker Compose runs separate backend and frontend services; named volumes db_data and uploads_data preserve the database and uploads. The README describes the services at localhost:8000 and localhost:8501.

git clone https://github.com/raniyaaa/geospatial-measurement-api.git
cd geospatial-measurement-api
python -m venv .venv
python -m pip install -r requirements.txt
uvicorn app.main:app --reload
streamlit run frontend/app.py

docker compose build
docker compose up
docker compose up -d
docker compose down

I build separate Docker images for the FastAPI backend and Streamlit frontend from the project root. Docker Desktop must be installed and running, with Docker Compose available through the Docker CLI. Compose connects the two services on an internal network; the frontend uses API_BASE_URL to find the backend, using http://backend:8000 in Compose because backend is the FastAPI service name. The documented local-development address is http://<redacted>:8000; its host is unspecified.

I can open the Streamlit frontend at http://localhost:8501 and the FastAPI Swagger documentation at http://localhost:8000/docs. The frontend container exposes port 8501 and the backend container exposes port 8000; port mappings make both available from the host. I can stop a foreground run with Ctrl + C, or stop and remove the containers and Compose network with docker compose down.

I use the named volume db_data to preserve the SQLite database at /app/data/geospatial.db and uploads_data to preserve uploaded geospatial files at /app/uploads. Stopping or recreating containers does not normally delete these volumes, so I avoid docker compose down -v unless I intend to remove the volumes and their data.

I can upload KML files and Shapefile ZIP archives, then view each file's ID, filename, feature count, processing status, and source CRS.
The frontend displays geometry types and measurements in a table: Polygon area in square metres (m²) and LineString length in metres (m).
It shows error messages when uploads or API requests fail.
HireCheck is a Python multi-agent AI-powered ATS that screens resumes, evaluates candidates, and generates recruiter-ready insights; it was last updated 2026-09.

In the HireCheck GitHub README, I describe a Python, multi-agent applicant tracking system that screens resumes and generates recruiter-ready insights. Recruiters upload multiple PDFs or images, paste a job description (JD) and an Ideal Profile, and process candidates in a batch. The project started in 2026-05 and was last updated in 2026-09.

My documented candidate workflow uses a Parser Agent to extract text from PDFs or images, a JD Matcher Agent to score each resume against the JD, and a Reference Matcher Agent to score it against the Ideal Profile. A Summarizer Agent creates a recruiter summary; the Decision Engine combines the scores and applies the decision thresholds; then a Comms Agent generates an email. Results are saved to SQLite and displayed in the UI.

The JD Matcher and Reference Matcher each score candidates on a 0–10 scale, and the Final Score is the sum of JD Score and Ref Score. The documented rules are > 18 = Accept, 15-18 = Review, and < 15 = Reject. The README gives ACCEPT_THRESHOLD=18 and REVIEW_THRESHOLD=15 as defaults and says recruiters can adjust thresholds live with sidebar sliders. The exact-18 boundary is not explained consistently: the rules put 18 in Review, while the configuration describes 18 as the accept threshold.

The README promises detailed reasoning for scores, candidate summaries, search and filtering by name or decision category, and CSV export of the full results table. Generated emails are mock emails saved as .txt files in mock_emails/, named CandidateName_Decision_Timestamp.txt; the README describes changing agents/comms_agent.py to use Python’s smtplib and Gmail credentials for real Gmail, but does not say that integration is implemented. The feature list says “4 AI Agents” while naming five—Parser, JD Matcher, Reference Matcher, Summarizer, and Comms—an unresolved discrepancy.

The README’s stack is Streamlit for the UI; Groq with llama-3.1-8b-instant; pdfplumber and PyMuPDF for PDF parsing; pytesseract and Tesseract for OCR; SQLite via SQLAlchemy; pandas for export; and python-dotenv for configuration. Its example .env settings are ACCEPT_THRESHOLD=18, REVIEW_THRESHOLD=15, and GROQ_MODEL=llama-3.1-8b-instant; it instructs me to set GROQ_API_KEY and points to https://console.groq.com for a key.

For local setup, the README says to open the HireCheck/ folder in VS Code and run pip install -r requirements.txt. Image-resume OCR requires installing Tesseract; the listed commands are brew install tesseract on Mac and sudo apt install tesseract-ocr on Linux, with a Windows download link to the UB Mannheim Tesseract page. The README gives https://hirecheckfrontend.onrender.com as the browser address.

The repository layout documents app/main.py as a CLI test runner, app/graph.py as the pipeline definition, and app/state.py as the candidate data container. Agent modules cover parsing, JD matching, reference matching, summarizing, and communications; decision/decision.py handles decisions, batch/batch_processor.py processes resumes, database/db.py handles SQLite, and llm/groq_client.py connects to Groq. The README also lists uploads/resumes/, exports/, mock_emails/, streamlit_app.py, and run.py.