Семантычны пошук з ChromaDB і эмбедынгамі для шматагентнай платформы

У праекце Enterprise Multi-Agent AI Platform аджынаваецца новы этап: прыемны канал платформы цяпер выконвае справжній семантычны пошук, выкарыстоўваючы інтэграцыі, якія зберагаюцца ў ChromaDB. Архітэктура перайшла ад падготовкі дакументаў да рэальнага прыемнага каналу, у яком спачатку запускаецца SourceDocument, пасля чаго — DocumentChunker, далей EmbeddingService, потым OpenAI Embeddings, пасля чаго — ChromaDB, далей ведзецца семантычны пошук, і нарэшце — RetrievedDocument.

Гэта значны пераход на новы этап. Платформа больш не толькі падготавляе дакументы і стварае інтэграцыі. Яна можа зберагаць вектарызаваныя корпоратывныя знання, шукаць іх за сэмантыкай, ранжаваць значыцыйя і вяртаць структураваныя рэзультаты. Пад час ўстановкі платформы таксама выявіліся калькі проблем з якасцю прыему, якія павінны былі быць выправлены, прычым канал мог бы быць прыўязаны да RetrievalAgent.

Канал прыбліжаецца да готовасці

Архітэктура адаптавання выглядае так:

Enterprise Documents
        │
        ▼
   SourceDocument
        │
        ▼
 DocumentChunker
        │
        ▼
  DocumentChunk[]
        │
        ▼
 EmbeddingService
        │
        ▼
 OpenAI Embeddings
        │
        ▼
     ChromaDB
        │
        ▼
 Semantic Search
        │
        ▼
RetrievedDocument[]
        │
        ▼
  RetrievalAgent

Кожны слой мае адзіну адпаведная яго задачу, і гэта робіцца намеравана. Метай не была стварэнне адной вялікай функцыі RAG, якая бы завантажвала файлы, дзеляла тэкст, ствараўа эмбедынгі, керавала базай вектароў, выканала пошук і даўала адпаведны адказ. У замену сістэма складаецца з чыстых архітэктурных меж.

Этап 1: даследныя дакументы

Усё пачынаецца з корпаратыўных ведамасцей. З часам гэты кантэнт можа прыходзіць з файлаў PDF, DOCX і TXT, фінансавых атласоў, внутрашняях правілах, тэхнічных дакументацый, науковых матэрыялаў і баз ведамасцей корпарацыі. Мадэль SourceDocument надае гэму матэрыялу стандартную форму пры входзе ў працэс апрацоўкі. Канцэптуальна гэта выглядае так:

SourceDocument
 ├── document_id
 ├── content
 ├── source
 └── metadata

Головным прынцыпом, які тут мае значэння, ёсць відстэжуванісць. Усе, што будзе згодом відновлено, мае залішатыся пов’язанім із віхіднім джэрэлом.

Етап 2: падзелу на частыні

Велікі документы зазвічай не слід вбудовуваты як одын блок. DocumentChunker перэтворуе кожэн SourceDocument на меншы частыні, готові до відновлення:

SourceDocument
      │
      ▼
DocumentChunker
      │
      ├── Chunk 0
      ├── Chunk 1
      ├── Chunk 2
      └── Chunk N

Kiekvieni частак зберае свой chunk_id, document_id, content, source, chunk_index і метаданы. Такім чыном, семантычній пошук можа працюваты з маленькімі одыніцямі інформацыі, не втрачаючы зв’язку з орыгінальнім документом.

Покрашчання якосты частаків

Выканання рэального працэсу отрымання інформацыі віявіло проблему. Розбіток на часткі зарады змісту можа прызвесты до того, што частына слова будзе розрызана між часткамі. Такім чыном, можа вінікнуты частак, які закінчуецца прамо посерэд слова.

...important financial risks for

пасуюць фрагмент, які пачынаюцца так:

the upcoming quarter...

Альбо, у худшых случаях, розкол усерэдзіні слова. Такі фрагменты тэхнічна ўзьямлівы, пры тым чыстацтва даступных даных залежыць не толькі ад правільных структурах даных. Межы вплываюць на сэмантычнае чыстацтва таго, што включаецца.

Таму стратэгія фрагментавання была зменена так, каб для звычнага прозы прывяліцца да меж слоў, а для тэксту без корыстных прабелаў — да меж знакоў. Цяпер фрагментавальны прыстрой мае два рэжымы работы:

Normal prose
    ↓
Prefer word-aware boundaries

Text without whitespace
    ↓
Fallback to character boundaries

Гэта незначны тэхнічны дэталей, але ён несе важную архітэктурную науку: пасыранне тэстаў не значыць, што якосьтва адзысквання дадзеных ў жыцці ёсць хорашым, а рэальныя дадзеныя выкрываюць проблемы, якія ізольаваныя тэсты на елементах часта не можуць паказаць.

Этап 3: эмбеддынгі

Калі фрагменты дадзеных будуць гатовы, EmbeddingService перакладае ўсё іх тэкстацкое змест на чысловыя вектары.

DocumentChunk
      │
      ▼
EmbeddingService
      │
      ▼
Embedding Model
      │
      ▼
Vector Representation

Сэрвіс падтрымляе адна-тэкстовыя эмбедынгі для запітоў і пакетныя эмбедынгі для частак дакументаў. Ранейшы рэальны тэст інтэграціі на месца паўнастаў вектарную размеру 1,536. Сама цыфра мае меншое значэнне, чым той факт, што рэалізацыя эмбедынгу застаёцца за межамі сэрвіса, таму агент для выкарыстоўвання дакументаў ніколі не патрабуе ведаць, як ствараюцца вектары.

Этап 4: Храненне вектараў у ChromaDB

Наступны слой — гэта стацыонарнае храненне вектараў. Кожную частку цяпер можна зберагчы разам з ўсім вектаром і метаданаямі. Канцэптуальна:

DocumentChunk
      +
Embedding
      +
Metadata
      │
      ▼
   ChromaDB
      │
      ▼
Persistent Vector Collection

Запіс вектара можа зберагчыць такую інфармацыю:

Vector Record
 ├── chunk_id
 ├── embedding
 ├── content
 ├── document_id
 ├── source
 ├── chunk_index
 └── metadata

Чысты вектар не мае значэння для рэшты прыемліка. Платформа патрэбуеяць сам факт наявнасці кантэнту і мусі ведаць, звядзе гэты кантэнт прыйшоў.

Этап 5: сэмантычны пошук

Дзякуючы умесцаваным фрагментам у ChromaDB сістэма можа выконваць сэмантычны пошук. Шлях запытку выглядае так:

User Query
     │
     ▼
EmbeddingService
     │
     ▼
Query Embedding
     │
     ▼
   ChromaDB
     │
     ▼
Similarity Search
     │
     ▼
Top-K Relevant Chunks
     │
     ▼
RetrievedDocument[]

Методы адаптавання пошуку зменіліся: з пошуку дакументаў, які точна маюць гэтыя словы, на пошук фрагментаў, значэнне якіх найбольш адпавядае запіту. Гэта ўсьмо тое, што стоіць за основнымі можлівасцямі тэхналогіі RAG.

Корэкцыя метрыкі сэмплярнасці

Практычныя тэсты выявілі ўсьмо другую проблему. Базы дадзеных на адной вектарнай основе падтрымліваюць разныя метрыкі адстані чы сэмплярнасці, і калі колекцыя вікорыстоўвае одну метрыку, а працоўны програма чытае павернутую адстань як іншую, то рэйтынг рэлевантнасці стае вадзейным. Для гэтага працэсу колекцыя ChromaDB была явна настроена на вычысленне косінусовай адстані, таму шар пошуку можа стабільна чытаць рэзультаты як сэмплярнасць, вырачаную на адной косінусовай основе.

Query Embedding
      │
      ▼
ChromaDB
      │
      ▼
Cosine Distance
      │
      ▼
Similarity Score
      │
      ▼
Ranked Results

Семантычныя методы адзыскві ўключаюць не толькі вярненне дакументаў, але і разумэнне таго, насколькі яны рэлевантныя.

Рэальныя рэзультаты адзыскві

Пасля практыкавання методаў чанкавання і калікуляцыі сэмабільнасці, працэс быў перапытаны з рэальным запітам пра фінансавыя рызыкі. Рэзультаты, аранжаваныя па рэлевантнасці, мелі значэння сэмабільнасці апошней часткай 0,6181, 0,5520 і 0,4198; адзысканы кантэкст уключаў рэлевантную інфармацыю пра рызыкі ліквіднасці і волатыльнасці рынку. Такім чынам, працэс адзыскві успел пройсці ўсю гэтую схему:

Question
   ↓
Query Embedding
   ↓
ChromaDB
   ↓
Semantic Similarity
   ↓
Relevant Chunks
   ↓
Financial Risk Context

У тым моманце інфраструктура адзьёбвання пачала выконваць не проста задачы на налагоджэнне, а стала дазваляць рэальнае адзьёбванне сэмантычных дакументаў.

Чаму важная рэальная перацёк адзьёбвання

Макетаваныя тэсты на адзінкавую логіку застаюцца чырвонымі. Яны забезпечваюць шырокаскорасць, дэтэрмінізм, безпеку ў працэсе інтэграцыйных тэстаў, абсэнцію віткоў на зовнішнія API, контрольваныя сцэнарыі неудач і ізоляцыю логікі прыкладнага праграму. Аднак яны не можу адпаведзець на кожнае пытанне. Макетаванны тэст можа падтвердзіць, што ўсё працюе структурна:

EmbeddingService
      ↓
Expected Vector

Але гэта не можа цалкам паказаць, што следуючы ланцуг дае хорашую працэздатнасць пад час выкарыстоўвання:

Real Document
      ↓
Real Chunking
      ↓
Real Embedding
      ↓
Real Vector Database
      ↓
Real Semantic Query
      ↓
Useful Context

Такім чынам, стратэгія тэставання выдзеляе калькі роўней парабярання.

Стратэгія тэставання

Платформа працюе над стварэнням трох падкрэплальных роўней тэставання.

Юнітныя тэсты ўскораныя і дэтэрміністычныя, і яны ўключаюцца ў звычную практыку CI:

Application Logic
      ↓
Mock External Dependencies
      ↓
Controlled Results
      ↓
Assertions

Тэсты інтэграціі пераканальваюць рэальную інфраструктуру і можаць выконвацца окалічна ад шырокага набора інструментаў CI:

Application
      ↓
Real Embedding Provider
      ↓
Real ChromaDB
      ↓
End-to-End Retrieval

Колі платформа розвіваеця, стае необхіднім проводыты тэстування продуктывносты і стабільносты:

Realistic Workload
      ↓
Concurrent Requests
      ↓
Latency
Throughput
Rate Limits
Failures
Cost
Scalability

Сістэма AI, готовая даець рэзультаты у працоўнай суперактывацыі, патрабуе ўсіх трох. Імітаванне зовнішніх служб у тэстах на елементарныя функцыі не заменяе тэстаў інтэграцыі, а тэсты інтэграцыі не заменяюць тэстаў на выкананні. Кожны слой адпавядае на разную інжынерную задачу.

CI застаецца ў стане «зеленага»

Пасля папрабоўкаў паўтарнага запрашэння дадзеных быстрыя тэсты працуюць нормальна: 17 тэстоў пройшлі, а 2 тэсты інтэграцыі былі выключаны. Гэта важна, таму што практыка RAG становіцца все болей складнай, але не паскладваліцься працэс верыфікацыі CI. Цыкл разработкі продовжаецца так:

Code Change
     ↓
Fast Unit Tests
     ↓
Commit
     ↓
Push
     ↓
GitHub Actions
     ↓
CI Validation
     ↓
Keep Green

Тэсты на рэальныя сервісы застаюцца доступнымі як адзінэ отдзельнае запусканне.

Паўязка RAG з платформай калькольнікаў

Інфраструктура адзысквання дакументаў не існуе ізольавана. Яна прызначаная стаць шаром знанняў для большага калькольнікаўскага сістэмы, а шырэйшая архітэктура развіваецца ў гэтым напрамку:

User
                          │
                          ▼
                    Supervisor Agent
                          │
                          ▼
                     Planning Agent
                          │
                          ▼
                    Execution Plan
                          │
                          ▼
                     Agent Registry
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
      RetrievalAgent ResearchAgent AnalysisAgent
             │
             ▼
      RetrievalService
             │
             ▼
      EmbeddingService
             │
             ▼
          ChromaDB
             │
             ▼
      Semantic Search
             │
             ▼
      Relevant Context
             │
             ▼
       Downstream Agents

Этам момант, калі RAG і оркестрацыя калькоў агентаў пачынаюць супрацоўваць разам.

Зберэнне простасці агента выкарыстоўвання дадзеных

Ключовая мета — калі RetrievalAgent быў сфокусаваны на сваёй задачы. Ям не патрэбна інформацыя пра алгорытмы разбівання на часткі, рэалізацыю эмбеддынгу, вектарныя размеры, внутрашняе строенне ChromaDB, вычысленні сэмабільнасці чы ўстановкі хранення. У замяну:

RetrievalAgent
      ↓
RetrievalService
      ↓
VectorStoreService
      ↓
EmbeddingService + ChromaDB

Агент запрашвае неабяжлівыя знання, а інфраструктура выкарыстоўвання знанняяў вяршыць рашэнне пра тое, як іх знайсці. Такая раздзеленасць дазволяе эвалювацыяй асновнай рэалізацыі без перапісву агента.

Наступны крок: замена тымчасовай інфраструктуры выкарыстоўвання знанняяў

Наступны крок ясны. Агент выкарыстоўвання знанняяў все ўсё павінен быць падключаны безпосерэдня да рэальной інфраструктуры выкарыстоўвання знанняяў. Сёньдзе ён выглядае так:

BEFORE

RetrievalAgent
      ↓
Temporary Local Documents

А цэль — гэта:

NEXT

RetrievalAgent
      ↓
RetrievalService
      ↓
VectorStoreService
      ↓
EmbeddingService
      ↓
ChromaDB
      ↓
Semantic Search
      ↓
Enterprise Knowledge

Пасля такой інтэграцыі агент перастае вяртаць тымчасовыя, жорсткая спісаваныя рэзультаты і берае інформацыю з рэальнага індэксаванага калекцыі дакументаў.

Ад інфраструктуры да выканання з калькольніка агентаў

Этая інтэграцыя паказвае ўжо аднойчы пераход. Большая частка працы да гэтага моменту была спрамована на стварэнне інфраструктуры для пошуку. Калі RetrievalAgent будзе вікорыстоўваць рэальную семантычную паеўну, архітэктура зможа падтрымваць такія рабочыя працэсы:

User Request
      ↓
Supervisor
      ↓
Planning Agent
      ↓
Execution Plan
      ↓
Retrieval Agent
      ↓
Enterprise Knowledge
      ↓
Analysis Agent
      ↓
Report Agent
      ↓
Quality Review
      ↓
Final Response

RAG стае адзінам з элементаў шырэйшай сістэмы выканання з калькольнікамі і больш не ўжо ўособлёвай функцыяй адзыскання інфармацыі.

Перспектывы

План развіцця адзыскання інфармацыі пераходзіць ад фундаментальных складовых да можнасцей, адпрацоўваных для практычнага выкарыстоўвання:

Document Contracts               ✅
        ↓
Chunking                         ✅
        ↓
Embeddings                       ✅
        ↓
ChromaDB Vector Storage          ✅
        ↓
Semantic Search                  ✅
        ↓
RetrievalAgent Integration       ← NEXT
        ↓
Reranking
        ↓
Caching & Cost Controls
        ↓
Observability & Metrics
        ↓
Multi-Tenant Isolation
        ↓
Production Hardening

У пазнейшых этапах значэнне вырастае, калі платформа пераходзіць ад функцыональной архітэктуры да кампанейскай эксплуатацыі.

Практычная платформа RAG апыяўляецца больш чым толькі функцыяй выкарыстоўвання дадзеных

Выкарыстоўванне рэлевантных фрагментаў з ChromaDB — гэта важны этап, але не канец архітэктуры. Практычная платформа для выкарыстоўвання дадзеных ў канечнай лініі должна справляцца з:

• Перыякораваннем, таму што пачатковая сэмабільнасць вектараў не завжды дае найкрашчая архітэктура ранжавання.
• Кэшаваннем, адтуды што паўтарныя включэння дадзеных і пошукі збільшаюць час адпаведзення і вітраты.
• Магчымасцю аблікавання, каб можна было мерыць час адпаведзення, час включэння дадзеных, колькасць дакументаў, ўскладненасць, неудачы і вітраты.
• Эвалюацыяй модэляў і вектарных прастораў, таму што змена модэляў включэння дадзеных можа вымагаць версіяваных індэксаў і контролюемага паўтарнага включэння.
• Кераваннем лімітамі частоты, адтуды што зовнішнія прадаўцы AI накладаюць аперацыйныя обмежэння, якія не ўсега дэтэрміністычныя.

Ізоляцыя калькунатароў, таму што даныя падпрыемства не можаць дзеліцца без абмежэнняў у межах выкарыстоўвання.

Контракты схемы, тое ў значэнні стабільных інтарфейсаў между слоямі прабрамлення, умяшчання, зберагача, выкарыстоўвання і агента.

Тэставанне выконвальных якасцей пад рэалістычнымі умовамі канкурантнасці і об’ёма дадзеных.

Гэтыя пункты ўключаюцца да плану развітка, але іх следзь уводзіць паэтапна, з абмежанымі рамкамі, а не спяшаючы ўводзіць у ўсёеедыну рэалізацыю з самага пачатку.

Інжынерны прынцып

Найважлівейшы урок гэтага этапу: спачатку разрабатваць абстракцыю, пераканацца ў яе працэснасці на рэальных дадзеных, а пасля, калі архітэктура расце, удосконаляць яе характэрыстыкі. Гэты прынцып быў выбрана намерна:

Data Contract
     ↓
Chunking
     ↓
Unit Testing
     ↓
Embeddings
     ↓
Mocked Provider Testing
     ↓
Real Integration Validation
     ↓
Vector Storage
     ↓
Semantic Retrieval
     ↓
Retrieval Quality Improvements
     ↓
Agent Integration

Кожны ўзлёт адкрывае новы клас проблем, і самэ гэта ўсёліквідае перавагу інкрэментальной архітэктуры.

З дакументаў да выканання з удзелам калькулятораў

Большая канцэпцыя стае ясней:

Enterprise Knowledge
        ↓
Document Processing
        ↓
Chunking
        ↓
Embeddings
        ↓
Vector Storage
        ↓
Semantic Retrieval
        ↓
Retrieval Agent
        ↓
Multi-Agent Orchestration
        ↓
Analysis + Research + Reporting
        ↓
Quality Review
        ↓
Grounded Enterprise Response

RAG – гэта не вся платформа. Гэта інфраструктура знанняя, якая дазволяе спецыялізаваным агентам працаваць у кантэксце падпрыемства.

Настоячы этап

Што існуе сёння: едынаковыя мадэлі дакументаў, фрагментаванне з урахоўваннем меж слоў, сервіс укладкі з фальшывымі тэстамі на едыніцы плюс рэальны тэст на перакананне, стойкое зберагачэнне ў ChromaDB з явным заданнем косай сэмабільнасці, сэмантычны пошук, які вяртае рэзультаты, сортаваныя па рангу, а таксама швыракі набор з 17 працюючых тэстаў. Наступны этап – падключэнне RetrievalAgent да рэальнага сэмантычнага канвэю адзысквання інфармацыі, дзе сістэма перастае быць проста падсістэмай RAG і начынае выканання багатаагентных задач за дапамогою RAG.

Корпаратыўскі ІІ не значыць проста падключэння LLM да базы дадзеных з вектарамі і прызнання перамогі. Кожны слой патрэбуе дагавораў, дагаворы — тэстаў, інтэграцыі — рэальнай перакананні, а сама сістэма — можлівасці для развіцця. Цяпер шлях перадачы дадзеных распрастарыўся з дакументаў, фрагментаў, эмбедынгаў і вектараў да дакументаў, фрагментаў, эмбедынгаў, ChromaDB, семантычнага пошуку і стосунаванага корпаратыўскага кантэксту. Наступны крок — калі гэты кантэкст прайдзе да RetrievalAgent, а потым да рэалізаціі за дапамогою калькі агентаў. Рабочы цыкл застаецца незменным: ствараць, тэставаць, мерыць, паспрабаваць паўрабіць, інтэгравацыя і масштабаванне.