Co to jest Retrieval-Augmented Generation, czyli RAG?
Przykład kodu w Python który wykorzystuje RAG by przeszukiwać poemat Pan Tadeusz Adama Mickiewicza.
Aby zrozumieć najnowsze osiągnięcia w dziedzinie generatywnej sztucznej inteligencji, wyobraź sobie salę sądową.
Sędziowie rozpatrują i rozstrzygają sprawy w oparciu o swoje ogólne rozumienie prawa. Czasami sprawa – na przykład pozew o błąd w sztuce lub spór pracowniczy – wymaga specjalnej wiedzy specjalistycznej, dlatego sędziowie wysyłają urzędników sądowych do biblioteki prawniczej w poszukiwaniu precedensów i konkretnych spraw, które mogliby przytoczyć.
Środowisko programu
Skrypt który realizuje to zadanie jest napisany w Python. Wykorzystuje LangChain - framework do tworzenia aplikacji opartych na modelach językowych. Sam Lanchain rozbity został na trzy pakiety: langchain-core, langchain-community i langchain. Przeczytaj więcej o każdym z pakietów.
W programie wykorzystywana jest także baza Chroma. Odczytany z poematu tekst dzielimy na kawałki, obliczamy wektory ('embeddings') dla każdego 'kawałka' tekstu i zapisujemy sam fragment oraz wektor do właśnie tej bazy.
Następnym komponentem jest właśnie LLM. Używamy modelu do obliczania wektorów (do czego one są nam potrzebne niżej) oraz generowania treści z naszego poematu (zapisanego w Chroma DB). Środowiskiem modeli jest Ollama.
Jak działa program - loader?
- Odczytujemy plik, dzielimy na kawałki ("chunks"). Polecenie splittera 'CharacterTextSplitter' ma parametry 'chunk_size', 'chunk_overlap', 'separator'. Chunk_size mowi jakiej maksymalnej długości mają być kawałki tekstu. ALE jeśli tekst nie zmieści się w deklarowanej długości, chunk będzie dłuższy. Np. kiedy separator wypadnie dalej niż po 1000 znaków. Program wyświetli wtedy komunikat: 'Created a chunk .... longer than the specified'. Chunk_overlap to po prostu nakładanie się następujących po sobie fragmentów treści czasami wymagane by nie utracić kontekstu. Jeśli tekst konczyłby sie np słowami '... mały rowerek.' to przy 'chunk_overlap=8' to słowo 'rowerek' rozpocznie następne zdanie. Separator oznacza... separator który rozdziela kolejne fragmenty treści. Domyślnym separatorem jest nowa linia. Efektem zastosowania takiego separatora jest próba utrzymania wszystkich akapitów (a następnie zdań, a następnie słów) razem tak długo, jak to możliwe, ponieważ ogólnie wydają się one najsilniejszymi semantycznie powiązanymi fragmentami tekstu. Jednak Twój tekst może być inny, użyj więc innego separatora. Pana Tadeusza. Tekst możesz pobrać np. z https://wolnelektury.pl
- Obliczamy wektor dla tego fragmentu tekstu i zapisujemy sam tekst i wektor do bazy Chroma. Gdybyśmy nie użyli parametru 'persist_directory', fragmenty teksu i ich osadzenia ('embeddings') zapisane zostałyby w pamięci.
Skrypt loader.py
# import
from langchain_community.llms import Ollama
from langchain.chains import RetrievalQA
from langchain_community.embeddings import OllamaEmbeddings
from langchain_community.document_loaders import TextLoader
from langchain_community.vectorstores import Chroma
from langchain_text_splitters import CharacterTextSplitter
# mierzymy czas wykonania, start:
import time
start_time = time.time()
# ładujemy dokument
loader = TextLoader("F:/Ollama/RAG/pan_tadeusz.txt", encoding="utf8")
documents = loader.load()
# dzielimy go na kawałki (chunks)
text_splitter = CharacterTextSplitter(chunk_size=1000, chunk_overlap=0, separator=".")
docs = text_splitter.split_documents(documents)
# model SBERT - embeddings
#embeddings = SentenceTransformerEmbeddings(model_name="all-MiniLM-L6-v2")
# model Ollama - embeddings
embeddings = OllamaEmbeddings(model="mistral")
# zapisujemy do Chroma ('vector store'), do pliku na dysku nie pamieci
db = Chroma.from_documents(docs, embeddings, persist_directory="F:/RAG/ChromaData")
#zapisujemy rezultat - baze z wektorami
db.persist()
# ile czasu zajelo wykonanie
end_time = time.time()
execution_time = end_time - start_time
print("Execution time:", execution_time, "seconds")
Jak działa program - reader?
- Odczytujemy z bazy Chroma treść która jest skojarzona z naszym zapytaniem. Zauważ że nasze połączenie z bazą danych Chroma używa modelu 'mistral' - tego samego którego użyliśmy do utworzenia wektorów w poprzednim kroku (parametr 'embedding_function'). W rezultacie tego zapytania możemy otrzymać kilka dokumentów - używamy ich jako treści której użyje model. Parametr 'return_source_documents=True' pokaże nam które dokumenty zostały użyte do wygenerowania odpowiedzi.
- Używamy modelu by wygenerował odpowiedź na nasze zapytaniu używając treści źródłowej jak wyżej i algorytmów modelu. Parametr 'search_kwargs' retrivera określa ile dokumentów ma być brane pod uwagę przy analizie materiału. Im wyższa liczba, tym dokładniejsza może być nasza odpowiedź (szczególnie jeśli zapytanie nie jest precyzyjne lub źródło 'rozproszone'). Ale będzie to mieć negatywny wpływ na szybkość odpowiedzi - trzeba przeanalizować wiekszą ilość informacji.
Skrypt reader.py
# import
from langchain_community.llms import Ollama
from langchain.chains import RetrievalQA
from langchain_community.embeddings import OllamaEmbeddings
from langchain_community.vectorstores import Chroma
# mierzymy czas wykonania, start:
import time
start_time = time.time()
# reset zmiennej
db=None
embeddings = OllamaEmbeddings(model="mistral")
# odczytaj z bazy Chroma
db = Chroma(persist_directory="F:/Ollama/RAG/data", embedding_function=embeddings)
results = db.get()
llm = Ollama(base_url='http://localhost:11434', model="mistral", temperature=0)
qa_chain = RetrievalQA.from_chain_type(
llm,
retriever=db.as_retriever(search_type="similarity", search_kwargs={"k": 3}),
return_source_documents=True
)
question = "O czym mowa w utworze?"
result = qa_chain.invoke({"query": question})
result["result"]
print(result)
#skasuj wszystko
#db.delete_collection()
#print(results)
# ile czasu zajelo wykonanie
end_time = time.time()
execution_time = end_time - start_time
print("Execution time:", execution_time, "seconds")
Rezultat
Jeśli wykonasz ten skrypt zobaczysz odpowiedz podobną do tej poniżej:
{'query': 'O czym mowa w utworze?',
'result': " The poem appears to be a narrative about an event or scene involving various noblemen and their possessions.
There is mention of a judge, a seneschal (Rejent), an assessor, a bernardyn (a friar), Wilbik, Skoluba, Vojski, and Asesor.
They seem to be discussing the taking away of treasures from churches and the opposition to it.
There is also mention of Napoleon and his granting of titles and lands to his generals.
The poem contains descriptions of various objects such as a horse, a ring, golden armor, agun (a f), and a gun (fuzyjka).
There are mentions of Strapczyna, Wojski, Rejent, and Asesor. They seem to be opposing the taking away of treasures from churches.
The poem also contains descriptions of objects such as a horse, a judge, Spawnik, and a gun.
It is called Sagalas London à Bałabanów or Sagalas, which is a famous Polish English English English English poem.
It speaks of a sword, which was used to crush the animal's body. The poem also mentions a ring, a horse, and a judge.
They seem to be discussing the taking away of treasures from churches, opposition to it, and their opposition to it."}
Jeśli użyjesz parametru 'return_source_documents=True', w odpowiedzi otrzymasz wypisane 'source_documents' - dokumenty które zostały użyte do wygenerowania odpowiedzi.
Format odpowiedzi
W powyższym skrypcie 'result' ma format 'dictionary' (po polsku 'słownik'). Słowniki służą do przechowywania wartości danych w parach klucz : wartość. Słownik to zbiór uporządkowany*, podlegający zmianom i nie pozwalający na duplikowanie.
Czym są Large Language Models (LLMs) i jaki jest ich potencjał?
Duże Modele Językowe (LLM - Large Language Models) mogą odpowiadać na różnorodne zapytania ludzkie. Powstały w wyniku analizy ('szkolenia') ogromnej ilości informacji. Budowa takich modeli obejmuje co najmniej kilka faz takich jak przygotowanie danych, wstępne ich przetworzenie a następnie zastosowanie odpowiednich "tranformatorów" które potrafią obsłużyć różne języki, znaczenie analizowanych materiałów i utworzyć zbiór który jest "modelem językowym". Ten zbiór jest skondensowaną wiedzą i regułami które potrafią obsłużyć zapytania użytkowników. Coś jak encyklopedia Britannica. Co więcej, reguły zawarte w tym modelu mogą być użyte do analizy zewnętrznego źródła danych który nie był obecny podczas "trenowania" modelu - np. wewnętrzna informacja Twojej firmy.
Kiedy mowa o '"sztucznej inteligencji", magicznym terminem który się zawsze pojawia jest "trenowanie". Samo "trenowanie", czyli analiza materiału (źródłowych danych) to tylko jeden z etapów i etap ten nie byłby możliwy bez wcześniejszego zaprojektowania odpowiedniego transformatora (lub kilku). Transformatory mają różne zastosowanie, architekturę i przeznaczenie. Rezultaty ich pracy, np. właśnie "modele językowe" mają różna złożoność i różne przeznaczenie. Kiedy mówimy o "modelach" większość z nas wyobraża sobie natychmiast GPT, Google Gemini czy Ollama. Ale modelami mogą być także np. modele SBERT - są stosowane głównie do rozwiązywania problemów związanych z analizą semantyczną tekstu, w szczególności do zadań, w których istotne jest porównywanie i ocenianie semantycznej podobieństwa między zdaniami lub krótkimi tekstami. Wymieńcie dziesiątki lub nawet setki innych.
Tak więc modele językowe które zostały zbudowane za pomocą transformatorów same zawierają transformatory w celu realizacji zadań jakie postawiono przed tymi modelami. Np. za pomocą modeli SBERT możesz tworzyć osadzenia (embeddings) w wektorowych bazach danych. Przeczytaj więcej na ten temat. Te właśnie "osadzenia" odgrywają kluczową role kiedy wykorzystujesz Duży Model Językowy (LLM w języku angielskim) w koncepcji RAG - Retrieval-Augmented Generation.
Transformatory to rodzaj wielowarstwowej architektury , która przekształca lub zmienia sekwencję wejściową w sekwencję wyjściową. Rozważmy na przykład następującą sekwencję wejściową: „Jaki jest kolor nieba?” Model transformatora wykorzystuje wewnętrzną reprezentację matematyczną, która identyfikuje trafność i związek między słowami kolor, niebo i błękit. Wykorzystuje tę wiedzę, zawartą w modelu, do generowania danych wyjściowych: „Niebo jest niebieskie”. Warstwy transformatorów mogą być można układać jedną na drugiej, tworząc głębsze transformatory i potężne modele językowe. Transformatory biorą udział zarówno w tworzeniu modelu językowego jak i w są zawarte w nich samych by obsługiwać zapytania użytkowników.
Jak powstaje model językowy?
Jak złożone jest to przedsięwzięcie można prześledzić na przykładzie modelu llama firmy Meta (Facebook). W lutym 2023 r wydano Llamę. Już w lipcu 2023 r Llamę2, udostępniając ją bezpłatnie do celów badawczych i komercyjnych, z pewnymi skromnymi ograniczeniami. Prawdopodobnie jeszcze w roku 2024 pojawi się kolejna wersja - Llama3. Obecnie Meta do trenowania tych modeli wykorzystuje infrastrukturę która mniej więcej odpowiada 300 tysiącom wysokiej klasy komputerów osobistych. Ale to mało. Jak powiedział Zuckerberg:
„Budujemy ogromną infrastrukturę obliczeniową, aby wspierać nasz przyszły plan działania… w sumie prawie 600 tys. odpowiedników mocy obliczeniowej H100”
To są ogromne liczby zarówno jeśli chodzi o ilość sprzętu jak i kwoty - ta inwestycja równałaby się 20 miliardom dolarów na chipy. "Trenowanie modelu" to nie jest zadanie dla Twojego biurkowego PC. Jeśli zainteresuje Cię czym jest słynny "H100", przeczytaj więcej o tym układzie na stronie Nvidia.
Rezultat "trenowania modelu" to prawdziwy diament; cała ta wiedza o której mowa powyżej potrafi być zawarta w zbiorze danych który często nie przekracza 4GB.
Parametry - czy zawsze więcej oznacza lepiej?
Parametr w dużym modelu językowym to ustawienie która wpływa na to, jak model rozumie zapytanie i generuje odpowiedź.
Mam tu najczęściej pojęcie "wagi" która informuje model, jak bardzo dany element tekstu jest połączony z innymi (budowanie sekwencji słów w odpowiedzi).
Powiązanym parametrem jest "obciążenie" które pomaga modelowi dostosować się do różnych kontekstów i sytuacji - obciążenia mogą pomagać modelowi uwzględnić różne style pisania, preferencje językowe lub inne cechy tekstu, które mogą wpłynąć na generowane odpowiedzi.
GPT-4 posiada zdumiewającą liczbą 175 bilionów parametrów, przewyższającą 175 miliardów parametrów GPT-3.5. Czy zawsze więcej parametrów oznacza lepiej? W skrócie: nie. Im więcej parametrów ma duży model językowy (LLM), tym lepiej jest w stanie uchwycić złożoność ludzkiego języka i efektywniej go przetwarzać. Wybierając między dwoma modelami o różnej liczbie parametrów, zwykle preferuje się ten z większą liczbą, o ile pozostałe czynniki są podobne. Jednakże istnieje wiele innych kwestii, które warto wziąć pod uwagę. Duże modele są droższe w eksploatacji, zarówno podczas procesu uczenia, jak i w trakcie ich użytkowania, wymagając znacznych zasobów obliczeniowych i danych. Wybór bardziej opłacalnego i zrównoważonego modelu z mniejszą liczbą parametrów może być korzystniejszy dla środowiska, a także dla budżetu. Ważne jest jednak, aby pamiętać, że sukces modelu nie zależy wyłącznie od jego rozmiaru - jakość danych treningowych odgrywa równie istotną rolę. Model z mniejszą liczbą parametrów, ale wyszkolony na danych o wysokiej jakości, może okazać się równie skuteczny, jeśli nie lepszy, niż większy model wytrenowany na danych niskiej jakości.
Potencjał modeli językowych
Ocenia się że 47–56% zadań można by wykonać znacznie szybciej przy tym samym poziomie jakości wykorzystując LLM. Oprogramowanie oparte na LLM będzie miało istotny wpływ na skalowanie skutków ekonomicznych leżących u podstaw modeli. LLM to technologia ogólnego przeznaczenia a to oznaczą że może mieć znaczące implikacje gospodarcze, społeczne i polityczne.
"Sztuczna inteligencja" czyli algorytmy i wykonujące je oprogramowanie mogą identyfikować wzorce w dużych zbiorach danych, konsolidować wiedzę lub tworzyć nowe połączenia."Sztuczna inteligencja" może być wykorzystana by pomagać ludziom identyfikować powiązania między pozornie niepowiązanymi danymi, objaśniać znaczenie poprzez nałożenie nowej warstwy.
Jest to niezwykle, że maszyna potrafi przeprowadzić precyzyjną identyfikację geometrii 3D cząsteczek biologicznych i jednocześnie nie ma w tym niczego niesamowitego - dlaczego maszyna nie miałaby tego zadania wykonać szybciej niż człowiek?
A.I. odświeżyła przepowiednie "upadku programowania" (określenie "kodowanie" jest bardziej właściwe) o których słyszymy od dekad. Tym czasem tworzenie oprogramowania ciągle nie jest rzeczą trywialną. Same programy stają się bardziej złożone nie prostsze. "Sztuczna inteligencja" bardzo pomaga w tym procesie (propozycje kodu, weryfikacja, dokumentowanie, objaśnienia ...) - odciąża programistów i pozwala być im bardziej kreatywnym.
Przepowiednie o firmach zbudowanych na A.I. są niespełnionymi proroctwami. Mamy rok 2024, rynek jest pełny niesamowitego oprogramowania. Czy w związku z tym firmy przestały używać Excel? Ekonomia zawsze wylewa kubeł zimnej wody na rozgrzane głowy marzycieli. Percepcja decydentów i odbiorców jest często dodatkowym firewall'em.
Nie ma żadnej globalnej wioski - jest wzburzone morze na którym A.I. wieje bardziej w żagle dużych galeonów.
To logiczny błąd oczekiwać od algorytmów stworzonych przez człowieka kreatywności która przewyższa idee człowieka.
Cechy takie jaki pomysłowość, wyobraźnia, intuicja, emocje zdecydowanie silniej identyfikują ludzi - maszyny są dobre w symulowaniu.
AI zabierze nam pewna prace i stworzy nową przestrzeń dla naszej aktywności i talentu.
Etyka modeli
Technologia nie tworzy nowego świata. Problemy etyczne pojawiające się w rezultatach pracy modeli językowych nie powstały w nich samych ale poziom niżej. Modele są transparentne - algorytmy korzystają z danych i wyniki bazują na tych źródłach. Są jak małe dzieci których szczerość jest rozbrajająca ale też może doprowadzić do dość niezręcznych sytuacji. Pojęcie "etyki' w "sztuczna inteligencji" jest niewłaściwym użyciem tego słowa. W przestrzeni publicznej niewiele jest treści która nie została poddana cenzurze lub autocenzurze. Te mechanizmy stosowane są także by cenzurować rezultaty dostarczane przez modele językowe. Stosowana jest cenzura semantyczna w celu wykrycia niepożądanych treści w wynikach LLM. W przestrzeni publicznej funkcjonują więc najczęściej "modele cenzurowane.
Product recommendations
The value for business. Shedding the light on recommendation engines details.
Product recommendations in online stores are worth implementing for several reasons, as they can significantly benefit both the consumers and the retailers. Here are some key reasons why product recommendations are valuable:
- Enhanced Customer Experience: Product recommendations provide a personalized shopping experience for customers.
- Increased Sales: Personalized recommendations can lead to higher conversion rates and increased sales.
- Time Savings for Customers: In a vast online marketplace, customers may feel overwhelmed by the sheer number of products available.
- Improved Customer Retention: By offering a personalized and positive shopping experience, online stores can build stronger relationships with their customers.
- Competitive Advantage: In the competitive world of e-commerce, providing a unique and personalized shopping experience can set a store apart from its competitors.
- Data Utilization: Product recommendation algorithms leverage customer data to understand their preferences and behaviors.
- Adaptability and Continuous Improvement: Recommendation systems can adapt and improve over time.
That is what GPT chat said and other sites quote. The fact that personalized recommendations are "worth implementing" seems obvious. It is much more difficult to answer the question "What is the real value of these recommendations - how much profit do they bring?"
What is the real value of product recommendations?
If we take the trouble to check out the results of such a query in Google, we will find out that 35% of Amazon's sales come from recommendations and Netflix achieved 75%. This information originates from some consulting company - published a few years ago is like Garner's "80% of..." or has similar "trust me" certificate. It is undoubtedly impressive, which is why it is often quoted in many materials. Direct revenue increases are more often reported to lie between one and five percent, which can also be substantial in absolute numbers
It is undisputed that recommender systems can have positive business effects in a variety of ways. However, how large these effects actually are - compared to a situation without a recommender system or with a different algorithm - is not always clear.
Unfortunately, while nowadays a number of research datasets are available, they usually do not contain quantitative data from which the business value can be directly inferred. Furthermore, since the choice of a business measures is often specific for a domain, researchers typically abstract from these specific domain what gives simplified results.
The business value of the recommender systems is not adequately defined, measured, or analyzed, potentially leading to wrong conclusions about the true impact of the systems.
Companies usually do not publicly share the exact details about how they profit from the use of recommendation technology and how frequently recommendations are adopted by their customers – main purpose of such information is product or service marketing.
Ticketing tool or BPM platform?
How to organize the environment of custom-built applications and ticket handling tools even more effectively and speed up processes.
Every company has a certain set of applications that are specially developed to support company needs or used in specific way to support some processes running within organization. Custom-built software or application is built specifically for what you need it for - the specific needs of your business.
To avoid communication chaos, we often use tools that are specialized in ticket handling. Ticketing system organizes activities and communication between the customer, the company, and the company teams in charge of meeting demands. In the vast majority of business applications we have some kind of workflow and process organization of work, but ticketing software provides a higher level of work organization, setting priorities, process follow-up and analyzing result.
Our dedicated applications are most often used to work with data and Help Desk/Service Desk systems are used to manage processes.
However, in such an organized architecture, we quickly notice gaps. In every business, a group of people do their job to "deliver value". But we don't do everything together and we break the task into activities because we specialize and carry out tasks according to skills - role. We do our job and pass it on to the next person - like an assembly line. If our production line consists of many unconnected sections, the process is not very effective. These are some of the challenges to deal with.
Information exchange (Interoperability) needed
In order to guarantee a productive, efficient and intelligent work that adds value, reduces costs and is scalable, interoperability is essential. It is impossible to carry out all company operations in one system and companies usually use many dedicated applications to perform various tasks. However, processes often pass through more than one system and therefore data exchange between them is required.
Lack of visibility is killing productivity
Resource shortages, communication frustration, and missed due dates - these can be an outcome of a lack of visibility. It’s pretty common to find teams or employees that are very good at their own tasks, but they have no global view of the company.
If we do not have a clear picture of the entire process, it is difficult to identify potential bottlenecks. Without centralized information about quality, execution time and resources used to perform individual tasks in the process - we are not able to measure or improve the process and therefore we do not manage it.
Applications are expensive
Software is the engine of today’s business - bloodstream of economy. But software cost a fortune. The global software market is predicted to reach a value of 872.72 billion of USD by 2028 [Skyquest Technology Consulting].
The ticketing software we are talking about here, which helps handle corporate processes, is becoming more and more sophisticated and its price is increasing every year - the bigger pool of users, the higher cost it is. Not all users use this class of software in the same intensive way - quite often we have a situation when simply reading information is not enough, but access to full functionality is excessive.
Multiple instance of the same category systems within the company
For various reasons, companies often have multiple instances of software that support processes; ticketing, project tasks and collaboration.
Sometimes it is the legacy of the organizations that have been brought together, sometimes it is conscious choices due to different needs or simply units location but the consequence is always same- these apps remain unconnected.
It can be done in a better way
In fact, most modern ticketing applications offer great freedom in creating configurations tailored to various needs and the ability to connect to various systems. But sooner or later we reach a wall where we have to sacrifice too much to get little, and some of the problems described above remain anyway.
Let's take as an example the onboarding of a new employee in a company. When a new person is hired, a number of activities is performed; employee is created in the systems, equipped with the equipment necessary and properly trained to start work. A sample process diagram might look like below.