LangChain или LlamaIndex: агентът и търсачката искат различна основа

Когато приложението трябва да избира инструменти, да използва междинните им резултати и да решава следващото действие, започнете с LangChain. Когато основният проблем е да намерите точния откъс сред много документи, започнете с LlamaIndex. Това е избор на отправна точка според архитектурата, а не граница на възможностите: и двете платформи поддържат агенти и извличане.

Разликата личи по мястото, където грешката струва най-много. При агент може да бъде избран неподходящ инструмент или да се загуби контекстът между действията. При търсене в документи агентът може да изпълни безупречно задачата си, но да получи остарял или неотносим пасаж. Ако и двете части са сложни, извличането може да бъде отделен инструмент в агентен поток.

Коя част на приложението определя избора

Полезното разклонение е кратко. Ако задачата завършва с намиране на информация и отговор въз основа на нея, проектирайте първо зареждането, индекса и извличането. Ако намерената информация е само вход за следващи проверки или действия във външни услуги, проектирайте управлението на инструментите и състоянието на агента. При сложни документи и сложни действия разделете двете отговорности.

Да вземем условен въпрос за правило във вътрешна папка. Ако резултатът е отговор с относим откъс, качеството на търсенето е водещо. Ако след прочитането на правилото системата трябва да провери календар и да изпрати заявка към друга услуга, решението кога и при какви условия да извика тези инструменти става също толкова важно. Така един и същ документен корпус може да участва в различни архитектури.

Агентният цикъл и паметта

Ръководството за агенти на LangChain описва create_agent като цикъл от модел и инструменти, оформен от системен промпт и middleware. Състоянието включва историята на съобщенията; за запазването ѝ между отделни ходове локалният пример използва checkpointer и идентификатор на разговора. Това е пряка основа за приложение, в което резултатът от един инструмент определя следващото действие.

Ръководството за агенти на LlamaIndex показва FunctionAgent с модел и инструменти, включително възможност търсенето да се предостави чрез QueryEngineTool. Описани са памет за разговора и координация между агенти. Следователно изборът на LangChain за агентен поток е архитектурна препоръка, а не твърдение, че LlamaIndex не може да управлява действия.

Паметта на разговора и документният индекс имат различни роли. Паметта запазва казаното и резултатите от действията в дадено взаимодействие; индексът служи за намиране на съдържание от корпуса. Дългият разговор не обновява автоматично променен документ, както и добре поддържаният индекс не решава сам дали агентът трябва да извика календар, търсачка или друга услуга.

Приемането на документи и извличането

При корпус, който се променя, първото индексиране е само част от работата. Описанието на IngestionPipeline показва последователни преобразувания, кеширане на обработените части и запис във векторно хранилище. При добавено хранилище за документи потокът може да пропусне непроменен вход, а при променено съдържание и свързано векторно хранилище да го обработи отново. Това насочва вниманието към цената на обновяването, а не само към скоростта на първото зареждане.

Документацията за VectorStoreIndex показва краткия път от документи до индекс и посочва, че по подразбиране той се съхранява в паметта. За постоянно съхранение и контрол върху разделянето на текста, метаданните и векторните представяния са нужни допълнителни решения. Името на рамката само по себе си не определя дали намереният откъс е верен: значение имат съдържанието на корпуса, начинът на разделяне, моделът за представяне и настройките на извличането.

Една условна задача, два минимални пътя

При условния въпрос за вътрешно правило минималният път с LlamaIndex е да се заредят файловете със SimpleDirectoryReader, да се изгради VectorStoreIndex.from_documents и да се зададе въпрос през as_query_engine и query. Тази последователност подхожда на задача, която започва и завършва в документите. За реален корпус остават решенията за модела, векторното представяне, обновяването и постоянното съхранение.

С LangChain същите документи могат да се предоставят на create_agent чрез инструмент за извличане. Агентът получава модел, инструменти и системен промпт, а търсенето става едно от възможните му действия. Ако отговорът винаги изисква само едно търсене, агентният цикъл добавя решение, което задачата може да не изисква. Ако след откриването на правилото трябва да се извърши проверка или действие в друга система, цикълът вече обслужва съществената част от процеса.

Комбинацията има ясна граница: LlamaIndex приема и индексира документите и връща относими откъси; LangChain решава кога да извика търсенето и как да използва резултата за следващото действие. Добре е инструментът да връща и произхода на откъса, за да може отговорът да се свърже с конкретен документ. Така промяна в извличането не изисква непременно промяна в цялата логика на агента.

Какво измерва публикуваният тест

В публичния тест RAG-Performance, обновен на 15 юли 2024 г., приемането на корпус от 10 008 026 токена отнема 510,04 секунди с тестваната конфигурация на LangChain, 171,93 секунди с LlamaIndex и 81,54 секунди с асинхронната конфигурация на LlamaIndex. Публикувани са скриптове за възпроизвеждане. Това са резултати за приемане на данни при конкретни реализации, а не измерване на точността на извличането, времето до отговор или скоростта на всеки бъдещ проект.

За сравнение върху собствено приложение измерванията трябва да разграничават отделните източници на забавяне:

• време за първоначално приемане и за обновяване на променени документи;
• дял на въпросите, за които извличането намира правилния откъс, и време за самото извличане;
• пълно време до отговор, включително модела, а при агент — броя и времето на извикванията към инструменти.

Един и същ корпус, набор от въпроси, модел и хранилище правят тези измервания сравними. Иначе бавна външна услуга или различно разделяне на документите лесно могат да изглеждат като разлика между рамките. Публикуваният тест е полезна отправна точка за метод, но изборът зависи от натоварването на конкретната система.

Цената на промяната

Ако приложението вече намира правилните пасажи, но се затруднява с последователността от действия, съществуващото извличане може да остане инструмент, докато се променя агентният слой. Ако агентът е прост, а новите редакции на документите се пропускат или търсенето връща неподходящ контекст, по-важна е преработката на приемането и извличането. Смяната на рамката може да наложи промени в адаптерите, метаданните и индекса, без сама да поправи качеството на намерените откъси.

Изборът е най-устойчив, когато отговорността на всеки компонент е ясна. За многостъпкови действия водещ е агентният поток; за голям и променлив документен корпус — пътят от документа до намерения пасаж. Когато и двете задачи са трудни, отделянето на извличането като инструмент позволява всяка част да се развива според собствените си изисквания.

Прочетете също:

• Descript или Riverside: еднаквите $24 решават различни проблеми
• Canva или Figma: маркетингът и продуктовият дизайн искат различен избор
• Zoom или Teams: гостите и вътрешната работа искат различен избор