chat311

311 service request generation using OpenAI

chat311's People

Contributors

Watchers

chat311's Issues

Identify if this request is a likely duplicate from a similar open request

Write a blog post

Cities are going to be interested in using OpenAI/ChatGPT

Like many others, the advent of OpenAI and ChatGPT will interest city leaders and get them wondering where and how the technology might be useful. As with any new technologies cities look to adopt, it is critical to think through days project and security, as well as if the product truly helps people as opposed to just being a shiny new tool to try.

While there are still many questions to be answered about OpenAI and ChatGPT, we thought of a couple of ways it could help.

Current challenge
Virtually every city has a method for allowing residents to request service - from reporting potholes or street light outages to asking for a street to be plowed, 311 services are a key way city governments interact with their constituents. There are two common challenges.

for residents, the list of requests to choose from are often organized in relation to how city departments are organized, not necessarily how a typical person might think about the request itself. Is a street light outage serviced by the department of public works? Does a missing manhole cover get taken care of by the sewer department?
for cities trying to understand the impact of their operations, it is often difficult to set benchmarks because there are not standard 311 requests across cities. A "pothole" request might be a "pot hole" request in Rochester. A need for "street plowing" in Buffalo might be "snow and ice" in Albany.

Our solution:
Constituent Requests
Using the available OpenAI APIs, we are able to identify the most likely service request and its severity based on a string of text. Instead of relying on a series of drop down menus in a typical 311 application, we can map the person's comments to the correct request type.

If someone types "it is dark on the street on the corner of Washington and Salina streets" the API recognizes the person is likely talking about a street light issue, even though the request says nothing about street lights.

If someone types, "there is a huge pothole near the carrier dome" the API recognizes this as a pothole request, but also says the request is severe (because of the huge pothole). It also recognizes the location of the Carrier Dome as being in Syracuse, though it does not do a good job of finding the right latitude and longitude.
[Screenshot of output]

Requests Standardized
OpenAI also does a good job categorizing requests across cities. Giving lists of categories to the algorithm and asking it to relate them with an explanation for why they are associated works pretty well.

For cities that are interested in performance management and understanding of they are filling similar numbers of potholes in the same amount of time as a related city, this solution helps make the requests apples-to-apples. While not perfect, it allows for a good first pass at relating thetypes of requests quickly.
[Screenshot of output]

Streamlit App
We built the solution using Streamlit, allowing for a quick app deployment that easily leverages the OpenAI API and is extendable to other packages - we added maps and started outputting data quickly.
[Link to repo]

Other thoughts:
The OpenAI APIs are easy to use, but having this app be fully in production and used widely would quickly get expensive. OpenAI gives $18 of free credits for the API - each request cost about $.05 - so enough for testing but not much beyond that.

For a city to use this, it would also be important to consider legal implications of the API - it is very new and still unclear what happens with the data they are collecting.

As with any new technology a city implements, thinking about adoption and roll out for both city staff and the community is critical. In concept this app could act as a front end that could integrate with a number of typical 311 products on the market.

Potential next steps:

integrate this front end with back end 311 apps like seeclickfix
analytics back end to show how cities compare to one another
translation services for requests
routing/ordering of requests based on severity

Report back analytics on how many requests have been completed nearby recently

Dynamically change height of st.text_area based on string length of response

Associate 311 lists from different cities

Using the following lists from Syracuse, Buffalo, and Rochester create a table with Syracuse in one column and Rochester in the second column and Buffalo in the third column that best associates items from each list and tell me why you think they are associated in a final column. Make sure all categories are listed in the table, but only use the categories listed, you shouldn't make up categories on your own. If one category does not associate with others, that is ok, just leave blank for other cities. Here are the lists:

Syracuse:

potholes
streetlights
dead animal in right of way
snow and ice

Rochester:

pot holes
street lights
roadkill
police matter

Buffalo:

potholes
street lights
plowing
code violation

Plot the request location on a map

Using the latitude and longitude, plot the request on a map within the streamlit app

https://docs.streamlit.io/library/api-reference/charts/st.map

Add a "created datetime" field that autogenerates based on when the request is made, have this value output to the exported data

This will be useful when showing how many requests are made per day

Use Geocoding service instead of OpenAI to determine issue location

Write each request and the OpenAI output to a db or parquet file

Each request should be saved and appended as a row to a database or parquet file. The output from the OpenAI response should be saved as well, along with the date of the request. This will let us do further analysis later on.