Millions of developers around the world use OpenAI’s GPT APIs to integrate some of the most powerful AI models on the market into their products [1]. These models can perform incredible tasks, however, they all currently lack a vital functionality which many developers have been asking for – The ability to search the web.
Due to this inability, OpenAI’s GPT APIs cannot access knowledge after its training data cutoff date, with the latest currently being December 2023 (GPT-4), or anything outside of this data. This incapability is a major issue for any developers who require their model to have the most up-to-date information available online.
OpenSearch solves this by taking a preexisting OpenAI GPT model and empowering it with search capabilities, for any developer to use in their products. Reliability, Scalability and Interoperability are crucial to OpenSearch’s success.
Name: Jordan Russo
Student number: 47445482
The system will comprise of a web application with a clean and simple GUI, where users can securely sign up for an account, add payment info to create API keys on the account page, or chat with OpenSearch itself in a dialogue box on the home page. See https://chatgpt.com/ for design inspiration.
The key features of the system include:
• Home Page: The web page users will first land on which contains navigation to the account and documentation pages and a dialogue box to use OpenSearch.
• Account Page: Once users have logged in, they can access this page which allows them to enter payment info to be able to generate API keys, view API usage statistics and their current wallet balance.
• Documentation Page: A page which provides developers with comprehensive instructions and details on how to use and integrate with the OpenSearch API, including information on endpoints, request/response formats, authentication, and error handling.
• OpenSearch Search Functionality: The actual search functionality will be implemented as follows:
Set Up a Search Engine: Using a public search API, such as Google’s Custom Search API, perform web searches and obtain a list of relevant search results.
Build a Search Dictionary: Collect the title, URL, and a summary of each web page from the search results via web scraping to create a structured dictionary of information.
Generate a RAG Response: Implement Retrieval-Augmented Generation (RAG) by passing the gathered information to the OpenAI LLM, which then generates a final response to the user’s query.
The MVP of OpenSearch will be deployed onto the web and include:
• An intuitive Home page with navigation to the account and documentation pages and a dialogue box to use OpenSearch and view its output.
• An account page which, after users have created a secure account with a username, email and password, lets users generate and view an API key to allow them to utilise the OpenSearch API themselves.
• A documentation page which includes a brief overview of the API, instructions on how to obtain and use an API key, a list of the key endpoints along with their URL paths and HTTP methods and at least one example request with the corresponding response for each endpoint. A short section that outlines common error codes will also be included.
• The OpenSearch API itself must be fully functional (i.e. An OpenAI GPT which has web search capabilities) and useable for other developers. For the MVP we will only implement this for the OpenAI GPT-4o-mini model.
It is vital that OpenSearch can consistently deliver its functionality without failure; it is intended that many developers will utilise it in their own applications, therefore a failure on our end would result in the failure of all applications reliant on OpenSearch, a catastrophic scenario. ‘Consistently functional’ can be defined as the OpenSearch API remaining accessible and responsive with minimal downtime or performance degradation. This will require high uptime, typically 99.9% or higher, ensuring that the API is almost always operational. Additionally, response times should remain stable, with requests being processed within an acceptable latency range to prevent slowdowns.
Being scalable is a very important attribute for OpenSearch to have, as the ability to service a large and growing userbase is critical for the functionality and success of the system. If OpenSearch cannot scale effectively it will suffer from slow response times, high failure rates, and system crashes under heavy load, which can lead to frustrated users and damaged reputation. Scalability has a direct impact on the reliability attribute, which’s importance is explained above. Quantifying and monitoring scalability can be accomplished by using key performance metrics such as Response Time Under Load (Latency), Throughput (Requests Per Second - RPS), and Error Rate (% of Failed Requests).
Interoperability is a core attribute for OpenSearch, as seamless communication, integration, and data exchange both internally and externally is fundamental for OpenSearch’s operation. Without interoperability, OpenSearch will be isolated, completely limiting its usability, increasing development overhead, and making system integration more complex. It is vital that OpenSearch is available for any developer to implement into their own systems and have it operate successfully. Adherence to API standards such as REST, tested through tools such as Postman, will ensure compliance with recognised industry protocols to maximize compatibility.
• Home page: Must load rapidly and reliably every time a user accesses it, it should guarantee near-continuous uptime and resilience to high traffic. Additionally, the dialogue box used to chat with OpenSearch and page navigation should work without failure.
• Account Page: The account page must securely manage and display user data, including API keys, with consistent accuracy. Every action on the account page, such as key generation and user sign-up, should be processed without errors, reflecting a dependable and secure user experience.
• Documentation Page: This page must be consistently accessible, serving as a dependable resource that accurately reflects the current state of the API. Any changes or updates to the API must be promptly reflected in the documentation, ensuring that developers always have reliable guidance.
• OpenSearch API Calls: Must consistently return accurate and timely responses, regardless of load or network variability, thereby ensuring that every request is reliably processed. They should incorporate robust error handling and clear, standardized status codes so that any issues can be immediately identified and resolved.
• Testing tools:
Selenium: Automates browser interactions to ensure web pages load correctly and reliably across different browsers and devices.
Postman: Tests API endpoints to confirm they return accurate responses and proper status codes.
• Home page: Must be designed to handle increasing traffic and data loads without compromising its speed or functionality, dynamically scaling resources during peak usage periods so that users experience consistently fast load times.
• Account page: Should efficiently manage a growing number of concurrent user sessions, ensuring that operations such as login and key management remain responsive even as usage increases. It must be backed by scalable authentication services that can quickly add or remove resources as needed.
• Documentation page: Must reliably serve content to a growing number of developers without experiencing delays or downtime, leveraging caching and content delivery networks (CDNs) to ensure fast load times regardless of traffic volume.
• OpenSearch API Calls: API calls must continue to process an increasing volume of requests without degradation in response times or accuracy. The system should support horizontal and vertical scaling to accommodate higher throughput and ensure low latency even during traffic spikes.
• Testing tools:
JMeter: Simulates heavy traffic to measure performance metrics like latency and throughput, ensuring the API works under heavy load.
K6: Provides performance testing with a scriptable environment for creating custom load tests, helping to monitor how the API handles scaling challenges in real time.
• Home page: Must clearly communicate the API’s support for standard protocols and data formats, reassuring users that it can integrate seamlessly with other systems. It should showcase interoperability features and status indicators that demonstrate compatibility with other platforms
• Account page: The account page must ensure that user management and authentication services are built on open standards so that they can integrate with external identity providers and partner systems. It should provide clear, standardized interfaces that allow secure and smooth data exchange between systems.
• Documentation page: Must present comprehensive, up-to-date information that adheres to common industry formats. It should detail all endpoints, parameters, data formats, and error codes in a standardized way to facilitate easy integration by third-party developers.
• OpenSearch API Calls: Calls must follow standard data formats and protocols to enable seamless communication with other systems. They should implement versioning and standardised error responses to maintain consistent behaviour.
• Testing tools:
Postman: Used to run functional and integration tests, verifying that API endpoints correctly exchange data in standard formats and that responses adhere to predefined schemas.
OpenAPI: Ensures that the API documentation complies with OpenAPI specifications, confirming that endpoints, request formats, and response schemas are standardised.