Конфігурація RD-Agent і Qlib

Розподіліть RD-Agent і Qlib за різними обов’язками

Використовуйте RD-Agent для розробки та ревізії дослідницьких реалізацій, а Qlib — для виконання налаштованого кількісного процесу. Виклики моделі агента можуть пропонувати гіпотези, писати код і тлумачити зворотний зв’язок. Qlib обробляє свої дані, навчання та оцінювання в середовищі експерименту. Отже, ключ API моделі розв’язує лише одну залежність. До налаштування оберіть конкретний сценарій RD-Agent, зафіксуйте ревізію проєкту та визначте межі набору даних і оцінювання. Це відокремлює підготовку середовища від дослідницьких рішень агента.

Налаштуйте чат і embedding через документований бекенд

У перевіреній ревізії 32b3d395 файл .env.example RD-Agent документує бекенд LiteLLM, чат-модель і базову адресу, сумісну з OpenAI, а також окремий маршрут embedding із префіксом proxy. Наведений нижче шаблон оболонки зіставляє слоти моделей, якими володіє програма, із цими документованими полями. Оберіть актуальну чат-модель після перевірки її можливостей. EMBEDDING_BASE_URL і EMBEDDING_MODEL_ID мають посилатися на незалежно доступний сервіс embedding-ів; не припускайте, що чат-шлюз його надає. Передавайте обидва облікові дані через середовище та використовуйте документовану команду запуску сценарію для зафіксованої версії.

export BACKEND=rdagent.oai.backend.LiteLLMAPIBackend
export OPENAI_API_BASE=https://api.apisrouter.com/v1
export CHAT_MODEL="openai/$RESEARCH_MODEL_ID"
# Set OPENAI_API_KEY securely for the chat endpoint.

export LITELLM_PROXY_API_BASE="$EMBEDDING_BASE_URL"
export EMBEDDING_MODEL="litellm_proxy/$EMBEDDING_MODEL_ID"
# Set LITELLM_PROXY_API_KEY securely for the embedding service.

Незалежно перевірте дві можливості моделі

Перевірте, що вибраний чат-клієнт виконує потрібний сценарію формат відповіді та поведінку інструментів. Для embedding-ів перевірте непорожній вектор, сталу розмірність і стабільну ідентичність моделі. Зміна моделі embedding-ів може вимагати перебудови збережених векторів; успішна відповідь чату не перевіряє отримання даних. Підкріплена джерелом схема показує лише запропонований маршрут чату. Префікси провайдера LiteLLM обирають поведінку клієнта й не обов’язково є ID моделі, який бачить кінцева точка, тому зберігайте і налаштоване значення, і розв’язану ідентичність запиту.

Підготуйте кількісне середовище до циклу агента

Перевірте набір даних, середовище Python і дозволений контейнер виконання невеликою детермінованою перевіркою. Для міжнародного дослідження узгодьте регіон набору даних, ринковий календар і універсум інструментів із потрібним ринком. Документація процесу Qlib підтримує регіон США, але її приклад набору даних і припущення не слід без змін копіювати на інший ринок. Підтвердьте історичне охоплення, політику коригування та ідентичність бенчмарка. Лише після цього дозвольте агенту генерувати код-кандидат у цьому середовищі; інакше повторні ревізії моделі можуть лише компенсувати зламане налаштування даних.

Перевіряйте гіпотезу, код і зворотний зв’язок разом

Офіційна ілюстрація RD-Agent показує ітеративний дослідницький інтерфейс. Використовуйте цю структуру як нагадування зберігати кожну гіпотезу разом із її реалізацією та зворотним зв’язком, а не лише фінальний звіт. Рецензент має розуміти, чи виправив агент програмну помилку, змінив дослідницьке питання або вибрав іншого кандидата після перегляду оцінки. Зберігайте відхилені експерименти доступними та відокремлюйте вивід інструментів від інтерпретації агента.

Обмежте виконання коду та збережіть незалежність оцінювання

Запускайте згенерований код із явними обмеженнями файлової системи, мережі та ресурсів. Монтуйте лише потрібні набори даних і не відкривайте неспоріднені облікові дані. До ітеративної розробки зафіксуйте вікна навчання, перевірки та оцінювання на відкладених даних. Якщо зворотний зв’язок тесту багато разів повертається агенту, запишіть, що тестовий період став частиною процесу розробки. Маніфест експерименту має містити ревізію джерела, хеш коду, версію даних, конфігурацію, ідентичність середовища та рішення відбору. Це робить видимими і успішне виконання, і методологічну невдачу для наступного рецензента.

Відстежуйте витрати й відновлюйте невдалий етап

Пов’яжіть журнал запитів чату та embedding-ів із журналом локальних обчислень через ID експерименту. Оцінки вартості LiteLLM не обов’язково є фактичними списаннями шлюзу; узгоджуйте їх із відповідним платіжним записом. Розділяйте збій транспорту моделі, невідповідність векторного індексу, виняток коду та відсутні дані Qlib на різні стани. Тимчасові виклики повторюйте в межах бюджету, а помилки коду зберігайте для перевірки. Не перезапускайте весь цикл, коли виправлення потребує лише одного артефакту джерела або запиту моделі, і недійснюйте кеші, коли змінюється відповідна модель, код або набір даних.

Докази та межі

Поля середовища та поведінку бекенда перевірено в офіційній ревізії джерела 32b3d395 5 вересня 2026 року. Виклик Qlib і його обов’язки відповідають офіційній документації. Для цього посібника через APIsRouter не виконувалися запит клієнта проєкту, результат embedding-ів або повний цикл RD-Agent/Qlib. Наступний крок прийняття — обмежений сценарій зі збереженими входами, доказами запитів і числовими результатами.

Поширені запитання