Marker valg for å avgrense hvilke oppgaver som skal vises.
Sticos are developing a bot called @else (http://else.sticos.no) to help Human Resources (HR) departments be more efficient in their work. A lot of their time is consumed by reoccurring questions from their employees and managers. For years HR software have tried to tackle this problem by using a personnel manual. However, the use of it is sparse. The problem lies in accessibility and the fact that is easier to ask the question directly and get a qualified answer to your problem on the fly.
Vis hele beskrivelsen ]
Sticos develops and sells personnel manuals. All rules and answers to employees questions lies in the texts from the personnel manuals. Our customers can also write their own specific rules in the system.
An example correlation is: "An employee can have up to 10 days paid leave in order to take care of his sick kids under the age of 12. However, if the employee has more than 2 children under the age of twelve, he gets 5 days extra. A total of 15 days."
The correlations here are:
• one kid under 12 years : 10 days paid leave
• two kids under 12 years: 10 days paid leave
• three or more kids under 12 years: 15 days paid leave
The project can focus on one or more of the following aspects:
1. Grammatical analytics and statistical classification have different strength and weaknesses. Where IBM and Googles language understanding originates from those different approaches. Today Google, IBM and others uses a hybrid combination of both to understand text better. What is a proper combination of these techniques to understand a Norwegian text?
2. In order to reduce work and secure consistency we want @else to use the personnel manuals when answering questions from employees. What is the best way to achieve this?
[ Skjul beskrivelse ]
DNB sin Chatbot (MVP) på facebook messenger og fremtidige chatbots i nett- og mobilbank vil ha 2 moduser. Chatten vil først behandles av en robot, men kunden vil også få valget om å chatte videre med en rådgiver.
I denne oppgaven er det interessant å finne ut:
1. Hvor gode er våre modeller på å finne intent og gi et riktig svar til kunden?
2. I hvilken grad aksepterer kunder svaret som gis av roboten?
Chatbots bygges som regel opp av en kombinasjon av ulike regler og algoritmer. De enkleste er består hovedsakelig av regler, og de mest avanserte er basert på algoritmer alene. Vår erfaring er at de datadrevne modellene krever enorme mengder data for å fungere.
3. En vurdering av hvor mye data som kreves for å stole på algoritmene alene hadde vært spennende å bake inn i oppgaven.
4. En av de største utfordringene med chatbots er konteksthåndtering. Hvordan beholder man konteksten gjennom en lenger dialog og hvordan vet man at kunden er ferdig med et tema men ønsker å snakke om noe annet i samme tråd?
Med 150.000 henvendelser på Facebook i året og 1,6 millioner chat i nett- og mobilbank har vi tilgang på store mengder ustrukturerte data. Oppgaven kan også brukes til å se på andre spennende bruksområder for dette.
It is now possible to ask natural language queries over Internet, by SMS or by voice over telephone about various tasks, e.g bus routes or telephone information. You can try yourself by calling 7352 1290.
Telebuster is a prototype dialog system that understands conversations about travel information and can provide schedule information. The task will be to make a generic multipurpose query system that answer a variety of questions, and select the right service according to an analysis of the query, and without any restrictions or instructions on how to write the query, just that it is understandable for humans.
Bot-Topics may be route information, cinemas, telephone directories, addresses, tourist information, news, football results etc. The motivation may be to answer any question that you would ask for intance to 1881.
What is the most natural way to get information about bus scedules or other well organised and structured data?
In Trondheim we have the bus oracle (BusTUC) which has answered more than ten million English and Norwegian questions about the buses in Trondheim since 1997. On the other hand, there are also several services that answer many of the same questions, just by selecting location, destination and time constraints.
The goal is to investigate the best way for different groups of users, in different situations, to get travel information. The work can be done together with the FUIROS project, and new modes like Speech, GPS, Maps, and Real-time data integration and route updates could also be investigated.
One specific problem that should be investigated is that when people ask the atb.no Oracle and get an answer they are not happy with, they have to start from scratch again because the system "forgets everything" between questions. How can we make the Oracle react appropriately to each single user's needs, by remembering everything that they have asked before?
Some existing work to build on can be found here.