Practical Thoughts & Observations in the Realms of Optimization

Ahmet Çınar
Trendyol Tech
Published in
8 min readMar 4, 2024
Flow of the Algorithms in Warehouse

Introduction

The experience is a tricky concept. As technology evolves and changes rapidly, one needs to adapt to the massive changes and re-educate oneself to keep up with the new enhancements. This gigantic pace in technological developments forces us to reevaluate what we already know about experience. It is significant to apply the learnings to live problems. Different challenges appear when someone tries to solve a problem. These challenges manifest themselves in various forms: (i) the nature of the problem, (ii) technology requirements/needs, and (iii) communication between different parties. It is utmost important to construct a team that believes in the same goal. Once you have a team motivated by the same principles and believing in the same targets, then the first two challenges become easy to tackle. Throughout the years I have spent at Trendyol, we have delivered many optimization algorithms that created 15–20% efficiency in picking and delivery processes. In the following lines, I will share some of the practical observations that I have acquired during this journey.

Thoughts & Observations

Learning from a process and maintaining a stable and robust pipeline are as important as creating a state-of-the-art algorithm. One of the major reasons for the failures of analytical jobs is focusing solely on the algorithm’s quality without understanding the business or the environment. I will outline eight practical observations and provide discussions on why these observations might enhance the overall business’s quality. These will encompass everything from the quality of algorithms to constructing a team motivated by the same goals.

1. Optimal or Not Optimal

When tasked with solving an operational problem, determining the level of optimality is crucial. Opting for a mathematical model to solve the problem optimally can significantly impact operations. Conversely, resorting to a heuristic approach due to time constraints sacrifices optimality, resulting in deteriorated performance metrics. This predicament is common among algorithm developers tackling operational problems. Recently, we’ve embarked on solving an operational problem using a tailored heuristic while logging the instances. Each day, we re-solve these instances using a mathematical model in our local environments to assess the disparity between the heuristic and the mathematical model. This process also guides us in determining whether enhancements or modifications to our heuristic are necessary.

Figure-1: Slack Notifications

In Figure-1, the results of the heuristic and mathematical models are displayed, with the metric IPC (items per corridor) assumed to be maximized. It’s evident that the score obtained by the mathematical model outperforms the heuristic. However, acquiring the solution for an operational problem using the mathematical model necessitates significantly more time. This situation presents a paradox. Should we opt for the heuristic results and accept smaller IPC values, or should we employ the mathematical model and invest more time? By comparing the outcomes of these two algorithms in our local environments, we observe the disparity between the solutions. This observation leads us to establish the following policy: if, in any given month, the gap between the heuristic solution and the mathematical model solution exceeds 5%, then we should begin utilizing the mathematical model. Currently, we are implementing this policy in our fulfillment centers.

2. What is “Must” behind an analytical model?

Applying analytical models to real-life problems necessitates a clear understanding of the problem and proficiency in essential tools such as programming languages and state-of-the-art algorithms. However, what’s even more crucial is articulating your code or methodology as clearly as possible so that both your future self and others can comprehend its functionality. Therefore, incorporating comments in plain English and mathematical terms is of utmost importance. As the architect of the solution, you should always bear in mind three critical factors you’ll encounter:

* Understanding the problem.
* Grasping the solution strategy and the mathematics behind it.
* Having a moderate familiarity with the coding environment.

Code Segment-1: A Set of Logical Constraints

In Code Segment-1, we implement a set of mathematical constraints. The variables z[i] and z[j] are binary variables that determine whether i and j are selected or not. Another binary variable, y[i][j], assumes the value 1 if both z[i] and z[j] equal 1 simultaneously, and 0 otherwise. The mathematical equalities provided as comments indicate these relations. Including these equalities in the code instantly familiarizes those encountering it for the first time. Such clarity is especially crucial when your code incorporates mathematical models and constraints.

3. Knowing Which Algorithm to Use is Important

Certain solution methodologies that function effectively in smaller dimensions may not necessarily perform efficiently in higher dimensions. Conversely, when crafting an algorithm that approximates well and excels in higher dimensions, it may yield subpar solutions in smaller dimensions. Hence, understanding the appropriate circumstances and contexts for employing an algorithm is as crucial as the algorithm itself.

Code Segment-2: Parallel Call of the Algorithms

Sub-optimal algorithms do not consistently perform well across different problems. This discrepancy arises from the fact that each problem may possess a unique structure, rendering some algorithms unsuitable for certain structures. However, it is often difficult to anticipate this in advance. Therefore, it is considered good practice to offer a variety of algorithms for the problem under consideration and invoke them from an algorithm inventory concurrently for each instance, as demonstrated in Code Segment-2. This approach ensures that the best performer is selected for each instance. For an order batching problem in Trendyol, we employ an adaptive large neighborhood search, a constructive algorithm, and a quadratic model. With this method, we obtain the optimal solution for our batching process for each problem instance. It’s important to note that the performance of algorithms varies depending on the instances.

4. Change is Inevitable

Developing a mathematical or machine learning model, or an algorithm, shares similarities with architectural design. Failure to adequately define variables, features, and constraints with foresight for potential future modifications renders even minor adjustments challenging when requested by customers. It appears imperative that when tackling real-life problems, a significant portion of our time should be devoted to thoroughly comprehending the problem and meticulously designing the model.

5. Robust, Simple and Understandable Designs

As a member of the data science community, our objective is to discover efficient and effective strategies and methods for the problems we aim to solve. To achieve this objective, we should always bear in mind the following principles:

Robustness: Design the models to be robust enough to handle any unanticipated changes with minimal effort.

Simplicity: Adhere to the principle of simplicity. But what does simplicity entail? Simplicity refers to selecting the least expensive and time-consuming approach among various alternatives, allowing us to achieve the same goal with a certain level of confidence.

Understandability: Implement algorithms in a manner that ensures anyone familiar with the field of study and domain can comprehend the developed solutions.

6. Asking the Right Questions

Data scientists are tasked with developing algorithms and models to address real-life problems. We possess the expertise to construct mathematical models and code them proficiently. However, if one fails to grasp the problem accurately, even a flawlessly designed algorithm, in terms of computational efficiency and storage, may remain unused. It is my conviction that the foremost duty of a data scientist is to comprehend the problem correctly. At this juncture, one should not readily accept the provided problem documentation. Instead, one must pose inquiries that aid in a thorough understanding of the problem. This underscores the importance of teaching critical thinking and fostering a culture of questioning. Frequently, it is through asking the right questions that one truly comprehends the problem at hand.

7. Challenges

When endeavoring to solve a business or engineering problem, one often encounters various difficulties, each presenting itself in distinct forms and shapes. From my observations, the most common challenges can be categorized as follows:

* Difficulties intrinsic to the nature of the problem
* Difficulties caused by or requiring technology
* Difficulties driven by human relations or challenges

The challenges within the first two categories can typically be addressed through some form of investment or by employing approximate methodologies that ensure a certain level of quality. However, tackling the third type of difficulty is nearly impossible without assembling a team that shares similar motivations and is unified toward achieving the same goal.

8. The Pressure of Time

Operations researchers and data scientists encounter various real-life problems in business. Typically, these problems fall into three categories: operational, tactical, and strategic. While we often have sufficient time to address tactical and strategic problems, operational issues demand rapid solutions, sometimes within mere seconds. When constructing a mathematical model and implementing it through a solver, we set a time limit for the solver to provide solutions for operational problems. However, there are instances when solvers fail to return any solution within the allocated time limit and continue to run. For instance, if you set a time limit of 30 seconds, but the solver returns a solution after 2 minutes, it introduces significant operational risk. We cannot afford to spend more than 30 seconds on each problem. To mitigate this risk, we may incorporate a mechanism into our algorithm to abort the task if the solver does not return a solution within the specified time limit.

Code Segment-3: Time Limit in Algorithms

Integer programming models attempt to find optimal solutions by iterating through different branches. At each branch, the subproblems are relaxed, and an LP model is solved. If the solutions satisfy integrality conditions, then the branches are pruned. Of course, at each node, different cuts are added to the problem. Once the solver provides an integral solution, the lower and upper bounds of the problem are checked. When the primal and dual bounds coincide, the solver returns with an optimal solution. Often, we waste time in ensuring optimality, resulting in time loss. Therefore, as indicated in Code Segment-3, we set a time limit for our models and accept the solution given within that time limit. This is especially crucial in operational problems because operations must continue uninterrupted.

Conclusion

Over the past five years at Trendyol, spanning various domains and teams, I’ve had the opportunity to observe challenges and how we learn from them. These challenges have been sculpted into perfectly shaped solution statues. We’ve devised algorithms and mathematical models for a multitude of problems, including order allocation, order batching, worklist clustering, picking time prediction, picker routing, supply chain network design, package recommendation, store clustering, courier matching, delivery bundling, prep-time prediction, supply hour prediction, and more. For each project, we propose either a mathematical model, deploy a meta-heuristic algorithm (such as ALNS, genetic algorithms, simulated annealing, etc.), or utilize a machine learning algorithm. Each algorithm undergoes rigorous testing in simulation and production environments. Following thorough investigation, we’ve observed roughly a 20% increase in picking efficiency and a ~15% decrease in delivery times. These improvements were made possible through close collaboration among technology, business, and product teams. When you assemble a team that shares the same goals, solving even the most daunting challenges becomes feasible.

Join Us

We’re building a team of the brightest minds in our industry. Interested in joining us? Visit the pages below to learn more about our open positions.

--

--

Ahmet Çınar
Trendyol Tech

PhD in Operations Research, BA in Law, Lead Data Scientist @Trendyol Tech